BookmarkSubscribeRSS Feed

SAS 9.4 M7 Importance of UPN

Started ‎09-15-2020 by
Modified ‎09-15-2020 by
Views 4,652

SAS 9.4 Maintenance 7 has made some minor changes in the Kerberos initialization code designed to make the configuration of constrained delegation easier. However, this change has an impact for the configuration of Kerberos authentication on the server tier (Metadata Server and Object Spawner) on Linux & UNIX. In this article we will look at the problem and ways to mitigate the issue.

 

Before we start looking at details of the configuration and possible issue, we’ll remind ourselves of some important terms and principles. With Active Directory each object, both computer and user, has a unique referencing attribute of User Principal Name (UPN). The standard format of the UPN is user.name@REALM.COM. Equally, each registered service in Active Directory has a unique reference attribute of Service Principal Name (SPN). The standard format of the SPN is <service_class>/<host>@REALM.COM, for example SAS/metadata.host.com@REALM.COM.

 

When a service is registered against a user object that user object has a single UPN and one or more SPNs. For Kerberos the long-term key associated with both this user and the services registered against the user is based on the user’s password and a salt. The salt used by Active Directory is the UPN.

 

With Active Directory Kerberos credentials can only be initialized using the UPN. This means a kinit can only be performed using the UPN and providing the password or long-term key. You cannot initialize credentials with a SPN, attempting to do such will result in a Kerberos error "client not found in kerberos database".

 

On Linux or UNIX systems the long-term keys for Kerberos are provided using a Kerberos keytab file. The keytab file contains one or more principals, either UPN or SPN, and their associated long-term keys. The long-term keys leverage a supported encryption algorithm such as AES128, AES256, or RC4. So, we might have a single principal in the keytab three times with the three different encryption algorithms.

The Problem

The SAS services on Linux or UNIX are registered against a service account. SAS recommends that such a service account has the UPN set to the same value as the SPN. Then the Kerberos keytab file only needs to contain the SPN and it’s associated long-term keys. Setting up the service account and the Kerberos keytab in such a way causes no problems with SAS 9.4 Maintenance 7 or any previous releases.

 

However, some customers do not want to set the UPN to the same value as the SPN. So, their service account has the UPN in the standard format of user@REALM.COM. Then the Kerberos keytab might have different content it might contain:

  • Just the UPN and associated long-term keys
  • Just the SPN and associated long-term keys
  • Both the UPN and SPN along with the associated long-term keys

Any of these combinations will have worked correctly for Kerberos authentication in SAS 9.4 up to Maintenance 6, so long as constrained delegation is not used.

 

With SAS 9.4 Maintenance 7 the SAS process now initializes a Kerberos credential as part of the authentication. As we know this can only be done with the UPN and not the SPN. So, with SAS 9.4 Maintenance 7 if the service account has UPN ≠ SPN the following error will be generated when attempting to authenticate an end-user:

 

Kerberos failure in function krb5_get_init_creds_keytab: Client 'SAS/metadata.host.com@REALM.COM' not found in Kerberos database

 

To resolve this we need to tell SAS what principal to use to initialize the credential. The environment variable SAS_SERVICE_PRINCIPAL can be used to define the principal. Edit the <SASCONFIG>/Lev#/level_env_usermods.sh and add

 

SAS_SERVICE_PRINCIPAL=user@REALM.COM
export SAS_SERVICE_PRINCIPAL

 

You will need to restart the Metadata Server and Object Spawner.

 

Setting SAS_SERVICE_PRINCIPAL will be enough if the Kerberos keytab contains either just the UPN or both the UPN and SPN. However, if the Kerberos keytab only contains the SPN then Kerberos authentication will still fail, since the keytab will not contain the long-term keys for the UPN to enable SAS to initialize a Kerberos credential. As such the Kerberos keytab will need to be regenerated to include the UPN.

 

Alternatively, the customer could change the service account and set the UPN to be the same as the SPN. But, remember the UPN is used by Active Directory as the salt on the long-term keys so changing the UPN will change the long-term keys. Meaning the Kerberos keytab will need to be regenerated.

Comments

Many thanks @StuartRogers , really useful as always.

 

Is this detail relevant during upgrades-in-place, or will the SDW process for UIP adjust accordingly?

Hello @JuanS_OCS,

The SDW will not make any changes as part of UIP for the principal name.  You'll need to set the SAS_SERVICE_PRINCIPAL, if required yourself.  Also, it will be up to you to ensure the Kerberos keytab has the correct contents.

 

Thank you for your time.

 

Stuart

Hello @StuartRogers ,

 

thank you for your really quick reply.

 

Of course SDW or SDM would not make infrastructure changes, but I wonder if there is an option to keep using the same mechanism as in the past, instead of using this new method. From your post and your reply I assume it is not an option, but please confirm this assumption.

 

This would bring me to my next question: what is the background or design reasoning for this change? This is specially relevant as I hope you understand it has to be explained to Architects and the Infrastructure team leads before the change.

 

My last question for now would be: could you please share to the document in support.sas.com (or SAS Problem/Install Note) that officially describes this update/issue?

 

Thank you in advance,

Best regards,

Juan

Hello @JuanS_OCS 

Yes I can confirm at the moment SAS 9.4 Maintenance 7 changes the approach and there is no-way to opt-out of this change.  The change was to be able to support Kerberos Constrained Delegation without any additional configuration steps, other than that for Kerberos Unconstrained Delegation.  It was not intended to cause backward compatibility issues and SAS will provide a fix to resolve this issue.

At the moment I cannot point to any documentation updates, these will be appearing in the next few days.  I wanted to get this information out as soon as possible and so posted this before documentation updates were made.

Thank you for your time.

Stuart

Hello @StuartRogers ,

 

thank you, your explanation helps a great deal. I would add kudos to your reply if I could.

 

I appreciate very much your effort on getting this information through, as I am sure many others can appreciate it as well.

 

Would you (or someone else) be able to provide any update when a documentation update happens on this topic?


Thank you,

Best,

Juan

Hey, @StuartRogers excellent article I use it all the time. We also have to provide this Problem Note if the UPN does not match the SPN for 9.4 TS1M7. I thought it would also be a good thing to have on this page that they may need this hot fix if that is the case.

 

66937 - You see a "Kerberos failure" message after you set up Integrated Windows Authentication and ...

Version history
Last update:
‎09-15-2020 01:38 AM
Updated by:
Contributors

SAS Innovate 2025: Call for Content

Are you ready for the spotlight? We're accepting content ideas for SAS Innovate 2025 to be held May 6-9 in Orlando, FL. The call is open until September 25. Read more here about why you should contribute and what is in it for you!

Submit your idea!

Free course: Data Literacy Essentials

Data Literacy is for all, even absolute beginners. Jump on board with this free e-learning  and boost your career prospects.

Get Started

Article Tags