IWA with SAS 9.4 M2 on Linux

I’ve just finished a challenging but very rewarding experience configuring a SAS 9.4 M2 platform on Linux to use Integrated Windows Authentication (IWA), for both server and mid-tiers ….. without using Quest Authentication Services.

The SAS platform has supported IWA on Linux since SAS 9.3 but until recently has only supported it when you “purchase, install, and configure an additional third-party product (Quest Authentication Services 4.0)”.

I’ve been wanted to do a SAS + Linux + IWA config for a while but had put it off because of the Quest requirement. What brought it back to the front of my mind was talking to someone recently about implementing IWA for a SAS Visual Analytics installation on Linux. They wanted to provide seamless login via IWA for most users, but also provide form-based logins for people who couldn’t use IWA.

I remembered seeing this section from the What’s New in SAS 9.4 (SAS 9.4 Intelligence Platform):

In the second maintenance release for SAS 9.4, Integrated Windows Authentication on Linux systems no longer requires the use of Quest Authentication Services. SAS can leverage the libraries that are shipped with the supported operating system or that are provided in most third-party authentication solutions.

It sounded like SAS 9.4 M2 would allow me to build such a config, without using Quest, and use the standard Linux libgssapi_krb5 package instead. At the same time I also remembered reading a great SAS Global Forum paper by Zhiyong Li on mid-tier fallback authentication: this is where you can configure the SAS mid-tier to fallback to form-based authentication in situations where IWA is not available or has been disabled (like you might do when you want to login using a different second identity). These both sounded like great challenges [ and fun :) ], so I set about confirming my understanding of these possibilities with SAS 9.4 M2 by doing both at the same time.

After a few days of research, implementation, testing and debugging, I finalized the config last night. I got quite a buzz out of some of the mind-bending troubleshooting sessions and it was a very rewarding outcome. Other than a few relatively minor issues to resolve, it is all working very well now.

If I get some time I’ll try to write up a few blog posts with more detail on the steps, issues, troubleshooting techniques and resolutions. In the meantime here’s an outline of the approach I took:

Update 27Jul2014: For more information on the steps below, see the following blog posts:

  1. Installed and configured the MIT Kerberos client packages (krb5-user, libpam-krb5) on the Linux server
  2. Verified I could use kinit on the Linux server to authenticate and obtain a ticket granting ticket (TGT) from the Microsoft Windows Server 2012 R2 Active Directory (AD) server.
  3. Installed and configured Samba on the Linux server and joined the AD domain.
  4. Installed and configured System Security Services Daemon (SSSD) on the Linux server, and related PAM and GSSAPI packages (sssd, sssd-tools, libpam-sss, libnss-sss, libgssapi-krb5-2).
  5. Verified I could use ldapsearch with gssapi to query the AD server.
  6. Configured the PAM module pam_mkhomedir to auto-create user home directories as needed.
  7. Verified I could login to the Linux server with AD credentials and that getent passwd and getent group returned expected results for AD users and groups.
  8. Configured the SAS Metadata Server for IWA, with a SAS service account and keytab.
  9. Verified SAS desktop apps like SAS Enterprise Guide could connect to the metadata server using IWA and Kerberos.
  10. Configured the SAS Logical Workspace Server to accept IWA conections (Kerberos only).
  11. Verified SAS desktop apps like SAS Enterprise Guide could spawn a SAS Workspace Server from an IWA based metadata connection.
  12. Configured IWA, with a HTTP service account and keytab, for the SAS mid-tier.
  13. Verified I could login to SAS web apps using IWA.
  14. Configured delegation so SAS mid-tier apps (like SAS Studio) could get IWA access to a SAS Workspace Server.
  15. Enhanced the SAS mid-tier IWA config with fallback authentication to allow form-based login when IWA was not available.

I found the following resources essential in researching, planning, configuring and troubleshooting the SAS platform side of things:

I hope you find this post useful. I had great fun building this configuration! Please leave a comment if you have any questions or would like to see some more posts on the topic.

11 thoughts on “IWA with SAS 9.4 M2 on Linux”

  1. Paul thanks for this encouraging post. Sounds like this is something you do before breakfast;-) Looking forward for more stories on this topic.

  2. Thanks Bruno … though I might have to work through the night to be able to finish before breakfast ;)

  3. Hi Paul,

    this is great stuff, thanks for sharing. I’m more interested in first steps (“use system stuff instead of Quest”) – will you add more posts about the details of these topics too?
    Which OS was used in the tests, was it RHEL6.x ?

    Cheers,
    Frank

  4. Hi Frank,

    Thanks for the feedback. I do plan to add some more posts on the topic when I get some time. I’ll try to include info on getting the system software/config ready for SAS software to use. In my case I used Debian (one of the main distro’s I tend to use) but it would of course be better for a production installation to use RHEL or one of the other platforms supported by SAS.

    Cheers
    Paul

  6. Hi Paul,
    In my case, i have three linux servers that am trying to integrate, i have all of them being able to su – demo and i can see the /home/demo but when i tried to ssh and login with demo user and its password i get access denied.
    Any ideas will be helpful

    thanks.

  7. If logging on via sudo works but an ssh connection doesn’t then I would suggest checking the system logs for the reason. I usually configure ssh to limit access to specific groups so perhaps your ssh has been limited such that the demo user has no access. The system logs will probably provide the reason.

  8. Hi Paul

    to clarify, the user needs to be able to ssh to the metadata and compute servers to attain Single Sign On?

    Thanks

  9. Hi Lorenz,

    No, the user does not need to be able to ssh for single sign on to work. As long as the PAM config has been setup they may be able to login to SAS platform components using single sign on but may not be able to ssh. Whilst I sometimes use ssh for testing, it may be that your servers have been configured to limit who can ssh for security purposes.

    I hope that helps clarify things.

    Cheers
    Paul

  10. Hi Paul,
    Thanks for the reply.

    For further clarity, to test if PAM is working need the below command to test if connecting to LDAP successfully:
    getent
    su

    Btw, If PAM/sssd is not configured, IWA and SSO will not work? So its also a prerequisite aside from the kerberos prereqs?

    Thanks
    Lorenz

  11. Hi Lorenz,

    Yes, you can test that things are working as expected using getent to lookup users and groups, su to try switching to a test user, and kinit to obtain a kerberos ticket. When using the method outlined in this post and the linked posts (kerberos, sssd, realmd) then yes pam/sssd needs to be configured for IWA SSO to work. However, there are other methods of doing SSO than the one outlined in the post (Quest Authentication Services for example) so if you are using an alternative method then refer to its associated documentation for the requirements.

    Cheers
    Paul

Comments are closed.