Cannot Find Key of Appropriate Type Error When Attempting to Authenticate using Kerberos

Issue

After enabling Kerberos SSO, users are not automatically signed in and receives the message, "Tableau Server could not authenticate you automatically" when navigating to a Tableau Server URL.

Environment

Tableau Server
Kerberos SSO

Resolution

1. Specify the correct cipher when creating the keytab file with /crypto based on what the Kerberos Key Distribution Center (KDC) supports. If using AES ciphers, be sure to specify /mapuser when creating the keytab.

From the Tableau Online Help Article please note the following from the batch file contents:

REM When using AES256-SHA1 OR AES128-SHA1, the /mapuser option must be included
REM in the ktpass command to ensure the keytab file is mapped properly to the user. For example:
REM ktpass /princ HTTP/!--FQDN--!@!--Kerberos_Realm--! /pass !adpass! /ptype KRB5_NT_PRINCIPAL /mapuser <domain\username> /crypto AES256-SHA1 /out keytabs\kerberos.keytab
REM The following example shows the ktpass syntax with the example.lan configuration from above:
REM ktpass /princ HTTP/!--FQDN--!@!--Kerberos_Realm--! /pass !adpass! /ptype KRB5_NT_PRINCIPAL /crypto DES-CBC-CRC /out keytabs\kerberos.keytab

2. Ensure the Run As User (RAU) properties has the correct checkbox selected based on the type of encryption used above. Encryption options selected in the user record in Active Directory Users and Computers (ADUC) dictate which encryption type should be used in the keytab.
User-added image

Cause

The correct cipher will need to be included in the keytab.

Additional Information

The following information is also important for success. Please work with your Network Team and include a KDC admin to assist with number 4 below:

1. /princ in ktpass needs to be the A-record in the DNS for the url Tableau Server is using.
2. That name and any other DNS aliases need to have associated SPNs (both shortname and fqdn).
3. Forward and reverse lookup needs to work.
4. The cipher in use need to be supported by both the AD account (the Run As User) and the keytab (and not blocked by OS/network settings).

Additional points:

The main thing with the keytab is that the /princ principal needs to be the DNS A-record of the TS url endpoint. So if network changes change that A-record, then the keytab will need to be regenerated.
If network changes add any aliases, those would need to be added as SPNs with setspn.