SAS Viya 3.4 Kerberos with CAS
In this article, I would like to follow on from my previous post, SAS Viya 3.4 Kerberos with SAS Logon Manager. This time I’d like to examine in more detail Kerberos with SAS Cloud Analytic Services. This includes using Kerberos to authenticate to SAS Cloud Analytic Services and using Kerberos from within the CAS session. Remember that for Kerberos delegation from the visual interfaces SAS Logon Manager must also be configured for Kerberos authentication.
Kerberos delegation from visual interfaces relies upon both the Kerberos configuration for SAS Logon Manager and storing delegated Kerberos ticket with 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 8.3 or another Viya 3.4 solution, then the Credentials microservice will be included which will enable Kerberos delegation.
Before we delve into the details let’s consider what prerequisites must be complete to leverage Kerberos with SAS Cloud Analytic Services.
Kerberos Prerequisites
We have four prerequisites that must be completed before we can use Kerberos authentication with SAS Cloud Analytic Services. 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 does not have to 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:
sascas/<fully.qualified.hostname>
The first part of the Service Principal Name "sascas" is what SAS Cloud Analytic Services expects as the service class. This can be customized if for some reason the customer is unable to use "sascas" as the service class. We will address how a different principal can be used when we examine the configuration options.
With Active Directory we have an additional consideration with respect to principal names. Within Active Directory there are two principal name properties for each user object. There is the multi-valued Service Principal Name property which we have just discussed. In addition, there is a single-valued property for the User Principal Name. The User Principal Name will be used when initializing Kerberos credentials for the service account. SAS recommends that the User Principal Name property is set to the same value as the Service Principal Name. Some customers will not want to set the User Principal Name to the same value as the Service Principal Name, and we will discuss this below when detailing the configuration options.
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 Cloud Analytic Services.
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 just the SAS Cloud Analytic Services controller. The default expected location of the file is:
/etc/sascas.keytab
This can be changed in the configuration which we will examine shortly. Also, the file should only be accessible by the operating system account running the Linux process for the SAS Cloud Analytic Services controller. By default, this will be the "cas" account, but a different account could be used at deployment time, or the account changed as part of a multi-tenancy configuration.
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 Cloud Analytic Services and from SAS Cloud Analytic Services 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 Cloud Analytic Services 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 Cloud Analytic Services.
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 cas account, or whichever operating system account is running the SAS Cloud Analytic Services controller, 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 /etc/sascas.keytab
Should output:
Keytab name: FILE:/etc/sascas.keytab
KVNO Timestamp Principal
---- ------------------- ------------------------------------------------------
2 08/21/2018 08:52:35 hostname-sascas@REALM.COM (arcfour-hmac)
2 08/21/2018 08:52:35 hostname-sascas@REALM.COM (aes128-cts-hmac-sha1-96)
2 08/21/2018 08:52:35 hostname-sascas@REALM.COM (aes256-cts-hmac-sha1-96)
2 08/21/2018 08:52:35 sascas/hostname.domain.com@REALM.COM (arcfour-hmac)
2 08/21/2018 08:52:35 sascas/hostname.domain.com@REALM.COM (aes128-cts-hmac-sha1-96)
2 08/21/2018 08:52:35 sascas/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 /etc/sascas.keytab hostname-sascas@REALM.COM
Should output:
Using default cache: /tmp/krb5cc_0
Using principal: hostname-sascas@REALM.COM
Using keytab: /etc/sascas.keytab
Authenticated to Kerberos v5
If there are issues with the prerequisites there is no point in attempting the configuration SAS Cloud Analytic Services until they are resolved.
Kerberos Configuration for CAS
The configuration for Kerberos authentication is completed in two areas; via configuration files and via SAS Environment Manager. Both areas must be completed to configure Kerberos authentication for all types of use.
The configuration file settings for Kerberos can be manually entered into the following file:
/opt/sas/viya/config/etc/cas/default/casconfig_usermods.lua
Or these can be placed in the vars.yml and the deployment playbook re-run. When the settings are made via the vars.yml the settings will automatically appear in the following file:
/opt/sas/viya/config/etc/cas/default/casconfig_deployment.lua
The settings are:
- Update the cas.provlist to include kerb
a. In casconfig_usermods.lua this will be: cas.provlist = 'oauth.ext.kerb'
b. In vars.yml this will be under cfg: section and should be: provlist: 'oauth.ext.kerb' - (Optional) set the server principal
a. In casconfig_usermods.lua this will be: env.CAS_SERVER_PRINCIPAL = 'CAS/HOSTNAME.COMPANY.COM'
b. In vars.yml this will be under env: section and should be: CAS_SERVER_PRINCIPAL: 'CAS/HOSTNAME.COMPANY.COM' - (Optional) set the Kerberos keytab location
a. In casconfig_usermods.lua this will be: env.KRB5_KTNAME = '/opt/sas/cas.keytab'
b. In vars.yml this will be under env: section and should be: KRB5_KTNAME: '/opt/sas/cas.keytab'
It is necessary to make these changes to the configuration files to enable Kerberos authentication from SAS Cloud Analytic Services. But that is not sufficient to also allow Kerberos authentication into SAS Cloud Analytic Services from visual interfaces.
Two additional tasks must be completed in SAS Environment Manager to complete the configuration of Kerberos for SAS Cloud Analytic Services. First the configuration option must be specified that informs SAS Cloud Analytic Services that Kerberos authentication is configured. The option kerberos.enabled must be set to true. This can be found in the configuration section of SAS Environment Manager under Definitions, and under sas.compute. Equally this configuration setting can be specified in the sitedefault.yml during the deployment. To set the option using the sitedefault.yml add the following:
config:
application:
sas.compute:
kerberos.enabled: true
Remember: spacing is important in the sitedefault.yml and the tab character should never be used.
This configuration setting is shared with the SAS Launcher & Compute Server. We will discuss the full implications of setting this in a future posting. But at a high-level you want to configure Kerberos authentication for the whole SAS Viya 3.4 environment together.
The second task to complete in SAS Environment Manager is the creation of the custom group. For SAS Cloud Analytic Services to attempt to run the session as the end-user, the end-user must be a member of a custom group. The name of the custom group is not important and can be anything. The ID of the custom group must be CASHostAccountRequired. Without membership in this group the SAS Cloud Analytic Services session will be launched as the operating system account running the SAS Cloud Analytic Services controller. By default, this will be the "cas" account, but this can be changed at deployment or will be different in a multi-tenancy environment.
This completes the configuration changes for SAS Cloud Analytic Services. The operating system process for SAS Cloud Analytic Services Controller must be restarted to pick up the changes.
systemctl restart sas-viya-cascontroller-default
Kerberos Authentication to CAS
With the configuration above complete and the correct configuration of SAS Logon Manager for Kerberos authentication, Kerberos delegation can be used from the SAS Viya 3.4 visual interfaces. This is the scenario discussed in the SAS Viya 3.4 Authentication Overview article, shown in the following diagram:
| Click images to see a larger version |
Kerberos is used from the end-user’s browser to authenticate to SAS Logon Manager. Since the principal for SAS Logon Manager is "trusted for delegation" this connection also includes the delegated credentials for the end-user. The delegated credentials are stored in the Credentials microservice. Then when a connection is made to SAS Cloud Analytic Services, it checks three items; membership of the CASHostAccountRequired group and the presence of the kerberos.enabled configuration option, and the stored Kerberos credentials. With all three in place Kerberos is used to authenticate to the SAS Cloud Analytic Services Controller.
Since the principal for SAS Cloud Analytic Services is also "trusted for delegation" the end-user’s credentials are delegated again to the session that is launched. Finally, now the SAS Cloud Analytic Services session is running as the end-user with their delegated credentials Kerberos connections can be made to third-party data sources such as Secured Hadoop.
The other client which can leverage the Kerberos delegation configuration is SAS 9.4 Maintenance 5. As shown below:
In this scenario since all components of both SAS 9.4 M5 and SAS Viya have been configured for Kerberos, and all principals are "trusted for delegation", Kerberos can be used through-out.
Kerberos Authentication from CAS
So far, we have addressed authenticating to SAS Cloud Analytic Services using Kerberos. But for most customers the real aim is to provide Kerberos authentication to the connection out to their data sources.
There are three broad categories of how end-users authenticate to SAS Cloud Analytic Services that impacts how out-bound Kerberos credentials are made available to their session. These three categories are:
- Kerberos Delegation, as addressed above
- Username & Password
- Internal OAuth
Username & Password authentication to SAS Cloud Analytic Services with Viya 3.4 can occur in the following cases:
- Connections from programming clients such as SAS Studio 4.4
- Connections from SAS 9.4 M5 clients using username & password
- Connections from visual interfaces with stored username & password
The first two connections were available in previous SAS Viya releases and should be familiar now. The client sends the username & password to the SAS Cloud Analytic Services controller, which uses the Pluggable Authentication Module (PAM) configuration to validate the credentials and launches the session. So long as the PAM configuration is integrated with Kerberos, the end-user Kerberos credentials will be generated by PAM and made available to the SAS Cloud Analytic Services session.
The third connection is new for SAS Viya 3.4. With SAS Viya 3.4 a username & password can be stored in the Credentials microservice against an authentication domain. This username & password set can then be used to authenticate to SAS Cloud Analytic Services, when the end-user is in the CASHostAccountRequired custom group. The default name for the authentication domain is DefaultAuth, this can be changed but requires a restart of the SAS Cloud Analytic Services controller. The username & password can be managed individually by each end-user through SAS Environment Manager or for a group by an administrator in SAS Environment Manager.
The username & password retrieved from the Credentials microservice are used to connect to SAS Cloud Analytic Services in the same way as any other username & password. They are validated through PAM and if PAM establishes a Kerberos credential this will be available to the SAS Cloud Analytic Services session.
Retrieving a username & password from the Credentials microservice enables end-users in the visual interfaces, such as SAS Studio 5.1, to start SAS Cloud Analytic Services sessions as themselves with valid Kerberos credentials. Otherwise these end-users would need to rely on the final method of connecting with the internal OAuth token.
Connecting with the internal OAuth token means that SAS Cloud Analytic Services has no information to authenticate the end-user. All that is available from the OAuth token is the username, and the fact that they have already authenticated in some manner to SAS Logon Manager. If the end-user is not in the CASHostAccoutRequired custom group, the SAS Cloud Analytic Services session will be launched as the operating system account running the controller. By default, this will be the "cas" account. The SAS Cloud Analytic Services controller will then initialize Kerberos credentials for the sascas principal using the Kerberos keytab. Both the session and any connection to downstream data sources will be as the CAS account. This is the default behavior for end-users leveraging the visual interfaces.
If the end-user is in the CASHostAccoutRequired custom group, then the SAS Cloud Analytic Services controller will directly launch a session using the username from the internal OAuth token. Since the end-user was not authenticated by SAS Cloud Analytic Services there are no Kerberos credentials available to the session. Therefore, there is no ability to connect from the SAS Cloud Analytic Services session to a downstream data source.
The table below summarizes the information in this section. The table shows the client, how the client authenticated to SAS Cloud Analytic Servers, what provides the out-bound Kerberos credential, and who any downstream access is performed as.
| Client | Authenticated By | Out-bound Credential Provided By | Access As |
|---|---|---|---|
| SAS Viya – Visual Interface | Kerberos | Delegation | End-User |
| SAS Viya – Visual Interface | OAuth | Keytab | Service Account |
| SAS Viya – Visual Interface | OAuth | Stored Credentials | End-User |
| SAS Viya – Programming Interface | Username/Password | PAM | End-User |
| SAS 9.4 | Kerberos | Delegation | End-User |
| SAS 9.4 | Username/Password | PAM | End-User |
| SAS 9.4 | One-Time-Password | Keytab | Service Account |
Hello @AndyWilliams86 & @JuanS_OCS,
I’d like to take some time to present some additional information on some of the further Kerberos related topics. If you’d like further information beyond this please keep an eye out for my paper “Extending the Reach of Kerberos Authentication from SAS® Viya® 3.4 to Apache Hadoop” at SAS Global Forum this year, and if you are attending in person please come by the Quad and say hello.
At the time of this writing, there is a software bug that prevents this from working completely as designed. The fix has been identified and is being packaged – watch the Hot fix Announcements board for availability. If you need more proactive tracking of issues please work with SAS Technical Support who can look at your environment in much closer detail.
Scheduling
Scheduling within an environment configured for Kerberos authentication presents challenges. Kerberos tickets, by design are only valid for relatively short periods of time. Kerberos defines two lifetimes for a given ticket, the current lifetime of the ticket, and if configured with the Key Distribution Center (KDC) a renewable lifetime. A ticket still within its initial lifetime can be renewed up to its renewable lifetime. Once the renewable lifetime has expired, the end-user must authenticate again. Not all tickets are renewable, in which case they expire as soon as the ticket lifetime expires.
If we consider Microsoft Active Directory, by default your user’s Kerberos Ticket-Granting Ticket (TGT) will be valid for 10 hours and can be renewed for 7 days. So, if you log into your SAS Viya 3.4 environment at 9am and schedule a task to run every day at 9pm, you can see that you would expect to have issues. Even the first run of the task is going to take place 12 hours after you logged in, so your TGT will have expired before the task is run.
SAS provides a couple of technologies to assist with the expiring credentials. First, so long as you remain logged into the SAS Viya 3.4 visual interfaces your Kerberos credentials are refreshed. The keep alive messages triggered by the different visual interfaces, such as SAS Environment Manager or SAS Visual Analytics, trigger re-authentication to SAS Logon Manager. This means that the stored TGT is refreshed if you are logged in. So, in our example above if you stay logged in until 5pm, your TGT will now be valid for running that task at 9pm.
But what about the weekends or when you take vacation. The other technology SAS provides is the ability for SAS Cloud Analytic Services and the SAS Launcher Server to fallback to using a username & password. This username & password are not prompted for; they must be stored before-hand. The username & password are stored in an Authentication Domain in SAS Environment Manager, by default called DefaultAuth. This username & password could be stored individually for a user or associated with a group and made available to all members of the group. Only one username & password set should be available to a given user. This authentication flow is illustrated here:
Finally, for a SAS Viya 3.4 environment on Linux, SAS Cloud Analytic Services can also fall back to directly launching the session. This session, for your users who are members of CASHostAccountRequired, will not have access to any Kerberos credentials and so cannot access your secured third-party data source. However, it will be able to access data already loaded into memory, which is useful for running scheduled reports.
Therefore, you can see scheduling adds complexity to the Kerberos configuration, but does not become impossible. You just need to carefully plan who will be able to schedule depending on what they need access to.
SAS Administration CLI & SAS Visual Analytics App
With either SAS Viya 3.4 on Windows or the September 2018 release of SAS Viya 3.4 on Linux, Kerberos can be used with both the SAS Administration Command-Line Interface (CLI) and the SAS Visual Analytics App on mobile devices. Even when SAS Logon Manager is configured for Kerberos authentication, both applications still allow for connections using username & password. This is due to these applications accessing a different end-point of SAS Logon Manager that is not secured with Kerberos. However, when a connection is made using a username & password, SAS Logon Manager initializes a Kerberos credential for your end-user. This Kerberos credential is then stored with the Credentials microservice, and is available for further connections, for example to SAS Cloud Analytic Services.
In addition, the latest version of the SAS Administration CLI, available here: https://support.sas.com/downloads/package.htm?pid=2133, can also use Kerberos authentication for logging into your SAS Viya 3.4 environment. Kerberos support for logging in with the SAS Administration CLI is split based on the execution platform (Windows, Linux, OS-X):
- The Windows support utilizes the Windows SSPI via system calls.
- The Linux support utilizes a GSSAPI implementation using CGO to call the underlying GSSAPI C libraries.
- The direct OS-X support is currently disabled.
If you will run the SAS Administration CLI from a Linux host, the correct underlying GSSAPI C libraries must be installed. On a RedHat system this can be completed with the following command as root:
yum install -y krb5-devel
which will provide the /usr/lib64/libgssapi_krb5.so library. On a SUSE system this can be installed with the following command as root:
zypper install krb5
This provides the necessary infrastructure for the SAS Administration CLI to leverage Kerberos for authentication. Before using the SAS Administration CLI that you have downloaded, you need to install the CLI plug-ins and setup the profile. These steps are covered in detail in the documentation. Even if using the SAS Administration CLI on a Linux host where the original version has been run you must still set up the profile again.
Using Kerberos authentication to log into the SAS Administration CLI requires that you change the initial command to log into the SAS Viya 3.4 environment. You must use the following:
./sas-admin auth kerberos
You should see the following message:
Login succeeded. Token saved.
If you include --verbose on the command, you can review the HTTP requests/responses sent to SAS Logon Manager. You will then see the 401 HTTP response from the request to SAS Logon Manager with the Www-Authenticate: Negotiate header, notice this GET request is to /SASLogon. Alternatively, when using username & password the command line is:
./sas-admin auth login
Again, including --verbose, now shows a POST message sent to /SASLogon/oauth/token after entering your username & password.
Hopefully this gives you a better understanding of the use of Kerberos authentication, especially in conjunction with scheduling. As mentioned, if you have more questions specific to your environment, please feel free to contact SAS Technical Support.
Thank you
Stuart
