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    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.

15 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: https://www.linkedin.com/hp/update/6265492763559763968

    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: https://platformadmin.com/blogs/paul/2015/07/active-directory-authentication-for-sas-on-linux-with-realmd/ ) but like I said.. it seems that it wasn’t working at all I mean this -> “account optional pam_exec.so debug log=/tmp/sasauth-mkhomedir.log /etc/pam.d/sasauth-mkhomedir.sh” wasn’t even included and executed. So I ran into that: https://bugzilla.redhat.com/show_bug.cgi?id=634356 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.

  7. Hi Paul,

    We have a requirement where in access need to be provided to users who reside on mutiple active directories for our SAS 9.4 application.
    My question here is,whether steps mentioned under http://support.sas.com/kb/49/432.html would be sufficient or else third party tools like Metacoda Plugins or Quest Authentication Service need to installed to achieve the requirement.If yes,can you please guide to correct documentation or link.
    Also advise how different would be the steps for Microsoft Active Directory (AD) Domains contained within a single Forest or multiple domains from multiple trusted forests.

  8. Hi Ramakrishna,

    Firstly, Metacoda Plugins and Quest Authentication Service are used for different purposes. Quest will help you with configure the Linux host for authentication against Active Directory (AD). Metacoda Plug-ins will help you populate SAS metadata with the required identity (user and group) information from AD.

    For authentication, in addition to Quest, there are also other software packages you can use, both open source and commercial. In the commercial arena, I have had several people recommend Centrify to me. I haven’t had a chance to use it as yet, but it does seems popular. If you want to find out if Quest or Centrify support multi-domain and cross-forest authentication it would be best to contact the respective vendors. You might also want to investigate RedHat FreeIPA/IdM for its AD integration options.

    In my CentOS 7.3 environment, I have been using realmd (sssd) – see https://platformadmin.com/blogs/paul/2015/07/active-directory-authentication-for-sas-on-linux-with-realmd/ and https://platformadmin.com/blogs/paul/2015/01/iwa-sas-94m2-linux/ In the comments on the second post you will see that I have been able to use this method to authenticate with 2 domains in the same forest but not cross-forest authentication as yet. Additionally, whilst I can get IWA working with the primary domain, I have so far been unable to get IWA to work for users in secondary same-forest domains (I get “The destination buffer size was not sufficient for the requested password” and “Access denied” messages that I need to investigate further). When I get some time I will upgrade to 7.4 and see if I can resolve these issues.

    You might also want to follow a recent discussion in SAS Communities at https://communities.sas.com/t5/Administration-and-Deployment/ObjectSpawner-Authentication-for-Secondary-Domain/td-p/388790 where alexal, a SAS employee, mentioned that the recent RedHat Enterprise Linux 7.4 has a version of sssd that supports multi-domain AD-based login with unqualified userids (short names).

    Once you have authentication configured, for SAS identification, Metacoda Plug-ins can be used to synchronise AD users and groups into SAS metadata, for single domains, multiple domains in the same forest, and multiple domains in multiple forests. You can see an overview of each these scenarios at https://metacoda.github.io/idsync-utils/topics/ad-domains/

    I hope this helps.

    Cheers
    Paul

  9. Thanks alot for detailed explanation. Iam clear with these tools usage now.
    Do you think without tools like above,can we achieve authentication just by PAM when we have multiple multiple Active Directories?

    We would using either Linux 5 or 6 Operating systems.
    Can you please guide me to any documents/URLs for PAM authentication or approach to be followed for such configurations would be very useful.
    Below links I have already referred.But they have verified limited information.

    http://support.sas.com/documentation/installcenter/en/ikfdtnunxcg/66380/PDF/default/config.pdf
    http://support.sas.com/kb/49/432.html

    Thanks in advance

    Ramakrishna

  10. Hi Ramakrishna,

    It depends. For simple single domain environments, probably yes. For multiple domains within the same forest, maybe, depending on skills, versions, requirements for login formats and IWA etc. For multi-domain multi-forest maybe not. If you want more confidence in success and the ability to fall back on vendor support then you would probably want to choose one of the commercial or commercial-support options. RedHat FreeIPA/IdM looks promising and would probably be the first one I would choose now if I was starting from scratch or investigating for a customer.

    In terms of links, I don’t have really have much beyond those already contained in my past blog posts on the topics e.g.
    * https://platformadmin.com/blogs/paul/tag/active-directory/
    * https://platformadmin.com/blogs/paul/tag/iwa/

    A couple of extra interesting resources I saw regarding RedHat FreeIPA/IdM:
    * http://rhelblog.redhat.com/tag/active-directory/
    * https://www.socallinuxexpo.org/sites/default/files/presentations/Integrating%20Linux%20systems%20with%20Active%20Directory%20Using%20Open%20Source%20Tools%20SCALE%2015x%202017.pdf

    Cheers
    Paul

Leave a Reply

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