Kerberos authentication

Kerberos is the most common authentication method for Windows environments. It can be used to authenticate requests to DAX API.

Available on Enterprise plan.

On the diagram below, Kerberos is used to authenticate requests from Power BI Desktop (step 2):

Authentication flow

Kerberos is the recommended method to authenticate Power BI Desktop requests.

It works as follows:

• Power BI Desktop is launched normally, under the Windows domain account of the user.
• When connecting the DAX API, Windows verifies whether its service principal name is registered in the domain.
• Once verified, the Key Distribution Center issues a Kerberos ticket for the user.
• This ticket is transmitted to the DAX API in the request authorization header.
• The DAX API decrypts and verifies the Kerberos ticket.
• Finally, the user principal name is passed for further verification.

Configuration

Configuring Kerberos authentication includes the following steps:

• Obtain a Windows Server machine to use during the next steps.
• Register the service principal name.
• Generate a keytab.
• Configure the deployment to verify Kerberos tickets.
• Optionally, customize the authentication.

Obtaining a Windows machine

To perform the next steps, you need a Windows Server virtual machine:

• It should be joined to the same domain as the organization’s users.
• It should have the RSAT feature enabled.
• It should be able to reach the Key Distribution Center (KDC). For example, on Azure, this virtual machine can be created in the aadds-vnet subnet.

You should log in to this Windows Server machine using the account that has AAD DC Administrators group membership.

It is also recommended to create a custom organizational unit (OU) and a new user in this OU that will act as the service account.

On the screenshot below, the mdax-api-svc-account user is created in the MyCustomOU OU in the CUBE domain:

Registering the SPN

A service principal name (SPN) is a unique identifier of a service instance. Kerberos authentication uses SPNs to associate a service instance with a service sign-in account.

First, obtain your Cube Cloud deployment’s domain by going to Settings → General and copying the value in the Custom domain section.

Then, use the setspn command to register the Service Principal Name for the DAX API.

In the following example, the web service (HTTP) SPN on the redundant-brohman.gcp-us-central1.cubecloudapp.dev domain is registered for the mdax-api-svc-account user in the CUBE domain:

setspn -S HTTP/redundant-brohman.gcp-us-central1.cubecloudapp.dev CUBE\mdax-api-svc-account

Generating the keytab

The keytab file contains information needed to decrypt the Kerberos token.

First, use the ktpass command to generate the keytab file. You will be prompted to enter the password for the specified user:

ktpass /out kerberos.keytab /princ HTTP/[email protected] /mapuser mdax-api-svc-account /crypto All /ptype KRB5_NT_PRINCIPAL /pass *

Then, convert the keytab to a Base64-encoded string. For example, the following PowerShell script will do the conversion and put the result in the clipboard:

$Path = "C:\kerberos.keytab"
[Convert]::ToBase64String([System.IO.File]::ReadAllBytes($Path)) | Set-Clipboard

Configuring the deployment

Go to Settings → Environment Variables of your Cube Cloud deployment and set the following environment variables to facilitate the verification of Kerberos tickets:

Verifying the credentials

By default, CUBEJS_SQL_USER and CUBEJS_SQL_PASSWORD environment variables are used to verify the passed credentials. You can also customize the authentication by using the check_sql_auth configuration option.

Once the deployment is ready, you can test the Kerberos authentication by connecting from Power BI to the DAX API.

Provisioning users with SCIM

The user principal name passed by Kerberos is often not the email a user is provisioned into Cube Cloud with. For example, Power BI sends a UPN like [email protected], while the user exists in Cube as [email protected]. For authentication to succeed, the principal name must resolve to a Cube user.

To bridge this, Cube Cloud's SCIM API exposes an extension that lets your identity provider sync an alternate username alongside each user. During username-based authentication Cube checks the user's email, username, and any aliases — so the Kerberos UPN resolves to the same user.

Extension schema

Map an IdP attribute to the following single-valued, string target attribute:

urn:cube:params:1.0:UserAliases:alternateUserName

The value is lowercased and trimmed on write, and lookups are lowercased too, so matching is fully case-insensitive — the value just needs to be the same principal string Kerberos sends (same realm and separator). It must be unique across the tenant: if it collides with another user's email, username, or an existing alias, the sync is rejected with 409 Conflict.

Setting it up in Microsoft Entra

These steps assume you already have a SCIM provisioning app connected to Cube Cloud. If not, enable SCIM first under Cube → Settings → Authentication & SSO.

1. In Enterprise applications → [your Cube SCIM app] → Provisioning → Attribute mappings → Provision Microsoft Entra ID Users, tick Show advanced options and click Edit attribute list for customappsso.
2. Add a row: urn:cube:params:1.0:UserAliases:alternateUserName, type String, not multi-valued, not required. Save.
3. Click Add New Mapping and configure:
   • Mapping type: Direct
   • Source attribute: the attribute holding the alternate identity — for hybrid AD / Kerberos this is typically onPremisesUserPrincipalName. To build the principal from parts, use an Expression mapping, e.g. Join("@", [samAccountName], "INTERNAL.REALM").
   • Target attribute: urn:cube:params:1.0:UserAliases:alternateUserName
   • Apply this mapping: Always
4. Save the mapping and the provisioning configuration.
5. Verify with Provision on demand on a test user, then fetch them via GET /api/scim/v2/Users/:id to confirm the alias appears under the extension.

Entra only syncs a user when their source data changes, so existing users won't receive the alias until their next change — use Restart provisioning to force a full re-sync. onPremisesUserPrincipalName is only populated for users synced from on-prem AD; cloud-only users need a different source attribute or an expression with a fallback.

Other identity providers

The Cube-side target attribute is always urn:cube:params:1.0:UserAliases:alternateUserName; only the IdP-side mapping UI differs. In Okta, add a custom attribute on the SCIM app via the Profile Editor, then bind your source attribute to it on the Mappings tab. The value Cube receives is just a string — what you map to it is your decision.