SAS Viya 3.4 Kerberos with SAS Logon Manager
This article is a continuation of my previous post which provided an overview of the SAS Viya 3.4 authentication options. This time I’d like to examine in more detail Kerberos with SAS Logon Manager. The process for the configuration has not changed with SAS Viya 3.4, so if you are already familiar with the process from SAS Viya 3.3, it remains the same.
Remember configuring Kerberos authentication for SAS Logon Manager replaces all other browser-based authentication mechanisms. Once Kerberos is configured it is the only mechanism that can be used in the browser to access the SAS Viya 3.4 environment. Other access routes are not impacted, so the Administration Command Line Interface (CLI) will still correctly operate with a username & password validated against the LDAP provider.
Note: With the late 2018 release, SAS Logon Manager changes from validating the username & password with LDAP to using Kerberos. So, a delegated Kerberos credential can be generated through the other access routes. This enables Kerberos delegation for the CLI tools and the SAS Mobile application.
Always ensure LDAP users or groups have been correctly added to the SAS Administrators custom group before configuring Kerberos for SAS Logon Manager.
Before we delve into the details let’s consider what prerequisites must be complete to leverage Kerberos with SAS Logon Manager.
Kerberos Prerequisites
We have four prerequisites that must be completed before we can use Kerberos authentication with SAS Logon Manager. First, we need to setup either the domain service account with Active Directory or the principal with MIT Kerberos. With Active Directory the service account does not need any elevated privileges within Active Directory, this can be a standard user account. This domain service account will not be used to run the actual Linux process. The Linux process can still leverage a local user account.
It does make sense for this service account in Active Directory or principal in MIT Kerberos to have a more generous password policy. It will simplify the on-going management of the environment if the password reset cycle is less restrictive, so that the password does not have to change as often.
Next a Service Principal Name for Active Directory must be registered against the service account. This does not apply to MIT Kerberos since the principal name itself will be the Service Principal Name. The Service Principal Name has the default format of:
HTTP/<fully.qualified.hostname>
The first part of the Service Principal Name "HTTP" is the standard service class used by browsers. The "HTTP" service class is used for both HTTP and HTTPS sites. The hostname should be the fully qualified hostname typed by end-users to access the environment. You need to be aware that browsers will take the name, lookup the ip-address, use the ip-address to resolve a hostname. This final hostname will be the value used by the browser for Kerberos authentication. So, it is this hostname that must be registered.
Once the service account in Active Directory or principal in MIT Kerberos has been created, a Kerberos keytab file can be created. This holds the long-term keys for the service account/principal. The long-term key is related to the password of the service account/principal, so every time the password changes the long-term key changes and so the Kerberos keytab must be updated. The Kerberos keytab is used to provide the long-term keys to the Linux operating system process for SAS Logon Manager.
The long-term keys are generated from the password with different encryption algorithms. For example, AES-128 bit, AES-256 bit, or RC4 encryption algorithms. The stored long-term keys in the Kerberos keytab should match the long-term key used in the Service Ticket that Kerberos authentication will use to authenticate. So, if the end-users might only use a single encryption algorithm, perhaps AES-256 bit, then only a single long-term key is required in the Kerberos keytab. If you are uncertain which long-term key will be used in the Service Ticket, then include as many as possible in the Kerberos keytab.
The Kerberos keytab will need to be placed on the file system of all hosts running the SAS Logon Manager application. There is no default location and the file can be placed anywhere. However, the file will need to be accessible by the operating system account running the Linux process for the SAS Logon Manager, i.e. the "sas" account.
Finally, the service account/principal will need to be configured for delegation or forwarding of Kerberos credentials. This is required if Kerberos will be used to both connect to SAS Logon Manager and from the visual interfaces to either SAS Cloud Analytic Services or SAS Compute Server. For Active Directory environments the delegation properties are only available after a Service Principal Name has been registered against the service account. Currently SAS recommends using unconstrained delegation.
A prerequisite which might need to be completed is the provision of a Kerberos configuration file. SAS Logon Manager will attempt to fetch all required information via DNS records, but this might not provide sufficient information. If the customer has a complex cross-realm structure or to enable forwardable tickets, then a Kerberos configuration file will need to be provided. This can be provided in the default location or a specific file can be identified with the configuration of SAS Logon Manager.
Testing Prerequisites
As you will see below the configuration of SAS Logon Manager to use Kerberos is very straight-forward. Most issues with the configuration will be with the prerequisites. Carrying out some testing of the prerequisites will result is less struggles to implement Kerberos with SAS Logon Manager.
You should test the following items:
- Are the file permission correct on the Kerberos keytab?
- Does the Kerberos keytab contain the correct content?
- Has the Service account been setup correctly and the Kerberos keytab is valid?
- Are the file permission correct on the Kerberos configuration?
The file permissions should enable the sas account read access to both the Kerberos keytab and the Kerberos configuration file, if the Kerberos configuration file is required. The Kerberos keytab should contain the long-term keys for the principal. You can list the contents of the Kerberos keytab with the klist command (either the operating system command on Linux or the Java command on Windows). For example:
klist -ket /opt/sas/http.keytab
Should output:
Keytab name: FILE:/opt/sas/http.keytab
KVNO Timestamp Principal
---- ------------------- ------------------------------------------------------
2 08/21/2018 08:52:35 hostname-HTTP@REALM.COM (arcfour-hmac)
2 08/21/2018 08:52:35 hostname-HTTP@REALM.COM (aes128-cts-hmac-sha1-96)
2 08/21/2018 08:52:35 hostname-HTTP@REALM.COM (aes256-cts-hmac-sha1-96)
2 08/21/2018 08:52:35 HTTP/hostname.domain.com@REALM.COM (arcfour-hmac)
2 08/21/2018 08:52:35 HTTP/hostname.domain.com@REALM.COM (aes128-cts-hmac-sha1-96)
2 08/21/2018 08:52:35 HTTP/hostname.domain.com@REALM.COM (aes256-cts-hmac-sha1-96)
You should also be able to initialize a Kerberos credential using the Kerberos keytab file. Remember, if using Active Directory, you can only initialize the credential for the User Principal Name and not the Service Principal Name. You can initialize credentials with the Kerberos keytab with the kinit command (either the operating system command on Linux or the Java command on Windows). For example, on Linux:
kinit -V -kt /opt/sas/http.keytab hostname-HTTP@REALM.COM
Should output:
Using default cache: /tmp/krb5cc_0
Using principal: hostname-HTTP@REALM.COM
Using keytab: /opt/sas/http.keytab
Authenticated to Kerberos v5
If there are issues with the prerequisites there is no point in attempting the configuration SAS Logon Manager until they are resolved.
Kerberos Configuration for SAS Logon Manager
Kerberos configuration for SAS Logon Manager is completed in SAS Environment Manager. There are no configuration files to edit. With the possible exception of needing to update the content of the Kerberos configuration file. With SAS Environment Manager select Configuration, Definitions and create a new configuration for sas.logon.kerberos. Where the properties are:
| Field | Value |
|---|---|
| debug | On – causes debug messages to be output in log |
| holdOnToGSSContext | On – required to enable Kerberos delegation from SAS Logon Manager |
| keyTabLocation | Uniform Resource Identifier (URI), e.g. file:///opt/sas/http.keytab |
| servicePrincipal | Principal Name from keytab Note: If the environment includes multiple realms, this should include the realm so HTTP/fully.qualified.hostname@REALM |
| stripRealmForGss | On - causes realm to be removed from User Principal |
These settings in SAS Environment Manager look like the following:
| Click images to see a larger version |
The setting "holdOnToGSSContext" is the setting that will cause SAS Logon Manager to store the delegated Kerberos credentials with the Credentials microservice. This will make the delegated Kerberos credentials available for out-bound connections from the visual interfaces. This means that the delegated Kerberos credentials can be used to connect to the SAS Compute Server from SAS Studio 5.1, providing Kerberos delegated authentication to SAS Studio 5.1. Equally the delegated Kerberos credentials can be used for connecting to SAS Cloud Analytic Services. Both these topics will be explored in more details in future posting.
The setting "stripRealmForGss" will be on by default. This setting causes SAS Logon Manager to remove the Kerberos realm from the username obtained from the Kerberos Service Ticket. So, username@REALM becomes username for the search in the Identities microservice to return user and group information. This can be disabled for customers who need to perform this search on the full username@REALM value.
As well as defining the properties for sas.logon.kerberos, it is also necessary to set Kerberos as active. This is also completed in SAS Environment Manager. Select Configuration, All Services, SAS Logon Manager, and then update the settings for spring. The property profiles.active must have kerberos added to the comma separated list. The final setting will look like:
ldap,postgresql,kerberos
Note: The values here are case sensitive and must be all lower case.
This will look like the following in SAS Environment Manager:
Optionally, if a Kerberos configuration file needs to be specified, because it is not in the default location the can also be completed in SAS Environment Manager. Select Configuration, All Services, SAS Logon Manager, and then update the settings for jvm. An additional property can be created to point to the Kerberos configuration file:
Name = java_option_krb5conf
Value = -Djava.security.krb5.conf=/path/to/your/krb5.conf
This will look like the following within SAS Environment Manager:
This completes the configuration for SAS Logon Manager and the operating system process for SAS Logon Manager should be restarted. For example:
systemctl restart sas-viya-saslogon-default
Additional Debugging
If there are issues with the Kerberos configuration for SAS Logon Manager, you might need to collect more effective debugging information. You can collect more information on the Kerberos processing by setting two additional JVM options. Within SAS Environment Manager select Configuration, All Services, SAS Logon Manager, and then update the settings for jvm. Create two new properties:
Name = java_option_debug1
Value = -Dsun.security.krb5.debug=true
Name = java_option_debug2
Value = -Dsun.security.jgss.debug=true
This will look like the following:
You will need to restart the operating system process for SAS Logon Manager for these additional JVM options to be used. For example:
systemctl restart sas-viya-saslogon-default
The additional JVM options will cause SAS Logon Manager to produce a lot more information about reading the Kerberos keytab and processing the Kerberos Service Ticket.
