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.

5 thoughts on “SAS & IWA: Host Name Aliases and SPNs”

  1. Hi Paul,
    I am trying to register SPN for our Metadata, Computer and Web APPlication server as all three host machines uses an Alias.
    Please, can you advice on how the command should be constructed in each of the servers.

    Metadata Server CName: sit-app-01
    Compute CName: sit-com-01
    Web App Server CName: sit-mid-01

  2. Please, may I add.
    I am trying to get kerberos to function properly as we get authentication issue.

  3. Hi Christian,

    If you are using SAS 9.4 then you no longer need the port numbers on the SPNs. So for example:

    setspn -s SAS/sit-app-01 actual-host-name
    setspn -s SAS/sit-app-01.example.com actual-host-name

    I would also recommend getting the alias working for the SAS Metadata Server connection working before looking at the other machines. i.e. build up the layers one at a time, making sure each one works before moving on to the next.

    You should find the following more recent papers on this topic useful in helping you to get this working:

  4. Hi Paul,
    Thanks for the prompt response and for the advice.
    Our SAS version is SAS 9.3 (last update), does it mean I will have to specify the port numbers for each SAS service?
    Also, for the midtier, would i need to register for the SAS – Remote services and specify the port number?

    One last question with the command.
    you have mention I should specify the actual-host-name, so should the command look like the below.

    setspn -s SAS/sit-app-01 dev-app-02
    setspn -s SAS/sit-app-01.example.com dev-app-02

    where dev-app-02 is the physical host name.
    for the midtier, do i use SAS/ or HTTP/ in the command?

    My apologies, I am not versed with Kerberos and SPNs.

  5. Hi Christian,

    If you have a look at Stuart Rogers’ SASGF 2013 paper Kerberos and SAS 9.4: A Three-Headed Solution for Authentication you’ll see that SAS 9.2 registers port-based SPNs only, SAS 9.4 registered non-port-based SPNs, and SAS 9.3 registers both port and non-port versions. It has been a while since I last worked with SAS 9.3 so I would try the simpler non-port SPNs first and if that doesn’t work try port-based ones.

    If dev-app-02 is the name of the computer account in AD then your setspn commands look right to me. Use the SAS/ prefix for SAS services like the SAS Metadata Server and SAS Object Spawner. When configuring the mid-tier services use the HTTP/ prefix. There is an example HTTP/ SPN in my post Config Notes: SAS Mid-Tier (Linux) IWA with Fallback

    Cheers
    Paul

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.