Tag: SPN

Config Notes: SAS Mid-Tier (Linux) IWA with Fallback

Update 26Sep2018: This post is now a few years old and naturally technology and security have progressed in that time. For more up to date information regarding delegation and, in particular, the requirement for constrained delegation when working with Windows Defender Credential Guard in Windows 10 and Windows Server 2016, please see Stuart Rogers’ very useful SAS Global Forum 2018 Paper: SAS 9.4 on Microsoft Windows: Unleashing Kerberos on Apache Hadoop.

Continuing on the theme of configuring a SAS 9.4 M2 platform on Linux to use Integrated Windows Authentication (IWA), in this post I’m going to jot down some notes on steps 12-15 – configuring the SAS mid-tier on a Linux server for IWA with fallback to form-based authentication (when IWA is not available). This includes delegation, so that IWA users of mid-tier apps like SAS Studio are able to get IWA access to a SAS Workspace Server (and avoid having to store their passwords in metadata or switch to using SAS Token Authentication).

If you’re wondering what happened to steps 1-11, I’ll try get to those earlier steps in future posts. I’m starting at step 12 because someone recently asked me a question about configuring an IWA mid-tier and so it seemed like a good idea to get this blog post done first. Of course, when actual implementing, it’s always good to start at the beginning, building up the foundations, and verifying those first steps are working well before moving on to the next steps. So these steps assume you already have a working implementation where SAS desktop applications (like SAS Management Console & SAS Enterprise Guide) are able to connect to the SAS metadata server using IWA, and also to get IWA access to an appropriately configured SAS Workspace Server.

I have found the best mid-tier related documentation resources for this type of configuration are these ones:

… and there are a few others listed in a previous blog post.

One of the reasons I’m writing this post is to get down some notes on a config that worked for me. The documents referenced above cover a variety of scenarios including plain basic web authentication with an XML file-based UserDatabaseRealm, an LDAP JNDIRealm, IWA (SPNEGO) without fallback, as well as fallback to form-based SAS authentication. Getting the right mix of settings, that didn’t conflict with each other, took me a long time to determine (my mid-tier takes about 20 minutes to restart whenever I want to test a modified config). Along the way I encountered pop-up basic web authentication dialogs when IWA should have worked, and infinite browser-refresh loops for the SAS Logon Manager when IWA was disabled in the browser and I was expecting fallback to SAS authentication. This post is about the final config that worked for me. I know I’ll be referring to this post again, and I hope it proves helpful to others too.

Here goes … Continue reading “Config Notes: SAS Mid-Tier (Linux) IWA with Fallback”

SAS & IWA: Check the Logs

When testing Integrated Windows Authentication (IWA) based client connections to SAS® platform servers, it is well worth checking the SAS logs to verify the connections are being made the way you expect. SAS has a variety of methods up it’s sleeve to get you authenticated, including cached credentials, retrieving stored credentials from metadata, SAS token authentication etc. Looking in the SAS server logs will help you identify the connection/authentication events and methods used. In the past I’ve thought I was using IWA+Kerberos but when I looked in the log it was obvious I wasn’t! I think it’s essential when testing/troubleshooting a new IWA configuration to review the SAS server logs for both failed and successful connections.

In a previous post “SAS and IWA: Two Hops” I mentioned how sometimes it’s necessary to force the use of Kerberos with IWA to be able to make IWA delegated connections to secondary servers. So here’s some examples of what we might see in SAS server logs Continue reading “SAS & IWA: Check the Logs”

SAS & IWA: Reviewing SPNs

My last post was about configuring additional Service Principal Names (SPNs) in Active Directory to support the use of Integrated Windows Authentication (IWA) in a SAS® platform installation that uses host name aliases in preference to physical host names.

When working on a SAS & IWA setup like this, I’d start by reviewing the currently registered SPNs for all of the SAS servers involved (as well as any other servers that might be accessed from a SAS server using IWA). This gives an idea of what SPNs might have already been added, which ones still need to be added, and potentially which ones might need to be removed.

This is the command I use Continue reading “SAS & IWA: Reviewing SPNs”

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, Continue reading “SAS & IWA: Host Name Aliases and SPNs”

SAS and IWA: Two Hops

Update 26Sep2018: This post is now several years old and naturally technology and security have progressed in that time. For more up to date information regarding delegation and, in particular, the requirement for constrained delegation when working with Windows Defender Credential Guard in Windows 10 and Windows Server 2016, please see Stuart Rogers’ very useful SAS Global Forum 2018 Paper: SAS 9.4 on Microsoft Windows: Unleashing Kerberos on Apache Hadoop.

In an earlier post I mentioned that I would jot down a few notes about my experiences with SAS® software and Integrated Windows Authentication (IWA). This is the first of these posts and concerns the initial configuration. Chances are, if you knew you wanted to use IWA before you installed SAS, then it would have been discussed and implemented during the initial installation and configuration. If you decided to implement IWA after the fact then you would most likely have followed the instructions from either:

A basic SAS and IWA configuration might then look something like this. In the diagram below we have a client PC (saspc001), a dedicated metadata server machine (sasmeta) and an application server machine (sasapp). This is a homogenous environment consisting of all Windows machines in the same Windows domain. Other configurations might have multiple domains that trust each other, and now with SAS 9.3, some of the SAS servers may also be UNIX based (assuming the prerequisites are met).

In the diagram above a SAS Enterprise Guide user working on the saspc001 workstation initially connects (1) to the SAS Metadata Server on sasmeta using a connection profile with IWA enabled. When they run a project, an IWA connection (2) is then made to the SAS Object Spawner on sasapp to launch a standard SAS Workspace Server to execute the SAS code. The logical SAS Workspace Server has been configured in metadata to accept IWA connections. Both of these IWA connections involve only 1-hop from the workstation: saspc001 to sasmeta, and saspc001 to sasapp.

Problems might then arise when secondary connections need to be made from the workspace server to additional servers and access denied errors are seen in the SAS log. One example of a secondary connection includes executing code on the workspace server that reads a CSV or XML file from another file server (filesrv) using a UNC path (e.g. \\filesrv\share\file.xml). Another example might be assigning a library in the workspace server session that uses SAS/ACCESS Interface to ODBC or SAS/ACCESS Interface to OLEDB to connect to a Microsoft SQL Server database on another server (sqlsrv). These examples are shown in the diagram below as (3) and (4) respectively.

Both of these example involve IWA being used in 2-hops from the client. In the first hop (2) IWA is used to connect from saspc001 to sasapp as before. In the second hops the SAS workspace server process has to then connect and authenticate to the secondary servers: sasapp to filesrv (3), and sasapp to sqlsrv (4). It is these second hops which may fail if additional measures have not been taken:

  • Trusted for Delegation: the intermediate server (sasapp in this example – where the workspace server is running) needs to configured in Active Directory as Trusted for Delegation. This must be done by a domain admin. This configuration is mentioned in the SAS Intelligence Platform: Security Administration Guide on the Windows Privileges page for both SAS 9.2 and SAS 9.3. In a future post I’ll show the method I use as a non-domain-admin to double check this as part of the troubleshooting process.
  • Force Kerberos: you also need to ensure the Kerberos protocol is used and not NTLM. Whilst you could get all of your users to configure their SAS client connection profiles to use Kerberos, it is usually preferable to leave the clients alone and instead configure the SAS servers to only offer Kerberos and not NTLM. This is documented in the in the SAS Intelligence Platform: Security Administration Guide on the How to Force Use of Kerberos page for SAS 9.2, and the How to Configure Integrated Windows Authentication page for SAS 9.3. Things can get a bit trickier when DNS host aliases (or CNAMEs) are used in environments configured for disaster recovery. In a future post I’ll show some examples of additional Service Principal Names (SPNs) that might be required in these situations.

So if you find yourself getting access denied messages when using SAS and IWA in situations where multiple hops are involved, I hope this post gives you some ideas of things to investigate further.

For more posts in this series have a look at the IWA tag.