Auto Creation of Linux Home Directories for SAS Users

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 umask=0077

After a user has been authenticated and an account confirmed, a session may be initialized. At this point the 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

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 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/ with the following contents:

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/

… 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):

auth       include  system-auth
account    include  system-auth
account optional /etc/pam.d/
#account optional debug log=/tmp/sasauth-mkhomedir.log /etc/pam.d/

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.

8 thoughts on “Auto Creation of Linux Home Directories for SAS Users”

  1. Very elegant, I like it! I’ve seen a couple of hacky ways of achieving this with Centrify based auths. This is the *correct* way of implementing this.

  2. Thanks for your thoughts Nik. I don’t know about it being ‘correct’ but it does the job 🙂

    Personally, I would prefer it if the sasauth module triggered PAM session handling, for the SAS Object Spawner client, and then no changes to the PAM config would be required – it would just work. I’ll try to remember to post a SASware Ballot idea for it.

  3. Readers might also be interested in this associated LinkedIn discussion:

    In particular Greg shares his thoughts on this topic as part of the wider topic of user provisioning.

    There is also the point that Samba does not, by default, obey PAM’s account and session management directives, and so the use of Samba would not trigger home directory auto-creation with oddjob-mkhomedir. In case that LinkedIn link get broken in future, I’ll leave the smb.conf directive that is supposed to enable that here for future reference:

    obey pam restrictions = yes

    When I get a chance to try it out, I’ll add another comment with findings.

  4. It doesn’t work. My sasauth doesn’t even include this script because no log file appear in tmp file.
    My error contains message: The launch of the server process failed because of an invalid or inaccessible SASUSER library

  5. Ok it’s working

    I was using centrify, I updated sasauth and removed ‘session’ & ‘password’ groups and of course I had to install
    yum install oddjob oddjob-mkhomedir (from: ) but like I said.. it seems that it wasn’t working at all I mean this -> “account optional debug log=/tmp/sasauth-mkhomedir.log /etc/pam.d/” wasn’t even included and executed. So I ran into that: because I thought that something is wrong with oddjob-mkhomedir. And I think you should put those information also:

    Steps to Reproduce:
    1. yum install dbus oddjob oddjob-mkhomedir
    2. service messagebus restart
    3. service oddjobd restart

    After that the service oddjobd started to working and was visible for dbus.
    Adding to oddjobd to startup was only a formality.

    chkconfig oddjobd on

    It would be nice to mention about that you need to start oddjobd after installation. Then I was able to see my log in /tmp/sasauth-mkhomedir.log

    It works.

  6. Thanks for posting your notes Konrad. I did’t need to manually start oddjobd as I assume it was either started post-installation or after a machine restart.

Leave a Reply

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