SAS Viya 3.5 introduces support for Kerberos Constrained Delegation. In this article we’ll look at some considerations for using Kerberos Constrained Delegation, the prerequisites you need to complete, and how it is configured.
Kerberos Constrained Delegation or Service for User (S4U) is a Microsoft extension to the Kerberos authentication protocol. Microsoft documents the extension in this article. You can also view an overview of Kerberos Constrained Delegation. We will not be covering the details of Kerberos Constrained Delegation in this article. S4U includes two extensions, the first S4U2proxy allows a service to obtain a service ticket on behalf of a user to a different service and is the essential part of constrained delegation. The second S4U2self allows a service to obtain a Kerberos service ticket to itself on behalf of a user.
Also, it is important to know that there are two types of Kerberos Constrained Delegation:
Given this information about Kerberos Constrained Delegation we’ll now look at how it is used in SAS Viya 3.5. We’ll look at the example of authenticating to SAS Studio 5.2 (Enterprise), then launching a CAS session, and from the CAS session accessing Microsoft SQL Server. This is illustrated in the following figures.
Select any image to see a larger version.
Mobile users: To view the images, select the "Full" version at the bottom of the page.
Now that the end-user has launched SAS Studio 5.2 (Enterprise) they will launch their CAS session.
Now the end-user has a valid CAS Session within their SAS Studio 5.2 (Enterprise) session. Finally, they can use SAS Cloud Analytic Services to process data in Microsoft SQL Server.
From these flows we can see that HTTP Principal performs S4U2SELF & S4U2PROXY requests while the other components, SAS Launcher service and SAS Cloud Analytic Services, only perform S4U2PROXY requests.
Kerberos Constrained Delegation is becoming a standard item for customers to require since Microsoft rolled out Windows Defender Credential Guard with Windows 10 and Windows Server 2016. Window Defender Credential Guard disables unconstrained delegation so that the only Kerberos delegation that can be performed is constrained delegation. This impacts the browser clients deployed to Windows 10 client machines. Thus, it impacts both Linux and Windows deployments of SAS Viya. Microsoft recommends that Windows Defender Credential Guard is enabled on customer domains. Windows Defender Credential Guard is explained further in this article.
SAS Viya 3.5 supports Kerberos Constrained Delegation with SAS Logon Manager, SAS Cloud Analytic Services, as well as SAS Launcher & Computer Servers. The "Traditional" Constrained Delegation model is supported for both Linux full deployments and Windows deployments. While Resource-based Constrained Delegation is only supported with Viya on Windows; since the Kerberos libraries on Linux do not support Resource-based Constrained Delegation. Programming-only deployments do not use delegation at all.
The support for data sources is impacted by the data source client’s ability to support Kerberos Constrained Delegation. Microsoft SQL Server supports Kerberos Constrained Delegation along with Teradata. However, with Hadoop there are two issues preventing support; first the Java implementation has issues using the Constrained Delegation tickets and the Hadoop client itself seems to have issues correctly authenticating with the Constrained Delegation tickets. Equally, there are issues with the Oracle client supporting Kerberos Constrained Delegation. Where there are issues with the data source client, SAS has escalated requests to the data source providers for resolutions.
Kerberos Constrained Delegation cannot be mixed with unconstrained delegation. If constrained delegation is used on one connection, downstream connections must also use constrained delegation.
To use Kerberos Constrained Delegation with SAS Viya 3.5 all the standard prerequisites for using Kerberos authentication must be completed. We have discussed these before for both Linux and Windows. There are also some additional prerequisites specific to using Kerberos Constrained Delegation.
First Constrained Delegation must be setup for the different principals. For "Traditional" Constrained Delegation:
For example, in Active Directory Users and Computers the settings for the HTTP principal might look like the following:
While for Resource-based Constrained Delegation:
S4U2self requires that the service can obtain a Ticket-Granting Ticket (TGT) for itself; and is enabled with the "Use any authentication protocol" setting with Active Directory Users and Computers. With Active Directory domains only a User Principal Name (UPN) can obtain a TGT. This has implications for the properties of the HTTP service account and keytab. The recommended approach is to set UPN = SPN. Then the standard configuration for SAS Logon Manager is enough. Alternatively, if UPN ≠ SPN additional configuration is required for SAS Logon Manager.
For services not doing S4U2self the recommend approach is still to set UPN = SPN. If the customer requires that the UPN ≠ SPN for SAS Cloud Analytic Services & SAS Launcher Server principals, then we require:
Finally, there are Linux Kerberos library requirements. The MIT Kerberos libraries must meet the minimum version 1.11.6, this has no issues for RHEL 7.x. However, RHEL 6.x does not provide this version. So, the customer will need to download and build the libraries directly from MIT. Also, if the customer has version 1.16 or higher of the MIT Libraries SAS Cloud Analytic Services will produce more detailed log messages. The alternative Heimdal Kerberos libraries are not supported. Since Heimdal does not support writing the "proxy_impersonator" configuration entry to the credential cache file. Equally, One Identity (Quest) is not supported since this is built on the Heimdal Kerberos libraries.
The configuration of Kerberos Constrained Delegation is quite straightforward. The standard configuration for Kerberos unconstrained delegation should be complete with some additions.
For Linux deployments with default Service Principal Names only SAS Logon Manager requires additional configuration. You must set disableDelegationWarning to true and set impersonate to true for sas.logon.kerberos. You must also ensure the definition for sas.logon.kerberos is applied to all services, and not just SAS Logon Manager. Neither SAS Cloud Analytic Services or SAS Launcher Server require any other additional configuration.
Note: Setting impersonate to true when the HTTP Principal is not configured correctly for S4U2SELF will break Kerberos unconstrained delegation.
For Linux deployments with User Principal Names (UPN) based keytabs SAS Logon Manager requires:
SAS Cloud Analytic Services requires you to set CAS_SERVER _PRINCIPAL to the UPN value in the casconfig_usermods.lua file. Finally, the SAS Launcher Server requires you to set config/launcher-server/global/environment/SAS_SERVICE_PRINCIPAL to the UPN value using the SAS Bootstrap Config tool.
For Windows deployments with default Service Principal Names SAS Logon Manager must be updated. You must set disableDelegationWarning to true and set impersonate to true. Also, a system environment variable SAS_CONSTRAINED_DELEG_ENABLED=1 must be created.
For Windows deployments with User Principal Names (UPN) based keytabs the system environment variable SAS_CONSTRAINED_DELEG_ENABLED=1 is still required. In addition, for SAS Logon Manager
SAS Cloud Analytic Services does not support custom principal names on Windows. Finally, the SAS Launcher Server requires you to set config/launcher-server/global/environment/SAS_SERVICE_PRINCIPAL to the UPN value using the SAS Bootstrap Config tool
Once the configuration changes are complete the SAS Logon Manager, SAS Cloud Analytic Services, and SAS Launcher Server must be restarted. This completes the additional configuration required to enable Kerberos Constrained Delegation.
Essentially, if the end-users can authenticate correctly at each point in the delegation then you know that Kerberos Constrained Delegation is operating. For Linux deployments you can also review the Kerberos ticket caches to ensure that constrained delegation is taking place rather than unconstrained delegation. Firstly, on the client running the browser the Kerberos ticket cache should look like the following:
#1> Client: gatedemo001 @ GELLAB.NET Server: HTTP/sasviya01.gellab.net @ GELLAB.NET KerbTicket Encryption Type: RSADSI RC4-HMAC(NT) Ticket Flags 0x40a10000 -> forwardable renewable pre_authent name_canonicalize Start Time: 11/19/2019 4:38:16 (local) End Time: 11/19/2019 14:37:55 (local) Renew Time: 11/26/2019 1:37:54 (local) Session Key Type: RSADSI RC4-HMAC(NT) Cache Flags: 0 Kdc Called: gellabdc1.gellab.net
This shows the Service Ticket for the HTTP principal and shows that unconstrained delegation is not set with the absence of the ok_as_delegate flag.
Then on the host running the SAS Compute Server the Kerberos ticket cache should look like the following:
Ticket cache: FILE:/tmp/tktJsGgFm Default principal: gatedemo001@GELLAB.NET Valid starting Expires Service principal 11/19/2019 04:38:32 11/19/2019 14:38:32 sas-launcher/sasviya01.gellab.net@GELLAB.NET 11/19/2019 04:14:53 11/19/2019 14:14:53 krbtgt/GELLAB.NET@GELLAB.NET for client sas-launcher/sasviya01.gellab.net@GELLAB.NET, renew until 11/26/2019 04:14:53 11/19/2019 04:39:25 11/19/2019 14:14:53 MSSQLSvc/gellabdc1.gellab.net:1433@GELLAB.NET renew until 11/26/2019 04:14:53
The ticket cache contains three entries:
Finally, on the SAS Cloud Analytic Services controller the ticket cache should look like the following:
Ticket cache: FILE:/tmp/tktreSDMY Default principal: gatedemo001@GELLAB.NET Valid starting Expires Service principal 11/19/2019 04:40:08 11/19/2019 14:14:53 sascas/sascas01.gellab.net@GELLAB.NET renew until 11/26/2019 04:14:53 11/18/2019 23:31:19 11/19/2019 09:31:19 krbtgt/GELLAB.NET@GELLAB.NET for client sascas/sascas01.gellab.net@GELLAB.NET, renew until 11/25/2019 13:39:34 11/19/2019 04:40:09 11/19/2019 09:31:19 MSSQLSvc/gellabdc1.gellab.net:1433@GELLAB.NET renew until 11/25/2019 13:39:34
The ticket cache contains three entries:
For the case where the UPN ≠ SPN you should check the SAS Compute Server and SAS Cloud Analytic Services ticket caches. You should see that the Service Principal for the Service Ticket is the same as the client listed against the Ticket-Granting Ticket. If this is not the case, then the delegated credential will be unusable and you should check the contents of the Kerberos keytab provided to the service.
Kerberos Constrained Delegation, supported with SAS Viya 3.5, will be a common setup for many customers using Kerberos. It’s adoption, will be limited by the support provided by data sources, but this is expected to change over time. The additional configuration on top of the standard configuration for Kerberos delegation is relatively simple. The complexity is, as always, in the prerequisites. Ensuring the correct principals are trusted for delegation to correct principals will be the major point of issue. If possible, it is recommended to setup unconstrained Kerberos delegation first and prove that this works before enabling Kerberos Constrained Delegation. This will ensure all the basic Kerberos perquisites are complete before looking at the additional steps.
Registration is open! SAS is returning to Vegas for an AI and analytics experience like no other! Whether you're an executive, manager, end user or SAS partner, SAS Innovate is designed for everyone on your team. Register for just $495 by 12/31/2023.
If you are interested in speaking, there is still time to submit a session idea. More details are posted on the website.
Data Literacy is for all, even absolute beginners. Jump on board with this free e-learning and boost your career prospects.