> ## Documentation Index > Fetch the complete documentation index at: https://honeydew.ai/docs/llms.txt > Use this file to discover all available pages before exploring further. # Windows Authentication (Kerberos) > Let domain users connect to the Honeydew XMLA endpoint with their Windows login Windows Authentication for the XMLA endpoint is in Beta. To enable for your organization, please contact [support@honeydew.ai](mailto:support@honeydew.ai). This guide shows how to configure your **Active Directory** (AD) environment so that users on domain-joined Windows machines connect to the Honeydew [XMLA endpoint](/docs/integration/xmla-interface) from [Excel](/docs/integration/bi-tools/excel#connection-xmla-endpoint) with their Windows login — no password prompt and no API key. Authentication uses **Kerberos**: the client obtains a service ticket from your domain controller (KDC) and presents it to the Honeydew XMLA endpoint over HTTPS. ## How it works ```mermaid theme={null} sequenceDiagram participant Client as Windows client
(domain-joined) participant KDC as Your AD / KDC participant XMLA as Honeydew XMLA endpoint Note over Client: Holds a Kerberos ticket (TGT)
from domain login Client->>KDC: Request a service ticket for
HTTP/#60;xmla-endpoint-hostname#62; KDC-->>Client: Service ticket Client->>XMLA: HTTPS request with the service ticket Note over XMLA: Validates the ticket
against the keytab XMLA-->>Client: Connected as the verified user ``` The Honeydew XMLA endpoint is a cloud service — nothing is installed inside your network: * Your network exposes **nothing inbound**. Clients connect out to Honeydew over HTTPS. * Honeydew gets **no access to your Active Directory**. The endpoint validates tickets offline using a **keytab** file you provide — it never connects to your domain controllers. * Employees' machines obtain tickets from your domain controller as usual, on your network. Three things must line up for authentication to work: the **SPN** registered in AD, the **keytab** (Honeydew's copy of the key for that SPN), and **DNS** so that clients reach the endpoint over HTTPS with a trusted certificate. **Who does what:** your **AD administrator** performs the four AD steps below (service account, SPN and keytab, DNS, keytab delivery); your **desktop team** configures the client machines; and **Honeydew** sets up the hostname, loads the keytab, and publishes the endpoint in public DNS. ## Prerequisites * A custom XMLA hostname for your organization — contact [support@honeydew.ai](mailto:support@honeydew.ai) to set one up. Once set up, you can locate it in the Honeydew UI, under the **XMLA** section in **Settings**. The steps below refer to it as ``. * Windows client machines joined to your AD domain. Users log in as domain users. (Machines that are not domain-joined — for example, joined only to Microsoft Entra ID — typically do not hold AD Kerberos tickets and cannot use this method, unless AD tickets are available through Entra Cloud Kerberos Trust). * Each user must be provisioned in Honeydew through the [Entra ID SSO integration](/docs/access-control/entra-id) specifically — a generic OIDC or SAML connection to the same Entra tenant is not matched. Honeydew identifies the caller by mapping their Windows user principal name (UPN) to an email address and matching it (case-insensitive) against an Entra ID-federated Honeydew user whose email is **verified** in the identity provider. If your UPN domain differs from users' email domains, contact Honeydew support to configure a domain mapping for your organization. ## Configure Active Directory These steps are performed once per deployment by your AD administrator. In the commands below, replace `` with your XMLA endpoint hostname and `CORP.LOCAL` with your AD Kerberos realm (uppercase). Create a regular AD user to own the SPN, e.g. `svc-xmla`. In its account settings, enable: * **Password never expires** — otherwise the keytab silently stops working when the password expires. * **This account supports Kerberos AES 256 bit encryption** — for strong keys. Run `ktpass` on a domain controller as a domain admin. This maps the SPN to the service account, sets its key, and writes the keytab file: ```cmd theme={null} ktpass -princ HTTP/@CORP.LOCAL ^ -mapuser CORP\svc-xmla ^ -crypto AES256-SHA1 ^ -ptype KRB5_NT_PRINCIPAL ^ -pass * ^ -out xmla.keytab ``` * The realm in `-princ` must be **UPPERCASE** (`@CORP.LOCAL`) — a lowercase realm is a common cause of authentication failures. * `-pass *` prompts for (or resets) the service account password. Note the resulting key version (KVNO) — a later password reset invalidates the keytab. * Use `AES256-SHA1`, and avoid the legacy DES/RC4 mechanisms. * The SPN service class is `HTTP` even though the endpoint uses HTTPS. Do not use `HTTPS/`. * `ktpass` rewrites the service account's UPN to the `-princ` value. This is expected — the AES key salt derives from it — but note it if other systems rely on that account's original UPN. Verify the SPN is unique — it must return exactly one account: ```cmd theme={null} setspn -Q HTTP/ ``` Duplicate SPNs (the same SPN on more than one account) break Kerberos authentication. Use `setspn -X` to find duplicates. Honeydew publishes `` in public DNS as an **A record** — no DNS configuration is needed as long as your client machines resolve public hostnames. If your network restricts clients to internal DNS servers, create a matching A record in your internal DNS. Ask your Honeydew support contact for the address. In that case: * Do not use a CNAME — some clients build the SPN from the canonical name and request the wrong service ticket. * A reverse-lookup (PTR) record is not required. Deliver the generated keytab to Honeydew through a secure channel agreed with your Honeydew contact — do not send it as an unencrypted email attachment. Treat the keytab like a password: anyone who holds it can impersonate the XMLA endpoint. Honeydew loads it into the XMLA endpoint configuration for your organization. On any service account password or key reset, the keytab becomes invalid (its key version changes). Re-run `ktpass` and re-deliver the keytab to Honeydew, coordinating timing with your Honeydew support contact. Rotate the keytab on the schedule set by your organization's credential-rotation policy, following the same steps. ## Configure client machines Each Windows client needs the following. For a fleet rollout, apply via GPO. 1. **Domain-joined** and logged in as a domain user, so the machine holds a Kerberos ticket (TGT). 2. **DNS resolution** of `` (see the DNS step above). 3. **Certificate trust** — the endpoint's TLS certificate chain must be trusted by the client. A public CA works out of the box; an internal CA requires distributing its root certificate (GPO → Trusted Root Certification Authorities). 4. **Local Intranet security zone.** Excel (via Windows HTTP services) sends the Kerberos ticket automatically only when the host is in a zone that allows it. Add `https://` to the **Local Intranet** zone. Fleet-wide via GPO: *User/Computer Configuration → Administrative Templates → Windows Components → Internet Explorer → Internet Control Panel → Security Page → **Site to Zone Assignment List*** — add the URL with zone value **1** (Intranet). Without this, the client either does not send the ticket or prompts for credentials. 5. **MSOLAP provider** installed (ships with Office / the Analysis Services OLE DB provider). The Honeydew XMLA endpoint accepts **HTTPS** connections only. Once configured, users connect from Excel following the [XMLA connection steps](/docs/integration/bi-tools/excel#connecting-excel), with two differences: * In the **Server** field, enter `https:///xmla`. Windows Authentication does not work with the shared `xmla.honeydew.cloud` endpoint. * Set **Log on credentials** to **Use Windows Authentication**. ## Verify the setup Run the following checks on a domain-joined client machine. 1. **Ticket acquisition** — proves SPN registration and KDC reachability: ```powershell theme={null} klist purge klist get HTTP/ ``` Use the bare SPN — do not append `@REALM`. On Windows, `klist` infers the realm from the machine's domain, and a realm-qualified SPN can itself raise `KDC_ERR_S_PRINCIPAL_UNKNOWN`. Note that `klist purge` clears the entire logon session's ticket cache, not just this SPN, so run it on a test machine. Success prints a ticket for the SPN; a `KDC_ERR_S_PRINCIPAL_UNKNOWN` error means the SPN is not registered or contains a typo. 2. **End-to-end handshake** — send an authenticated request over HTTPS and check the status code: ```powershell theme={null} try { iwr https:///xmla -UseDefaultCredentials ` -UseBasicParsing -Method Post -Body "" -ContentType "text/xml" | Out-Null } catch { $_.Exception.Response.StatusCode # 401 = Kerberos failed; 500 = handshake OK } ``` The test body is deliberately malformed, so a working endpoint returns an **HTTP `500`** fault — never a `200`. A **`401`** means Kerberos failed (the client could not present a valid ticket); a **`500`** (or any status other than `401`) means the Kerberos handshake succeeded. The `try/catch` is required because Windows PowerShell 5.1 raises a terminating error on a `401` or `500` alike, so a bare `iwr` cannot tell them apart. This proves only that Kerberos authentication works — not that the user is authorized. Both an authorized user and one who is not provisioned get a `500` here, so confirm authorization with the Excel step below. 3. **Excel** — connect a Pivot Table with **Use Windows Authentication**; it should connect without a password prompt. ## Troubleshooting | Symptom | Cause | | ---------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `KDC_ERR_S_PRINCIPAL_UNKNOWN` | SPN not registered, a typo, or a CNAME host | | Duplicate SPN errors, intermittent authentication | SPN on more than one account — `setspn -X` | | `KRB_AP_ERR_SKEW` | Client clock more than 5 minutes off from the domain controller | | Client prompts for a password | Host not in the Local Intranet zone, or plain HTTP used | | TLS trust error in Excel | Certificate not trusted (internal CA root not distributed) | | Authentication broke after a password reset | Keytab is stale — regenerate and re-deliver it | | Works with `klist` and `iwr` but not Excel | Host not in the Local Intranet zone — `iwr` ignores zone policy but Excel enforces it | | Errors only behind a corporate proxy | Proxy re-signs the cert or breaks `Negotiate` — exempt the endpoint from TLS inspection and proxy authentication | | `Windows account not authorized` (after Kerberos succeeds) | Identity not provisioned as an Entra ID user; matched user's email not verified in the identity provider; UPN does not map to its email; or more than one Entra user shares that email — contact support | If authentication fails, run `klist` after a connection attempt and check for a ticket for `HTTP/`. If none is present, the client fell back to NTLM — which the endpoint cannot validate — so check the SPN and DNS.