SAS Viya 3.5 Multi-Tenant Kerberos Constrained Delegation

1 Like

SAS Viya 3.5 introduced support for Kerberos Constrained Delegation which we have discussed before. Also previously for SAS Viya 3.4 we have discussed Kerberos with multi-tenant deployments. In this blog I want to bring the multi-tenant discussion up to date by looking at Kerberos constrained delegation in a Viya 3.5 multi-tenant environment. Also, I want to touch on using RedHat Identity Management (IdM) or FreeIPA as an alternative to Active Directory in such a scenario.

First a reminder of some standard principles:

Kerberos authentication is supported in multi-tenant environments, but only configured via the provider. The settings in the provider apply to all the individual tenants. So, Kerberos is all or nothing.
SAS Logon Manager is tenant aware and end-users connect to tenant using the tenant ID in the URL, which has the form http://<tenantID>.<sasviya_hostname>. This means the browser will ask for a service ticket for HTTP/<tenantID>.<sasviya_hostname>.
The principals for SAS Launcher Server and SAS Cloud Analytic Services do not contain the tenant ID. The tenant specific services are identified by the port number the separate processes listen on.
With SAS Logon Manager the provider and individual tenants can fall-back to other authentication mechanisms.
Kerberos constrained delegation requires the use of S4U2SELF and S4U2PROXY requests. Most importantly the microservice layer will use S4U2SELF to obtain initial credentials as the end-user before using S4U2PROXY to obtain credentials for the target service.
The sas.logon.kerberos settings are applied to all services, this ensures the configuration options are available to the microservice layer to perform S4U2SELF.
S4U2SELF requests from the microservice layer use the sas.logon.kerberos.principal value in the request for initial credentials.

Now that we have been reminded of these principles, we can consider how Kerberos constrained delegation can be configured in a SAS Viya 3.5 multi-tenant environment.

Principal Requirements

For multi-tenant environments the principal that will be different to a non multi-tenant environment is the HTTP Principal. We require a HTTP principal for the provider and each tenant. Also, we know that the SAS Logon Manager configuration settings only allow us to specify a single principal. Previously, we were able to set the sas.logon.kerberos.principal value to "*" to account for the different provider and tenant principals that would connect to SAS Logon Manager.

However, with SAS Viya 3.5 and constrained delegation we know that the sas.logon.kerberos.principal value will be used by the microservice layer to perform the S4U2SELF requests. We cannot request a service ticket for *@<CUSTOMERREALM.COM> and therefore we cannot set sas.logon.kerberos.principal to "*". We must set sas.logon.kerberos.principal to a valid value. It makes sense to set sas.logon.kerberos.principal to the HTTP principal for the provider, so the recommended value would be HTTP/<sasviya_hostname>.

Setting sas.logon.kerberos.principal to the HTTP principal for the provider means that SAS Logon Manager will only load the long-term keys for this principal from the Kerberos keytab. To be able to authenticate end-users presenting a service ticket for a tenant this long-term key must match the long-term key used in the service ticket. The long-term key is generated from the password associated with the principal and a salt. The salt used by Active Directory is the User Principal Name and the salt used by MIT Kerberos is the principal name. So, to be able to authenticate to SAS Logon Manager for each tenant the long-term key for each tenant principal must match the provider principal long-term key. With Active Directory this just requires that all the Service Principal Names are registered against a single service account. We will discuss MIT Kerberos in a later section.

User Principal Names

With Active Directory a user object has two principal name properties. The first is the User Principal Name (UPN), which must be single valued and unique. The second is the Service Principal Name (SPN) property which can contain several different entries, where each entry must be unique. The statement above about setting sas.logon.kerberos.principal to the HTTP principal for the provider only holds so long as the UPN in Active Directory is the same as the SPN.

Active Directory will only allow the initialization of Kerberos credentials for the UPN or assumed UPN which is sAMAccountName@REALM.COM. In some cases, the actual value of the UPN property in Active Directory will not match any Kerberos realms, for example this might be the Office365 email address. Then the assumed UPN value must be used to initialize Kerberos credentials. Therefore, if the UPN is not the same as the SPN the value of sas.logon.kerberos.principal must be changed to the UPN. Otherwise the microservice layer will not be able to initialize the credentials required for the S4U2SELF request.

Keytab Requirements

Now that we’ve considered the principal requirements and user principal names, we can state what we require in the Kerberos keytab. Since we will set sas.logon.kerberos.principal to a single value we only require a single entry in the keytab. The entry in the keytab will match the value of sas.logon.kerberos.principal, since when the microservice layer initializes a credential a matching long-term key must be fetched from the keytab. For Active Directory this will be the UPN value, even if the UPN is the same as the SPN. As we’ve already explored the same long-term key must be used for all tenant principals and the provider principal and so we only need the single entry in the keytab.

Alternative KDC Implementations

In most cases customers will use Active Directory as their KDC, but alternatives are available. The most common alternative is MIT Kerberos. With MIT Kerberos the database does not distinguish between user and service principals. Everything in the Kerberos database is just a principal. Since there is no higher-level object to contain the principal objects.

This presents some challenges with Kerberos constrained delegation and multi-tenancy. By default, MIT Kerberos uses the principal name as the salt for the long-term key. This means that the long-term keys will be different for the provider and tenants HTTP principals. The supported salt types are:

normal	default for Kerberos Version 5
v4	the only type used by Kerberos Version 4 (no salt)
norealm	same as the default, without using realm information
onlyrealm	uses only realm information as the salt
afs3	AFS version 3, only used for compatibility with Kerberos 4 in AFS
special	generate a random salt

This means for our case of Kerberos constrained delegation with multi-tenancy we want to use the onlyrealm salt type. This will ensure that if the same password is used for all the HTTP principals the same long-term key is generated. Rather than changing the default list for all principals with the kdc.conf file the kdamin command can be passed the "-e" option to set the keysalt list to be used for any new keys created. For example:

kadmin -e aes256-cts:onlyrealm,aes128-cts:onlyrealm 
-q "addprinc +ok_to_auth_as_delegate HTTP/<sasviya_hostname>@REALM"

RedHat Identity Management (IdM) & FreeIPA are built upon MIT Kerberos and other technology. However, with RHEL IdM kadmin is no-longer used to generate principals. Instead the command ipa-generatekeytab both generates the keytab and creates the Kerberos principal. To be able to have the provider and tenant HTTP principals use the same long-term key a different approach is required.

In the GUI for RedHat Identity Management it is possible to associate Principal aliases to a service. This enables something more like Active Directory in that all the principal values are then associated with a single object and will have the same long-term key. The screenshot below illustrates an example with a provider principal of HTTP/sasviya01.gellab.net and tenant principals of HTTP/dev.sasviya01.gellab.net, HTTP/test.sasviya01.gellab.net, and HTTP/prod.sasviya01.gellab.net.

Select any image to see a larger version.
Mobile users: To view the images, select the "Full" version at the bottom of the page.

Then the following command can be used to generate both the keytab and Kerberos principals:

ipa-getkeytab -p HTTP/sasviya01.gellab.net -k /tmp/http.keytab

Conclusion

You have now seen the key considerations for configuring Kerberos constrained delegation with SAS Viya 3.5 multi-tenant environments. The configuration of SAS Viya 3.5 itself is simple – the complexity lies in correctly configuring the principals and Kerberos keytabs. As with any Kerberos setup the debugging we discussed before can be very helpful in understanding where your issues are occurring.