Was this page helpful?
Yes No
Tableau Help > Tableau Server on Windows Help > 

Troubleshoot Kerberos

The troubleshooting suggestions in this topic are divided into issues related to Single sign-on (SSO) on the server and issues with the delegated data sources.

Single Sign-on to Tableau Server

Kerberos Authentication Failed (unable to connect automatically to Tableau Server)

If you are using Kerberos for SSO and a user is prompted to sign in to Tableau Server when they connect with either a web browser or with Tableau Desktop, try these steps from the client computer:

Troubleshooting on the client computer

  • Account permissions—Try to sign in to Tableau Server using the user's name and password. If they can't sign in to Tableau Server using their user name and password, they do not have permission to access Tableau Server and Kerberos authentication will fail.

  • Other accounts—Try to connect with SSO to Tableau Server using other user accounts. If all users are affected, the problem may be in the Kerberos configuration.

  • Computer location—Kerberos will not work when connecting from localhost. Clients must be connecting from a computer other than the Tableau Server computer.

  • URL address—You cannot use Kerberos SSO when connecting using an IP address. In addition, the server name you use to access Tableau Server must match the name used in the Kerberos configuration (see Key table entry, below).

  • TGT (Ticket Granting Ticket)—Confirm that the client computer has a TGT from the Active Directory domain. Kerberos requires a TGT to sign in. Constrained delegation, with the proxy granting a ticket, is not supported.

    For more information, see Single-Sign On (SSO) in Kerberos Requirements.

    To confirm the client computer has a TGT, type:

    • klist tgt at a command prompt on a Windows computer
      or
      klist at a terminal prompt on a Mac computer

      The output should show a TGT for the user/domain trying to authenticate to Tableau Server.

      The client computer may not have a TGT in the following circumstances:

      • The client computer is using a VPN connection

      • The client computer is not joined to the domain (for example, it is a non-work computer being used at work)

      • The user signed into the computer with a local (non-domain) account

      • The computer is a Mac that is not using Active Directory as a network account server

  • Browser—Check which browser the user is using to access the server

    • Internet Explorer (IE) and Chrome work "out of the box" on Windows

    • Safari works "out of the box" on Mac

    • Firefox requires additional configuration

    For more information about browser support for Kerberos Single Sign-On (SSO), see Browser Support for Kerberos SSO.

Troubleshooting on the server

If you cannot solve the problem from the client computer, your next steps are to troubleshoot on the computer running Tableau Server. The administrator can use the request ID to locate the sign-in attempt in the Apache logs on Tableau Server.

  • Log files—Check the Apache error.log for an error with the exact time/date of the failed sign-in attempt.

    • In a ziplog archive, these logs are in the \httpd folder.

    • On Tableau Server, these logs are in the \data\tabsvc\logs\httpd\ folder.

  • Key table entry—If the error.log entry says "No key table entry matching HTTP/<servername>.<domain>.<org>@", for example:

    [Fri Oct 24 10:58:46.087683 2014] [:error] [pid 2104:tid 4776] [client 10.10.1.62:56789] gss_acquire_cred() failed: Unspecified GSS failure.  Minor code may provide more information (, No key table entry found matching HTTP/servername.domain.com@)

    This error is a result of a mismatch between any of the following:

    • Tableau Server URL - The URL used by the client computer to access the server.

      This is the name that you type into Tableau Desktop or a browser address bar. It could be a shortname (http://servername) or a fully-qualified domain name (http://servername.domain.com)

    • DNS reverse lookup for the server IP address

      This looks up a DNS name using an IP address.

      At a command prompt type:

       ping servername 

      with the IP address returned by pinging the server, do a reverse DNS lookup type:

      nslookup <ip address>

      The Tableau Server computer name needs to match in:

      • .keytab file

      • Service Principal Name (SPN) for the server

Test Configuration and tabconfig.log

Use the Test Configuration button in the Tableau Server Configuration utility:

If your SPNs are correctly set up for Kerberos, SPNs are correctly configured shows OK.

If any services are configured for delegation, the number of configured services will appear. A value of 0 (zero) does not indicate a problem unless you are using delegation and Kerberos authentication to SQL Server or MSAS.

Look in tabconfig.log for any problems or errors. For example:

2014-10-17 10:58:16.545 -0700 ERROR root: No SPN entries found

If the test does not show successful results, run the configuration script again.

Data source SSO

Delegated data source access failures

Check the vizqlserver log files for "workgroup-auth-mode."

  • In a ziplog archive, these logs are in the \vizqlserver\Logs folder

  • On the Tableau Server, these logs are in the \data\tabsvc\vizqlserver\Logs folder

Look for "workgroup-auth-mode" in the log files. It should say "kerberos-impersonate" not "as-is".

Kerberos delegation multi-domain configuration

Tableau Server has the ability to delegate users from other Active Directory domains. If your database uses MIT Kerberos, you may need to adjust your Kerberos principal to database user mapping. Specifically, you will need to update krb5.conf with rules for each Kerberos realm that users will connect from. Use the auth_to_local tag in the [realms] section to map principal names to local user names.

For example, consider a user, EXAMPLE\jsmith, whose Kerberos Principal is jsmith@EXAMPLE.LAN. In this case, Tableau Server will specify a delegated user, jsmith@EXAMPLE. Tableau Server will use the Active Directory legacy domain alias as the Kerberos Realm.

The target database may already have a rule such as the following to map the user, jsmith@EXAMPLE.LAN to the database user, jsmith.

   EXAMPLE.LAN = {
			RULE:[1:$1@$0](.*@EXAMPLE.LAN)s/@.*//
			DEFAULT
		}

To support delegation, you must add another rule to map jsmith@EXAMPLE to a database user:

   EXAMPLE.LAN = {
			RULE:[1:$1@$0](.*@EXAMPLE.LAN)s/@.*//
			RULE:[1:$1@$0](.*@EXAMPLE)s/@.*//
			DEFAULT
		} 

See the MIT Kerberos Documentation topic, krb5.conf, for more information.

Cross-domain constrained delegation

In some cross-domain scenarios where the KDC is running on a Windows Server prior to Windows 2012, delegation may fail. Errors you may see include:

  • SQL Server Network Interfaces: The system cannot contact a domain controller to service the authentication request. Please try again later.
  • SQL Server Native Client: Cannot generate SSPI context
  • The Domain Controller returns: KRB-ERR-POLICY error with a status STATUS_CROSSREALM_DELEGATION_FAILURE (0xc000040b).

"Cross-domain" refers to a scenario where Tableau Server is running in a different domain than the data source with different service accounts. For example:

  • Tableau Server runs on DomainA with DomainA service account.
  • SQL Server runs on DomainB with DomainB service account.

Traditional constrained delegation only works if both servers are in the same domain. The user can come from other domains.

If you are seeing the errors noted above, then to enable this scenario, your Active Directory administrator should remove any traditional constrained delegation which is configured on the delegating account. Removing delegation can be achieved with Active Directory management tools or by removing the values associated with the Active Directory property, msDS-AllowedToDelegateTo.

If you wish to preserve an existing single domain delegation alongside cross-domain delegation, then you must configure both using resource-based constrained delegation.

The article, How Windows Server 2012 Eases the Pain of Kerberos Constrained Delegation, Part 2, provides a detailed description of how Microsoft KDC and Active Directory handle delegated scenarios. To configure these scenarios, refer to the Microsoft Kerberos documentation.