SAS Viya 3.5 Kerberos Constrained Delegation

2 Likes

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:

"Traditional" Constrained Delegation – where the constraints are defined against the front-end service limiting the back-end services that Kerberos authentication can be delegated to.
Resource-based Constrained Delegation – where the constraints are defined against the back-end service limiting the front-end services that can delegate Kerberos authentication to the back-end service.

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.

User authenticates using Kerberos to SAS Logon Manager and requests SAS Studio 5.2 (Enterprise)
SAS Launcher Service (microservice) triggers a S4U2self request
The S4U2self response is a Service Ticket for HTTP as if from the user
SAS Launcher Service (microservice) triggers a S4U2proxy request using the Service Ticket from the S4U2self response
The S4U2proxy response contains the Service Ticket for sas-launcher for the user
SAS Launcher Service (microservice) uses the Service Ticket for sas-launcher to start the SAS Compute Server session as the user
The SAS Compute Server responds to the SAS Compute Service
SAS Studio 5.2 (Enterprise) responds to the user

Now that the end-user has launched SAS Studio 5.2 (Enterprise) they will launch their CAS session.

User enters code in SAS Studio 5.2 (Enterprise): "cas mysession;"
SAS Studio 5.2 (Enterprise) submits code to the SAS Compute Server session requesting launch of a CAS session
SAS Compute Server session triggers a S4U2proxy request using the Service Ticket acquired during session launch
The S4U2proxy response contains the Service Ticket for sascas for the user
SAS Compute Server session uses the Service Ticket for sascas to start the CAS session as the user
The CAS session responds to the SAS Compute Server session
SAS Compute Server session responds to SAS Studio 5.2 (Enterprise)
SAS Studio 5.2 (Enterprise) responds to the user

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.

User enters code requesting CAS process data
SAS Studio 5.2 (Enterprise) submits code to the SAS Compute Server session
SAS Compute Server session requests CAS session to process data
CAS session controller triggers a S4U2proxy request using the Service Ticket acquired during session launch
The S4U2proxy response contains the Service Ticket for MSSQLSvc for the user
CAS session controller uses the Service Ticket for MSSQLSvc to authenticate and request data from MS SQL Server
MS SQL Server responds to the CAS session
CAS session processes data and responds to the SAS Compute Server session
SAS Compute Server session responds to SAS Studio 5.2 (Enterprise)
SAS Studio 5.2 (Enterprise) responds to the user

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.

Consideration for Kerberos Constrained Delegation

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.

Prerequisites for Kerberos 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:

SAS Viya Web Applications – HTTP principal must be able to connect to CAS & Launcher principals
SAS Launcher Server – sas-launcher principal must be able to connect to CAS principal and data sources
SAS Cloud Analytic Services – sascas principal must be able to connect to HTTP principal and data sources

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:

SAS Viya Web Applications – HTTP principal must allow connections from the sascas principal
SAS Launcher Server – sas-launcher principal must allow connections from the HTTP principal
SAS Cloud Analytic Services – sascas principal must allow connections from the HTTP principal and sas-launcher principal
Data Sources – the data sources must allow connections from the sas-launcher principal and the sascas principal

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:

the keytab to either contain only contain the UPN or have the UPN listed first
additional configuration for SAS Cloud Analytic Services & SAS Launcher Server

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.

Configuration of Kerberos Constrained Delegation

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:

Set disableDelegationWarning to true
Set impersonate to true
Set servicePrincipal to the UPN in the keytab
Set spn to the HTTP Service Principal Name

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

Set disableDelegationWarning to true
Set impersonate to true
Set servicePrincipal to the UPN in the keytab
Set spn to the HTTP Service Principal Name

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.

Validating 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:

The first entry is the Service Ticket for the SAS Launcher principal.
The second entry is the Kerberos Constrained Delegation Ticket-Granting Ticket obtained by the SAS Launcher principal on behalf of the end-user
The third entry is the Service Ticket for Microsoft SQL Server.

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:

The first entry is the Service Ticket for the SAS Cloud Analytic Services principal.
The second entry is the Kerberos Constrained Delegation Ticket-Granting Ticket obtained by the SAS Cloud Analytic Services principal on behalf of the end-user.
The third entry is the Service Ticket for Microsoft SQL Server.

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.

Conclusion

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.