SAS Viya 3.5 Authentication Options

[#1]

The SAS Viya 3.5, released in November 2019, provides some further enhancements with regards to authentication. In this article we look at these enhancements from a high level in the form of addressing customer scenarios. We’ll also touch upon some scenarios that are supportable with SAS Viya 3.4. In future posts we’ll take these scenarios and step through the configuration changes you’ll need to make.

At the highest level the changes to authentication with SAS Viya 3.5 are:

1. Support for Kerberos Constrained Delegation
2. Support for running the SAS Compute Server with a service account
3. Support for creating home directories

We’ll now look at some scenarios which these technology changes enable. In addition, we’ll explore a scenario that is also supported with SAS Viya 3.4.

Scenario 1: Use of Windows Defender Credential Guard

Microsoft is recommending the use of Windows Defender Credential Guard. The use of Windows Defender Credential Guard breaks applications if they require Kerberos unconstrained delegation. SAS Viya 3.5 supports Kerberos constrained delegation, which means that SAS Viya 3.5 supports Windows Defender Credential Guard. Previous releases of SAS Viya only supported unconstrained delegation and so did not support Windows Defender Credential Guard.

Scenario 2: No back-end user accounts

Some customers may not want to provision end-user accounts on the server hosts. This is especially true with cloud deployments, where the end-users of the application should not really be aware of the back-end computing resources and the additional administrative overhead of provisioning users is not required.

SAS Cloud Analytic Services in its default configuration on a Linux full deployment has always fitted this model well. The end-user authenticates to the CAS Controller, but the operating system process runs as the CAS service account. The authorization rules defined in the SAS Viya environment apply to the end-user, but host access is always as the CAS service account.

However, there has been an issue for the end-users wishing to write SAS code to interact with SAS Cloud Analytic Services. With SAS Viya 3.4 both SAS Studio 4.4 and SAS Studio 5.1 ran the SAS session for the end-user as the end-user. So, the end-user accounts had to be provisioned on these hosts. Also, with SAS Studio 4.4 since the end-user authenticated to the CAS Controller with a username and password their CAS session also ran as the end-user.

SAS Viya 3.5 introduces two improvements to resolve this issue. First is a new version of SAS Studio – with SAS Studio 5.2 (Enterprise) available in a full deployment, end-users can access the file system within the application. This means there is no need to use the traditional model SAS Studio 5.2 (Basic) which relies on the SAS Object Spawner and SAS Workspace Server. SAS Studio 5.2 (Basic) is still key in a programming-only deployment when there is no service layer.

The second improvement with SAS Viya 3.5 is the ability to associate a service account with a Compute context. This service account is then used to run the SAS Compute Server session. This means that end-users authenticate with SAS Logon Manager to gain access to SAS Studio 5.2 (Enterprise), but the SAS Compute Server session no-longer runs as the end-user. However, the SAS Compute Server session still has access to the end-user’s internal OAuth credentials generated by SAS Logon Manager. So, connections made from the SAS Compute Server session leveraging the service layer still occur as the end-user. For example, launching a CAS session will occur as the end-user even though the operating system process is running as the service account.

Scenario 3: No network mapped home directories

Ideally, just as the enterprise wide RDBMS implementations are "one version of the truth" for data, an enterprise wide network share is "one version of the truth" for end-users’ files. In such an idyllic place every end-user has a network accessible "home" directory that is automatically mounted and made available on every computing resource that they access.

However, many organizations are not in the idyllic place. Especially, with the move towards cloud computing – for fun try an online search for how easy it is to sync Microsoft’s OneDrive with Linux and think about trying to setup that for hundreds or thousands of end-users across a wide variety of different Linux platforms automatically. Many of these organizations will rely on local home directories for their users and rely on the Pluggable Authentication Module (PAM) configuration creating these on-demand the first time a user logs into a system.

Some of the SAS Viya 3.5 components still need access to a home directory for the end-users:

1. SAS Studio 5.2 (Basic) – to be able to log into the application
2. SAS Studio 5.2 (Enterprise) – to be able to log into the application (unless using service accounts)
3. SAS Cloud Analytic Services – for either username/password connections or host launched sessions the CASUSER caslib will be pointed to the home directory

These SAS components do not call far enough into the PAM stack to trigger any automatic creation of home directories. The SAS Object Spawner and SAS Compute Server have provided an option to enable the automatic creation of the home directory with SAS Viya 3.4, which I covered in a previous article. With SAS Viya 3.5 SAS Cloud Analytic Services also now supports the automatic creation of home directories.

Remember, for the automatic creation of home directories the process must "know" where to put the directory. This means that the user attributes returned from the operating system must correctly identify where the home directory should be located. This could be through reading a specific user attribute or something like SSSD fallback_homedir option.

Scenario 4: SAML or OpenID Connect Single Sign-On

SAS Viya 3.4 (May 2019 Upgrade) provided the option to simplify the sign-in process when using a third-party SAML or OpenID Connect provider. We discussed the sas.logon.zone configuration in a previous article. This removes the need to select the link at the bottom of the login form and end-users just type their email address. If the domain of the email address matches a comma separated list in the SAML or OpenID Connect configuration the end-user is redirected to the third-party provider for authentication.

But what about the case where we don’t want the end-user to have to interact with SAS Logon Manager at all. In this case we can leverage part of the OpenID Connect specification that is implemented by SAS Logon Manager. Using a login_hint parameter, allows an email domain to be passed to SAS Logon Manager authorize request, which is compared against the list of email domains in the SAML or OpenID Connection configuration. If there is a match, the user is automatically redirected to that providers, bypassing the login form altogether.

This login_hint parameter can be added to the SAS Logon Manager request using a simple RewriteRule in the Apache HTTP Server configuration. This RewriteRule can be crafted to either add the login_hint to every authorize request to SAS Logon Manager. Or might only add the login_hint based on properties of the requesting client, such as IP address or browser type. Equally, the RewriteRule might set the login_hint differently depending on where the request is coming from or some other criteria.

Thus, leveraging the login_hint provides true single sign-on for SAML or OpenID Connect providers.

Conclusion

SAS Viya 3.5 builds on all the great work that has gone into the previous releases of SAS Viya. The support for Kerberos Constrained Delegation is the main headline improvement for authentication with SAS Viya 3.5. This along with all the other pieces and improvements made through-out the SAS Viya 3.4 releases, make SAS Viya 3.5 more modern and easily integrated into your infrastructure.

[kmcnulty1]

Thank you @StuartRogers for helping us resolve an important discussion as you seem to be the authority on this topic.

So constrained delegation is now available for Hadoop and oracle or is the following still true?

"SAS Viya 3.5 supports Kerberos constrained delegation, however not all data sources support Kerberos constrained delegation...At the time of writing, due to third-party functionality that does not yet support constrained delegation, these SAS products do not currently support Kerberos constrained delegation functionality:

• SAS/ACCESS® Interface to Hadoop

• SAS/ACCESS® Interface to Impala

• SAS/ACCESS® Interface to JDBC

• SAS/ACCESS® Interface to Oracle

• SAS® Plug-ins for Hadoop"

https://www.sas.com/content/dam/SAS/support/en/sas-global-forum-proceedings/2020/4315-2020.pdf

[StuartRogers]

Hello @kmcnulty1,

Yes those statements are still true at this time (April 2021).  The SAS Note: 63143 - Windows Defender Credential Guard and SAS® Software contains the current state and will be updated once the situation changes.

Thank you for your time.

Stuart

[kmcnulty1]

@StuartRogers 

Hello again @StuartRogers    So does credential guard being enabled also interfere with unconstrained delegation? As I understand it constrained delegation was the workaround credential guard but now that I think about it, this means that unconstrained is simply not going to work either if credential guard is enabled.   This is a bit old but this is probably accurate:   Because SAS Viya 3.4 supports only unconstrained delegation, Microsoft Windows Defender Credential Guard cannot be enabled when you use Kerberos delegation. SAS plans to enhance SAS Viya to support constrained delegation in the future so that Microsoft WIndows Defender Credential Guard can be supported.

[JenniferJ]

@StuartRogers 

I'm curious what issues Windows Defender Credential Guard would cause in a system with the following setup.

SAS Viya 3.5 collocated on the same physical hardware as CDH Hadoop ecosystem at version Hadoop 3.0.0-cdh6.2.1. The OS running on the hardware is Oracle Linux 7.6.

No client side SAS desktop tools are used to connect to the SAS Viya system. The clients use a web browser on their Windows 10 desktop to access Visual Analytics.

Windows active directory is used for identify management. Kerberos is enabled as it's required to for SAS to access HDFS. Both unconstrained and constrained have been tested, neither have been successfully at this point.

In your experience could there be a Windows Defender piece a play preventing Kerberos from working with SAS Viya?

Thanks

[StuartRogers]

Hello @kmcnulty1  and @JenniferJ ,

Windows Defender Credential Guard prevents the Windows 10 client from doing unconstrained Kerberos delegation.  Therefore, if Credential Guard is enabled you cannot use unconstrained delegation to authenticate from the client to any server.  This includes SAS desktop client software such as SAS Enterprise Guide and the browsers used to access the SAS web applications.  Specifically from Microsoft's documentation we have the following statements:

When you enable Windows Defender Credential Guard, you can no longer use Kerberos unconstrained delegation or DES encryption. Unconstrained delegation could allow attackers to extract Kerberos keys from the isolated LSA process. Use constrained or resource-based Kerberos delegation instead.

@JenniferJ in your scenario you should be able to use constrained delegation - but there are some additional limitations to "traditional" constrained delegation; the main one being that the two sets of services must be in the same Kerberos Realm or Active Directory Domain.  This means that the SAS servers and the Hadoop servers must be in the same domain.  Resource-based constrained delegation does allow for the two sets of services to be in different domains/realms.  However, the MIT Kerberos Libraries used on Linux (provided as part of the operating system) do not support resource-based constrained delegation.  The libraries available directly from MIT do now support resource-based constrained delegation.  However, updating to these is difficult and might cause some sever problems with the Linux server OS.  You'd need to engage the support providers for the OS to help with that process.

Thank you for your time.

Stuart

[JenniferJ]

Thank you Stuart. This definitely helps to clarify.

[kopbran]

@StuartRogers 

I encountered the following problem during the testing of SAS Viya 3.5 with MFA solution from Cisco, which is based on PAM (RHEL 7.9 OS):

Apr 8 10:28:56 xxxxxx1234 java: pam_sss(sasauth-viya:auth): authentication success; logname= uid=1004 euid=1004 tty= ruser= rhost= user=xxx.yyy@zzz.com
Apr 8 10:28:56 xxxxxx1234 java: Couldn't open /etc/duo/pam_duo.conf: Permission denied

The file pam_duo.conf is supposed to be accessed from pam_duo.so and pam_duo.so is referred from PAM config file, which is sasauth-viya:

auth include duo-auth
account include duo-auth

duo-auth:

#%PAM-1.0
auth required pam_env.so
auth required pam_faildelay.so delay=2000000
auth [default=1 ignore=ignore success=ok] pam_localuser.so
auth sufficient pam_unix.so nullok try_first_pass
auth requisite pam_succeed_if.so uid >= 1000 quiet_success
auth requisite pam_sss.so forward_pass
auth sufficient pam_duo.so
auth required pam_deny.so

account required pam_unix.so 
account sufficient pam_localuser.so
account sufficient pam_succeed_if.so uid < 1000 quiet
account [default=bad success=ok user_unknown=ignore] pam_sss.so
account required pam_permit.so

password requisite pam_pwquality.so try_first_pass local_users_only retry=3 authtok_type= dcredit=-1 ocredit=-1 lcredit=-1 ucredit=-1 minlen=8
password sufficient pam_unix.so sha512 shadow nullok try_first_pass use_authtok
password sufficient pam_sss.so use_authtok
password required pam_deny.so

session optional pam_keyinit.so revoke
session required pam_limits.so
-session optional pam_systemd.so
session optional pam_oddjob_mkhomedir.so umask=0077
session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
session required pam_unix.so
session optional pam_sss.so

If I change the permission of the file pam_duo.conf then MFA plugin complains that only root is allowed to read the file, which makes sense since secret keys are inside. SAS Logon Manager passes U/P of the test user (who is a member of SAS Administrators group and is trying to access SAS Environment Manager application) to PAM, which processes statements in the PAM configuration file and returns the result to SAS Logon Manager. SAS Logon Manager grants access to the application (Environment Manager) if everything went OK.

I am wondering which Java process tries to open that MFA config file and how to configure Viya 3.5 to circumvent this problem?

Thanks

[StuartRogers]

@kopbran,

You need to remember with PAM there is no system wide daemon handling the authentication requests.  As you've seen it's the Java process for SAS Logon Manager that reads and processes the PAM configuration, which includes processing the Duo configuration file.  So you would need to run the SAS Logon Manager JVM as root for this to work.  However, the JVM is not designed to be run as root and it could possibly open up a range of other issues on your system.

A better approach is to look for a daemon process that can have parts of it running as root that can handle the authentication.  This is the approach covered in the following paper where Symantec VIP was used for MFA: Multi-Factor Authentication with SAS® and Symantec VIP.

It does appear that Duo has such an option:

The Duo Authentication Proxy is an on-premises software service that receives authentication requests from your local devices and applications via RADIUS or LDAP, optionally performs primary authentication against your existing LDAP directory or RADIUS authentication server, and then contacts Duo to perform secondary authentication. Once the user approves the two-factor request (received as a push notification from Duo Mobile, or as a phone call, etc.), the Duo proxy returns access approval to the requesting device or application.

You can find more information on Duo Authentication Proxy here: Authentication Proxy - Reference.

Using this approach the Duo Authentication Proxy has the parts that are running as root and so SAS Logon Manager does not need to be run with any elevated privileges.

Thank you for your time.

Stuart

[kopbran]

@StuartRogers 

Thanks for your answer. Since our proof-of-concept environment is retiring very soon, is there a way to run SAS Logon Manager with elevated privileges e.g. by adding "sas" user to "root" group or similar, just for the proof of concept of Duo 2FA and Viya? Or using tools like elssrv, sasauth, sasperm?

Thanks,

Bran

[StuartRogers]

Hello @kopbran, 

Looking at some documentation from Duo the pam_duo.conf needs to be only readable by root, so group access will not help and you'd really not want to have the sas account in the root group.  Also elssrv, sasauth, and sasperm do not help in this situation as the Java process for SAS Logon Manager is the one that needs to read the pam_duo.conf file.  Long-term the Authentication Proxy is the approach that would be supported and recommended.

Alternatively, I'd state again that this is not recommended and is very likely to cause issues with your environment.  But given you have stated this is a proof-of-concept environment and will be removed shortly, you could do the following:

Spoiler

1. Edit the /etc/init.d/sas-viya-saslogon-default file and change both SASUSER=root & SASGROUP=root

2. Run systemctl daemon-reload to update SystemD

3. Stop SAS Logon Manager with systemctl stop sas-viya-saslogon-default

4. Start SAS Logon Manager with systemctl start sas-viya-saslogon-default

This should allow you to test your Duo integration. 

At a bare minimum this will leave some files owned by root that will cause issues when you switch back to running SAS Logon Manager as the sas account.  It also opens up the possibility of your entire system being compromised if SAS Logon Manager is compromised.

Thank you for your time.

Stuart