The SAS Object Spawner that is part of the SAS Viya 3.5 environment supports SAS Studio 5.2 (Basic) and direct connections from SAS Enterprise Guide 8.2. Direct connections from SAS Enterprise Guide 8.2 provides a stop-gap solution for customers who are not able yet to fully move to the web-based SAS Studio 5.2 (Enterprise). SAS Studio 5.2 (Basic) only supports authentication to the Object Spawner with a username & password. SAS Enterprise Guide 8.2 can also use Kerberos as well as username & password. In this blog we’ll look at what is necessary to use Kerberos from SAS Enterprise Guide 8.2 to the SAS Viya 3.5 Object Spawner.
For more information on the basic setup of direct connections from SAS Enterprise Guide 8.2 to SAS Viya 3.5, see this post from @EdoardoRiva. Remember the strategic direction for SAS is to move towards SAS Studio. Leveraging direct connections from SAS Enterprise Guide 8.2 is a stop-gap measure for customers who are unable to fully utilize SAS Studio in the current release.
With SAS Viya 3.5 both unconstrained and constrained delegation are supported with the Object Spawner. In this blog we will address both use-cases.
Prerequisites
To be able to use Kerberos with the SAS Viya 3.5 Object Spawner the SAS Service Principal Name (SPN) must be registered. If using MIT Kerberos Key Distribution Center (KDC) this is just registered as a principal. If using Active Directory as the KDC it becomes more complex. For Linux deployments the SPN must be registered against a user object, a service account. For Windows deployments the SPN will be automatically registered against the computer object where SAS Viya 3.5 Object Spawner is running.
The SPN has the standard format of SAS/<fully.qualified.hostname>. A custom SPN can be used but additional configuration is required for SAS Viya, detailed below. For Linux using Active Directory the best practice is to set the user object’s User Principal Name (UPN) to the same value as the SPN. However, some customers do not allow the UPN to be the same as the SPN; again, additional configuration is required if the UPN is not the same as the SPN.
With Linux deployments a Kerberos Keytab file is required for the SAS principal. This should contain all the possible long-term keys that might be used in Service Tickets to connect to the SAS Viya 3.5 Object Spawner. If the UPN is different to the SPN, then the keytab should either contain just the UPN or both the UPN and SPN values with the UPN listed first. Here is an example with both the UPN and SPN contained in the Kerberos Keytab file:
Keytab name: FILE:/opt/sas/sas.keytab
KVNO Timestamp Principal
---- ------------------- ------------------------------------------------------
0 01/28/2020 12:53:47 sas-services@REALM.COM (arcfour-hmac)
0 01/28/2020 12:53:47 sas-services@REALM.COM (aes128-cts-hmac-sha1-96)
0 01/28/2020 12:53:47 sas-services@REALM.COM (aes256-cts-hmac-sha1-96)
0 01/28/2020 12:53:47 MYSAS/my_sas_server.com@REALM.COM (arcfour-hmac)
0 01/28/2020 12:53:48 MYSAS/my_sas_server.com@REALM.COM (aes128-cts-hmac-sha1-96)
0 01/28/2020 12:53:48 MYSAS/my_sas_server.com@REALM.COM (aes256-cts-hmac-sha1-96)
Remember the principal name is used as the salt for the encryption algorithm that generates the long-term key from the account password. Therefore, if the principal name is different the long-term key will be different.
To be able to use Kerberos authentication from the SAS Workspace Server launched by the SAS Object Spawner to data sources and SAS Cloud Analytic Services, the SAS principal must be trusted for delegation. If the principal is trusted for delegation to any service, this is unconstrained delegation. If the principal is trusted for delegation to specified services, this is "Traditional" Constrained Delegation. If the constraints for delegation are placed on the target services, this is Resource-Based Constrained Delegation. See my previous post for more details on Constrained Delegation.
Encryption Issues
SAS Viya 3.5 introduced Transport Layer Security (TLS) for the SAS Object Spawner. This is configured by default on Linux full-deployments using the SAS Secrets Manager. TLS can be manually configured for Linux programming-only deployments or Windows deployments. When TLS is enabled the process for launching the SAS Workspace Server by the SAS Object Spawner is changed. TLS requires a second authenticated connection from the SAS Object Spawner to the SAS Workspace Server as part of the launch, rather than the single connection when TLS is not used.
Because of this second authenticated connection Kerberos authentication is not supported when TLS is enabled. For Linux programming-only or Windows deployments this means you must not complete the manual steps to enable TLS to use Kerberos authentication. For Linux full-deployments TLS for the SAS Object Spawner must be disabled to use Kerberos authentication. To disable TLS only for the SAS Object Spawner update the file:
/opt/sas/viya/config/etc/spawner/default/spawner_usermods.sh
Add the following to the end of the file:
spawner_options="${spawner_options//-ssl*/}"
Save your changes and restart the SAS Object Spawner, for example on RHEL:
systemctl restart sas-viya-spawner-default
Confirm your changes by looking at the command-line for the SAS Object Spawner:
ps -ef |grep objsp
You should see that the command no-longer includes any of the following options:
- -sslpvtkeyloc
- -sslcertloc
- -sslpvtkeypassfile
- -sslcalistloc
Disabling TLS does not prevent data in-motion encryption. Instead of TLS, SAS/SECURE is used to encrypt communication with the SAS Object Spawner and SAS Workspace Server.
Configuration
To configure the SAS Object Spawner for Kerberos authentication edit the spawner_usermods.sh file on Linux or spawner_usermods.bat file on Windows. For example, on Linux the full path is:
/opt/sas/viya/config/etc/spawner/default/spawner_usermods.sh
On Linux add the following lines before the existing USERMODS line:
CMD_OPTIONS=-sspi
export KRB5_KTNAME=/opt/sas/sas.keytab
Update the existing USERMODS line to include the new CMD_OPTIONS:
USERMODS="$JREOPTIONS $CMD_OPTIONS"
Save your changes and restart the Object Spawner, for example on RHEL:
systemctl restart sas-viya-spawner-default
On Windows add "-sspi" to the USERMODS line so that it looks like the following:
Set USERMODS_OPTIONS=-sspi
Then uninstall and reinstall the Windows Service for the Object Spawner, by running the following:
C:\ProgramData\SAS\Viya\etc\spawner\default\spawner.bat remove
C:\ProgramData\SAS\Viya\etc\spawner\default\spawner.bat install
On Linux there is no additional configuration required to specifically support Kerberos Constrained Delegation. So long as the principal is correctly setup in Active Directory then Kerberos Constrained Delegation will be used.
On Windows the system environment variable SAS_CONSTRAINED_DELEG_ENABLED, is also required. To set the system environment variable complete the following as a local administrator:
- Open Control Panel ⇒ System and Security ⇒ System
- Select Advanced system settings and click the Environment variables... Button
- Click the New.. button under System variables
- Add the following variable name and value:
- Variable name: SAS_CONSTRAINED_DELEG_ENABLED
- Variable value: 1
- Click the Ok button when finished
- Restart the SAS Object Spawner
If Kerberos Constrained Delegation is already configured for the other SAS Viya 3.5 components this Windows system environment variable will already be set.
On Linux to configure a custom Service Principal Name (SPN) for the SAS Object Spawner update the spawner_usermods.sh file, the full path is:
/opt/sas/viya/config/etc/spawner/default/spawner_usermods.sh
Add the following lines before the existing USERMODS line:
SAS_SERVICE_PRINCIPAL=MYSAS/my_sas_server.com
export SAS_SERVICE_PRINCIPAL
Save your changes and restart the Object Spawner, for example on RHEL:
>systemctl restart sas-viya-spawner-default
If using a User Principal Name (UPN) based keytab file, then the SAS_SERVICE_PRINCIPAL environment variable in the spawner_usermodes.sh file should be set to the UPN. For example:
SAS_SERVICE_PRINCIPAL=sas-services@REALM.COM
export SAS_SERVICE_PRINCIPAL
On Windows to use a custom SPN that SPN must be registered against a Domain user account. Then the SAS Object Spawner windows service must be configured to run under that Domain user account. For both Windows and Linux, the connection profile in SAS Enterprise Guide 8.2 must be updated with the custom SPN.
Conclusion
Leveraging direct connections from SAS Enterprise Guide 8.2 to SAS Viya 3.5 is a valid stop-gap approach for customers not quite ready to move all clients onto SAS Studio. We’ve shown here that it is relatively straight-forward to enable Kerberos authentication for this direct connection from SAS Enterprise Guide 8.2. However, remember this does not impact SAS Studio 5.2 (Basic) which only supports authenticating with a username and password.
