Tableau Server on Windows Help

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

In a Kerberos SSO environment, a user signing in to Tableau Server from a web browser or Tableau Desktop might see a message indicating that Tableau Server can’t sign them in automatically (using single sign-on). It suggests that they provide a Tableau Server user name and password instead.

Troubleshooting sign-in errors on the client computer

• Enter the user name and password – To check the user’s general access to Tableau Server, sign in by entering the user’s name and password.

  If these credentials fail, the user might not be a user on Tableau Server. For Kerberos SSO to work, the user must be able to access Tableau Server, and they must be granted a Ticket Granting Ticket (TGT) by Active Directory (as described in the TGT item later in this list).

• Check other users’ SSO credentials – Try to connect with SSO to Tableau Server using other user accounts. If all users are affected, the problem might be in the Kerberos configuration.

• Use a computer other than the server computer – Kerberos SSO does not work when you sign in to Tableau Server on localhost. Clients must connect from a computer other than the Tableau Server computer.

• Use a server name, not IP address – Kerberos SSO does not work if you enter an IP address as the Tableau Server name. 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).

• Confirm that the client has TGT –The client computer must have a TGT (Ticket Granting Ticket) from the Active Directory domain. Constrained delegation, with the proxy granting a ticket, is not supported.

  To confirm the client computer has a TGT, do the following:

  • On Windows, open a command prompt and type the following: klist tgt

  • On the Mac, open a terminal window and type the following: klist

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

  The client computer might 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 in to the computer with a local (non-domain) account.

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

• Confirm browser version and settings – For web browser sign-in, make sure the browser is supported for Kerberos and, if necessary, is configured correctly.

  • Internet Explorer (IE) and Chrome work “out of the box” on Windows.

  • Safari works “out of the box” on the Mac.

  • Firefox requires additional configuration.

  For more information, see Tableau Client Support for Kerberos SSO.

Troubleshooting sign-in errors 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 includes the message, “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 of 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 nslookup command will return network information for the IP address. In the Non-authoritative answer portion of the response, verify that the fully qualified domain name (FQDN) matches the following configured values: 

    • The Kerberos .keytab file

    • Service Principal Name (SPN) for the server

    For more information about configuring these values, see Understanding Keytab Requirements.

Verify Kerberos configuration script

You may need to modify the ktpass command that you used to generate the keytab file for environmental variables. Review the troubleshooting steps in the Knowledge Base article, Unable to Generate Kerberos Script Configuration for Tableau Server(Link opens in a new window).

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 can 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(Link opens in a new window), 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 want to preserve an existing single domain delegation alongside cross-domain delegation, you must configure both using resource-based constrained delegation.

For more information about Kerberos and constrained delegation, see the Microsoft topic, Kerberos Constrained Delegation Overview(Link opens in a new window).