In a previous post I’ve described a method for configuring Active Directory Authentication for SAS® on Linux (with realmd). One of the packages that’s installed is oddjob-mkhomedir. This package normally handles any requirement for auto-creating home directories for those AD users on Linux. Unfortunately it doesn’t seem to get used by the SAS Object Spawner. I ran into this issue again today when logging into SAS Studio 4.2 as an AD user on the SAS Viya™ 3.2 platform. I wasn’t able to login because the AD user’s Linux home directory didn’t exist and hadn’t been auto created. After manually creating the home directory the login succeeded. I would rather get auto-creation working so I wouldn’t need to manually create home directories for each SAS user that was likely to use SAS Studio. Thankfully I was able to find a solution that I’ll describe in this post.
This non-auto-creation issue is something I’ve encountered and investigated before. Amusingly, when researching the problem again today, I stumbled over a comment I’d made about it, and since forgotten, on an old SAS Communities thread: SAS 9.4 GRID authentication with PAM. Thank goodness for SAS Communities! In that post I described my findings with respect to the SAS 9.4 platform:
I looked into this further today and did some testing and it seems that pam_oddjob_mkhomedir is not firing from the sasauth PAM config. Whilst I can successfully have home directories auto-created, via pam_oddjob_mkhomedir, when using ssh and su, it is not working for sasauth. Digging into this further it looks like perhaps sasauth as used by the object spawner is not triggering the session initialization where pam_oddjob_mkhomedir does its work (as does pam_mkhomedir). There are 2 things that seem to suggest this: 1) All of the PAM config samples I have seen in the SAS documentation and usage notes only include the auth and account groups (I have session in my config for testing) 2) the sasauth.conf file has a section related to PAM_SETCREDENTIALS and Centrify where it says: “Centrify requires that pam_setcred be called. sasauth traditionally has not done this, since there’s no “session” like an interactive login.” Perhaps it is not using pam_open_session either? Whilst I can understand that there might not be a session when sasauth is used by the SAS Metadata Server, when it is used by the SAS Object Spawner to spawn SAS processes as that user, that sounds like a session to me.
A home directory is required for SAS users on Linux servers where a standard SAS Workspace Server is launched by the SAS Object Spawner using the identity of the requesting SAS user. In addition to the SAS Studio on SAS Viya example mentioned at the beginning of this post, this also happens with the SAS 9 platform when users run projects in SAS Enterprise Guide, run jobs in SAS Data Integration Studio, and run programs in SAS Studio.
If you have the oddjob-mkhomedir package installed you will see the following line in some of the PAM config files in /etc/pam.d:
session optional pam_oddjob_mkhomedir.so umask=0077
After a user has been authenticated and an account confirmed, a session may be initialized. At this point the pam_oddjob_mkhomedir.so module will do it’s work and create a home directory for the user (if it doesn’t already exist). This session doesn’t seem to be triggered by the sasauth module. If you look at the /etc/pam.d/sasauth file you will see it only references auth and account – no session. Simply adding a session line doesn’t help because, as described above, it doesn’t seem to get used by sasauth. You can find out more about sasauth and configuring PAM authentication for SAS in Chapter 3 of the Configuration Guide for SAS 9.4 Foundation for UNIX Environments. I’ve just noticed that the config guide specifically states that “Session and password modules are not supported”. For more info on PAM visit http://www.linux-pam.org/.
The auto-creation of home directories is such a time-saver that I wanted to try and find a solution to this issue. I found inspiration in this Server Fault post: RHEL 6.5 web application PAM AUTH pam_oddjob_mkhomedir. I thought I would piggy-back on the end of the account module-type for sasauth using the pam_exec.so module to call a custom script that sends a DBus message to trigger the pam_oddjob_mkhomedir module.
I created a script /etc/pam.d/sasauth-mkhomedir.sh with the following contents:
#!/bin/sh dbus-send --system --dest=com.redhat.oddjob_mkhomedir --print-reply / com.redhat.oddjob_mkhomedir.mkhomedirfor string:"$PAM_USER"
… made it executable:
chmod +x /etc/pam.d/sasauth-mkhomedir.sh
… and then added the bold line below to the end of the /etc/pam.d/sasauth file (at the end of the existing account section):
#%PAM-1.0 auth include system-auth account include system-auth account optional pam_exec.so /etc/pam.d/sasauth-mkhomedir.sh #account optional pam_exec.so debug log=/tmp/sasauth-mkhomedir.log /etc/pam.d/sasauth-mkhomedir.sh
The commented line at the end is an alternative form if you need debugging and logging.
I found this worked immediately and nothing needed to be restarted. If you decide to try this out then take care when customizing PAM configuration. Authentication changes can have a significant impact and, of course, should be thoroughly tested in a development or playpen environment.
I have tested with with SAS Studio 4.2 on SAS Viya 3.2 as well as the older SAS 9.2 platform. If authentication succeeds and the home directory doesn’t exist then it will be auto-created. If authentication fails then the script is not called and no attempt is made to create a home directory for the unauthenticated user.
Whilst this solution is not ideal, in the absence of session support in sasauth, it is a method that works in my environment, and might possibly work for you too. If you have any comments, suggestions, or further insights on PAM, sasauth, and the auto-creation of home directories, please leave a comment below.