SAS & IWA: Host Name Aliases and SPNs

I’m quite keen on using host name aliases, rather than their physical host names, when referring to machines in SAS® platform installations. It does however mean a little extra configuration is required when using Integrated Windows Authentication. That is what this post is about: configuring Active Directory with additional Service Principal Names (SPNs) based on the aliases.

Host name aliases have several benefits over using physical host names. They can be easier to remember (e.g. sasmeta v.s. p106547). They can be easily redirected from primary environments to disaster recovery environments (e.g. sasmeta from p106547 to d106547) with no client reconfiguration requirements. They also allow host machines to be readily renamed if/when required with little or no changes to SAS configuration files, programs and/or metadata.

Whilst they have obvious benefits, host name aliases do make the installation more complex for the installer/administrator. During installation and configuration the aliases must always be used instead of the physical machine names. They need to be in place before the initial installation/configuration. When using Integrated Windows Authentication (IWA) additional work needs to be done by the domain admins to ensure all the required SPNs are in place (though this can be done post installation/configuration).

There’s more information about this topic on the Using Custom SPNs page in the SAS® 9.3 Intelligence Platform: Security Administration Guide. It is also discussed on the How to Configure Integrated Windows Authentication page in the SAS® 9.2 Intelligence Platform: Security Administration Guide. To quote the SAS documentation:

If your SAS servers use DNS aliases, you must manually register those aliases (as custom SPNs) in order to support Kerberos-based IWA connections.

SAS server components, such as the SAS metadata server and SAS object spawner, automatically register SPNs based on the physical host name of the machine they are running on. SAS clients, such as SAS Enterprise Guide and SAS Data Integration Studio, derive the SPN from the host name specified in the client connection profile. When you are only using physical host names then this works transparently as the SPN derived by the client and the one registered by the server match. When using host name aliases it is easy to get a mismatch. If the client is using the hostname alias for its SPN (e.g. SAS/sasmeta:8561) and the server has only registered an SPN for the physical host name (e.g. SAS/p106547:8561) then there is a mismatch and IWA will not work. There are 2 ways to resolve this: 1) the client connection profile can specify the physical host name based SPN or 2) the alias based SPN can be added to Active Directory. Whilst the client connection profile change is easy, it would not be recommended: it will need to be configured in all user’s client connection profiles and those profiles would need to change if/when the physical machine name changes, negating the benefit of using the host name aliases in the first place. Whilst the second method needs to be done by a domain admin, it does mean no changes are required to the client connection profiles. The client derived alias based SPN will match a registered alias based SPN for the server.

In earlier posts I mentioned how I had configured the SAS Workspace Server for IWA, configured the various SAS servers to Force Kerberos, and configured the machine account as Trusted for Delegation to allow additional IWA hops. With all of that in place, these are some examples of the various setspn commands I’ve used to get host name alias based IWA connections working with SAS servers:

… for a Lev1 Metadata Server:

setspn -A SAS/sasmeta-alias-name.example.com:8561 sasmeta-host-name
setspn -A SAS/sasmeta-alias-name:8561 sasmeta-host-name

… for a Lev1 SASMeta Workspace Server (used by the Lev1 SAS Object Spawner on the metadata server machine and only accessible to administrators):

setspn -A SAS/sasmeta-alias-name.example.com:8591 sasmeta-host-name
setspn -A SAS/sasmeta-alias-name:8591 sasmeta-host-name

… for a Lev1 SASApp Workspace Server (used by the Lev1 SAS Object Spawner on the application server machine):

setspn -A SAS/sasapp-alias-name.example.com:8591 sasapp-host-name
setspn -A SAS/sasapp-alias-name:8591 sasapp-host-name

… for a Lev1 SASApp OLAP Server (mainly for the benefit of 3rd party clients as SAS clients are more likely to use SAS Token Authentication when connecting to the OLAP server):

setspn -A SAS/sasapp-alias-name.example.com:5451 sasapp-host-name
setspn -A SAS/sasapp-alias-name:5451 sasapp-host-name

… and finally for the SAS PC Files Server:

setspn -A SAS/saspcfs-alias-name.example.com:8621 saspcfs-host-name
setspn -A SAS/saspcfs-alias-name:8621 saspcfs-host-name

You might notice that all of the commands above register both the short host name alias and the fully qualified host name alias. They also include port numbers. Interestingly one of the enhancements for SAS 9.3 is the removal of the port number from SPNs. This should reduce the number of SPNs required, especially with multiple clustered environments. One of the projects I worked on in the last year involved configuring IWA over 20+ SAS server machines. That was for SAS 9.2 so I’d be keen to revisit it for SAS 9.3. Here’s a quote from the What’s New in Security Administration in SAS 9.3 document:

In Integrated Windows authentication, the default service principal name (SPN) no longer includes a port value. The format is SAS/machine, where machine is the host machine’s fully qualified domain name. For example, SAS/A12345.company.com.

There’s more information on the setspn command in this Microsoft TechNet Setspn Overview page.

If you’re interesting in SAS and Integrated Windows Authentication, you can find more posts in this series by looking at the IWA tag.