SAS 9.4 Maintenance 7 has made some minor changes in the Kerberos initialization code designed to make the configuration of constrained delegation easier. However, this change has an impact for the configuration of Kerberos authentication on the server tier (Metadata Server and Object Spawner) on Linux & UNIX. In this article we will look at the problem and ways to mitigate the issue.
Before we start looking at details of the configuration and possible issue, we’ll remind ourselves of some important terms and principles. With Active Directory each object, both computer and user, has a unique referencing attribute of User Principal Name (UPN). The standard format of the UPN is user.name@REALM.COM. Equally, each registered service in Active Directory has a unique reference attribute of Service Principal Name (SPN). The standard format of the SPN is <service_class>/<host>@REALM.COM, for example SAS/metadata.host.com@REALM.COM.
When a service is registered against a user object that user object has a single UPN and one or more SPNs. For Kerberos the long-term key associated with both this user and the services registered against the user is based on the user’s password and a salt. The salt used by Active Directory is the UPN.
With Active Directory Kerberos credentials can only be initialized using the UPN. This means a kinit can only be performed using the UPN and providing the password or long-term key. You cannot initialize credentials with a SPN, attempting to do such will result in a Kerberos error "client not found in kerberos database".
On Linux or UNIX systems the long-term keys for Kerberos are provided using a Kerberos keytab file. The keytab file contains one or more principals, either UPN or SPN, and their associated long-term keys. The long-term keys leverage a supported encryption algorithm such as AES128, AES256, or RC4. So, we might have a single principal in the keytab three times with the three different encryption algorithms.
The Problem
The SAS services on Linux or UNIX are registered against a service account. SAS recommends that such a service account has the UPN set to the same value as the SPN. Then the Kerberos keytab file only needs to contain the SPN and it’s associated long-term keys. Setting up the service account and the Kerberos keytab in such a way causes no problems with SAS 9.4 Maintenance 7 or any previous releases.
However, some customers do not want to set the UPN to the same value as the SPN. So, their service account has the UPN in the standard format of user@REALM.COM. Then the Kerberos keytab might have different content it might contain:
- Just the UPN and associated long-term keys
- Just the SPN and associated long-term keys
- Both the UPN and SPN along with the associated long-term keys
Any of these combinations will have worked correctly for Kerberos authentication in SAS 9.4 up to Maintenance 6, so long as constrained delegation is not used.
With SAS 9.4 Maintenance 7 the SAS process now initializes a Kerberos credential as part of the authentication. As we know this can only be done with the UPN and not the SPN. So, with SAS 9.4 Maintenance 7 if the service account has UPN ≠ SPN the following error will be generated when attempting to authenticate an end-user:
Kerberos failure in function krb5_get_init_creds_keytab: Client 'SAS/metadata.host.com@REALM.COM' not found in Kerberos database
To resolve this we need to tell SAS what principal to use to initialize the credential. The environment variable SAS_SERVICE_PRINCIPAL can be used to define the principal. Edit the <SASCONFIG>/Lev#/level_env_usermods.sh and add
SAS_SERVICE_PRINCIPAL=user@REALM.COM
export SAS_SERVICE_PRINCIPAL
You will need to restart the Metadata Server and Object Spawner.
Setting SAS_SERVICE_PRINCIPAL will be enough if the Kerberos keytab contains either just the UPN or both the UPN and SPN. However, if the Kerberos keytab only contains the SPN then Kerberos authentication will still fail, since the keytab will not contain the long-term keys for the UPN to enable SAS to initialize a Kerberos credential. As such the Kerberos keytab will need to be regenerated to include the UPN.
Alternatively, the customer could change the service account and set the UPN to be the same as the SPN. But, remember the UPN is used by Active Directory as the salt on the long-term keys so changing the UPN will change the long-term keys. Meaning the Kerberos keytab will need to be regenerated.
