SAS Viya 3.4 Kerberos with SAS Compute

3 Likes

In this post I would like to follow on from the earlier post where we looked at an overview of the Viya 3.4 authentication options. This time I’d like to examine in more detail Kerberos with the SAS Compute Server. Remember in SAS Viya 3.4 the four components Compute microservice, Launcher microservice, Launcher Server, and Compute Server all work together to launch a SAS session for the end-user. The SAS session that is launched for the end-user is always running on the operating system as the end-user. This process is used from the visual applications in SAS Viya 3.4, such as SAS Studio 5.1 (but not in SAS Studio 4.4).

The key components for our discussion are the Launcher microservice and the SAS Launcher Server. The Launcher microservice performs all the logic and decides how to authenticate to the SAS Launcher Server. The SAS Launcher Server then processes the supplied credentials and launches the SAS Compute session. The SAS Launcher Server just processes what is sent by the Launcher microservice it does not perform any logic itself.

To leverage Kerberos authentication to the SAS Compute Server, SAS Logon Manager must be configured for Kerberos with delegation. The delegated Kerberos credentials must be stored by the Credentials microservice. It must be noted that SAS Visual Investigator 10.4 does not include the Credentials microservice, so Kerberos delegation will not work. However, if SAS Visual Investigator 10.4 is included with SAS Visual Analytics or another solution the Credentials microservice will be included. This will then enable Kerberos delegation.

Before we delve into the details let’s consider what prerequisites must be complete to leverage Kerberos with SAS Compute Server.

Kerberos Prerequisites

We have four prerequisites that must be completed before we can use Kerberos authentication with SAS Compute Server. 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:

sas-launcher/<fully.qualified.hostname>

The first part of the Service Principal Name "sas-launcher" is what SAS Launcher microservice expects as the service class.

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 Launcher Server.

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 include as many as possible in the Kerberos keytab.

The Kerberos keytab will need to be placed on the file system of any hosts where the SAS Launcher Server is running. There is no default location and the Kerberos keytab can be placed anywhere on the file system. The file only needs to be accessible by the operating system account running the Linux process for the SAS Launcher Server, 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 Compute Server and from SAS Compute Server to a downstream data source such as Secured Hadoop. 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.

Testing Prerequisites

As you will see below the configuration of SAS Launcher & Compute 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 Launcher.

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?

The file permissions should enable the sas account read access to the Kerberos keytab. 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/saslauncher.keytab

Should output:

Keytab name: FILE:/opt/sas/saslauncher.keytab
KVNO Timestamp           Principal
---- ------------------- ------------------------------------------------------
   2 08/21/2018 08:52:35 hostname-sas-laun@REALM.COM (arcfour-hmac)
   2 08/21/2018 08:52:35 hostname-sas-laun@REALM.COM (aes128-cts-hmac-sha1-96)
   2 08/21/2018 08:52:35 hostname-sas-laun@REALM.COM (aes256-cts-hmac-sha1-96)
   2 08/21/2018 08:52:35 sas-launcher/hostname.domain.com@REALM.COM (arcfour-hmac)
   2 08/21/2018 08:52:35 sas-launcher/hostname.domain.com@REALM.COM (aes128-cts-hmac-sha1-96)
   2 08/21/2018 08:52:35 sas-launcher/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/saslauncher.keytab hostname-sas-laun@REALM.COM

Should output:

Using default cache: /tmp/krb5cc_0
Using principal: hostname-sas-laun@REALM.COM
Using keytab: /opt/sas/saslauncher.keytab
Authenticated to Kerberos v5

If there are issues with the prerequisites there is no point in attempting the configuration SAS Launcher until they are resolved.

Kerberos Configuration for SAS Launcher

There are two steps to complete the configuration of Kerberos authentication for the SAS Launcher microservice and Server. First the configuration property in SAS Environment Manager must be set. This property is shared with SAS Cloud Analytic Services, so if SAS Cloud Analytic Services has been configured for Kerberos this will have already been completed.

In SAS Environment Manager select Configuration, Definitions, and select sas.compute. Update the configuration and set kerberos.enabled to true. This is required for the SAS Launcher Server to leverage Kerberos authentication.

Next a configuration option must be set that points to the Kerberos keytab for the SAS Launcher Server. With SAS Viya 3.4 there is no way to set this within SAS Environment Manager. So, the property must be set in the SAS Configuration Server using the SAS Bootstrap Config tool. To use the SAS Bootstrap Config tool several environment variables, need to be set in the current session. To set the environment variables run the following two commands:

source /opt/sas/viya/config/consul.conf
export CONSUL_TOKEN=`cat /opt/sas/viya/config/etc/SASSecurityCertificateFramework/tokens/consul/default/client.token`

With the environment variables set the SAS Bootstrap Config tool can be used to set the configuration property:

/opt/sas/viya/home/bin/sas-bootstrap-config kv write --force --key config/launcher-server/global/keytab --value path-to-keytab-file

Where the path-to-keytab-file is the full path to the Kerberos keytab file.

This completes the configuration of the SAS Launcher Server for Kerberos authentication and the operating system process can be restarted:

systemctl restart sas-viya-runlauncher-default

Authentication to SAS Compute

As a reminder in the previous post on SAS Viya 3.4 Authentication Options we presented the following diagram:

Click image to see a larger version

So, we have three possible outcomes after configuring Kerberos for the SAS Compute Server:

Kerberos delegation is used to authenticate to the SAS Launcher Server
Username & Password are used to authenticate to the SAS Launcher Server
The Launcher microservice is unable to launch a session

In the third case an error will be presented to the end-user. For example, in SAS Studio 5.1 the center of the interface will contain a message stating that the session could not be launched.

It is important to realize that sessions will fail to launch. Remember, from our examination of the configuration of SAS Cloud Analytic Services with Kerberos, the configuration setting for sas.compute of kerberos.enabled is shared by both SAS Cloud Analytic Services and SAS Compute Server. So, configuring SAS Cloud Analytic Services for Kerberos and not configuring anything for SAS Compute Server will result in failures.

The ideal scenario, with Kerberos delegation, is depicted here:

Click image to see a larger version

The end-user uses Kerberos delegation to authenticate to SAS Logon Manager. SAS Logon Manager stores the delegated Kerberos credential with the Credentials microservice. The SAS Launcher microservice fetches the delegated Kerberos credential and uses this to authenticate to the SAS Launcher Server. The SAS Launcher Server uses the Kerberos keytab to validate the Service Ticket presented by the SAS Launcher microservice. This authenticates the end-user and the SAS Compute Server session is launched. The end-user’s Kerberos credentials are delegated again to the SAS Compute Server since the SAS Launcher principal is "trusted for delegation". With the end-user’s delegated Kerberos credentials available to the SAS Compute Server session out-bound connects to downstream data sources can use Kerberos for authentication.

Alternatively, if the delegated credentials are not available, for example if the browser is not configured for delegation, then an attempt will be made to use a username & password. With SAS Viya 3.4 a username & password can be stored in the DefaultAuth authentication domain (where the name DefaultAuth can be changed if necessary). The credentials in DefaultAuth can be managed individually by end-users or by an administrator for a group.

The username & password from DefaultAuth are used by the SAS Launcher microservice to connect to the SAS Launcher Server. The SAS Launcher Server validates the username & password through the Pluggable Authentication Module (PAM) configuration on the host. If the PAM configuration incorporates Kerberos, the PAM transaction will initialize Kerberos credentials for the given username & password. These Kerberos credentials will be available to the SAS Compute Server session.

Kerberos Authentication from SAS Compute

Now that we have reviewed using Kerberos authentication to launch the SAS Compute Server session, let’s move onto the real aim of the setup: using Kerberos to access downstream data sources. Most customers are more concerned with the access to the data sources than they are about how internally the SAS process is launched. For example, with a Secured Hadoop environment the only way to access the data from a SAS Compute Server session will be through using Kerberos.

We have three possible ways in which the SAS Compute Server session was launched:

Direct launch with the internal OAuth token
Kerberos Delegation
Username & password from the Credentials microservice

If the SAS Compute Server session was launched using just the internal OAuth token, then the SAS Launcher Server was not able to authenticate the end-user on the operating system. This means that there will be no Kerberos credentials available to the SAS Compute Server session. Which means there is no way to use Kerberos authentication to reach the downstream data sources.

If the SAS Compute Server session was launched with Kerberos delegation then, so long as the principal for the SAS Launcher Server is "trusted for delegation", the end-user’s Kerberos credentials will be delegated. These delegated Kerberos credentials will be available to the SAS Compute Server session and can be used to access the downstream data source.

Finally, if the username & password retrieved from the Credentials microservice were used by the SAS Launcher Server to authenticate the end-user through PAM, it will all be dependent on the PAM configuration. If the PAM configuration includes Kerberos this will initialize a Kerberos credential as the end-user is authenticated.

One complication with the use of PAM is that the SAS Launcher Server does not pass the Kerberos Ticket Cache environment variable, KRB5CCNAME, to the SAS Compute Server session. This can result in the Kerberos credentials being initialized, but the connection to the downstream data source being unable to find them. The recommend approach to work around this issue is to ensure the correct default location is used for the Kerberos Ticket Cache.

For example, if the PAM system is setup with System Services Security Daemon (SSSD) the administrator will need to define the following in the Kerberos configuration file (/etc/krb5.conf😞

default_ccache_name = FILE:/tmp/krb5cc_%{uid}

And define the following options in the SSSD configuration file (/etc/sssd/sssd.conf😞

krb5_ccachedir = /tmp
krb5_ccname_template = FILE:%d/krb5cc_%U

This will result in the Kerberos Ticket Cache being:

/tmp/krb5cc_<uid>

This Kerberos Ticket Cache location will then be correctly picked up by the Hadoop client for the Kerberos connection to Secured Hadoop.