Windows Authentication (Kerberos)

​

How it works

• 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.

​

Prerequisites

• A custom XMLA hostname for your organization — contact 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 <xmla-endpoint-hostname>.
• 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 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

ktpass -princ HTTP/<xmla-endpoint-hostname>@CORP.LOCAL ^
       -mapuser CORP\svc-xmla ^
       -crypto AES256-SHA1 ^
       -ptype KRB5_NT_PRINCIPAL ^
       -pass * ^
       -out xmla.keytab

setspn -Q HTTP/<xmla-endpoint-hostname>

​

Configure client machines

1. Domain-joined and logged in as a domain user, so the machine holds a Kerberos ticket (TGT).
2. DNS resolution of <xmla-endpoint-hostname> (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://<xmla-endpoint-hostname> 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).

• In the Server field, enter https://<xmla-endpoint-hostname>/xmla. Windows Authentication does not work with the shared xmla.honeydew.cloud endpoint.
• Set Log on credentials to Use Windows Authentication.

​

Verify the setup

1. Ticket acquisition — proves SPN registration and KDC reachability:
   klist purge
   klist get HTTP/<xmla-endpoint-hostname>
   
   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:
   try {
       iwr https://<xmla-endpoint-hostname>/xmla -UseDefaultCredentials `
           -UseBasicParsing -Method Post -Body "<x/>" -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