Solaris, ldap config, and mkhomedir

Title:

Solaris/ldap integration

Author:

Douglas O’Leary <dkoleary@olearycomputers.com>

Description:

ldap commands under solaris and how to implement mkhomedir

Disclaimer:

Standard: Use the information that follows at your own risk. If you screw up a system, don’t blame it on me…

Overview:

I’m more familiar with ldap on linux systems so getting ldap fully functional on a solaris 9 box turned into quite the entertaining battle. The mkhomedir functionality that’s implemented via the pluggable authentication module, in linux, was particularly troubling.

Home directories:

SUN suggested method:

Linux systems, at least redhat based ones, create home directories as part of the pam.d config as follows:

# grep mkhomedir /etc/pam.d/sshd
session    required     pam_mkhomedir.so skel=/etc/skel umask=0077
# locate pam_mkhomedir.so
/lib/security/pam_mkhomedir.so

SUN apparently thinks that creating/manipulating home directories is outside the scope of PAM and, based on their UNIX philosophy, is redundant as evidenced by one response to a request for the mkhomedir module on Oracle’s Technology Network (OTN):

Are you all going completely insane? These are anomalies that you bring with you from Linux world into Solaris where they are completely redundant [[short-snip]] Solaris has a build-in automounter that can solve both issues. Existed since the dawn of day. For example of how to auto-create homedirs with the Solaris automounter see my blog posting This requires no external software, no C code that must be compiled, etc. All it requires is that you know how to make a shell script.

Yes, the right answer for Solaris is to use automounted home directories, exported from the localhost to the localhost, and an executable map. This discussion assumes an environment in which home directories aren’t centrally managed. If they are centrally managed in your environment, you’ve probably already stumbled across this little trick.

While a detailed discussion of the automounter is beyond the scope of this ll entry, a short example of a stereotypical configuration in a solaris environment is in order:

• Users’ home directories are maintained on a centralized system and mounted under /home as needed.

• The configuration for this would be:

  • /etc/auto_master: /home      auto_home

  • /etc/auto_home: * ${svr}:/export/home/&

• Using this simple example, anytime I access /home/doug.oleary, my home directory gets automatically mounted from ${svr}:/export/home/doug.oleary and unmounted some time after I’ve logged out.

To automatically create home directories, we simply replace the auto_home map with an executable script.

So, how does one configure a solaris box to automatically create home directories using the automounter?

Configuration Process:

1. update /etc/dfs/dfstab and start NFS server:

   # grep -v ^# /etc/dfs/dfstab
   share -F nfs -o rw=localhost -d "home dirs" /export/home
   # /etc/init.d/nfs.server start
   

2. Update /etc/auto_master:

   # cat /etc/auto_master
   /home           /usr/local/bin/mkhomedir
   

3. Create /usr/local/bin/mkhomedir & set perms:

   # cat /usr/local/bin/mkhomedir
   #!/bin/ksh
   
   ###########################################################
   # mkhomedir: script executed via automounter by references
   #            to /home subdirectories.
   # Author:    Doug O'Leary
   # Created:   08/21/13
   # Reference: http://znogger.blogspot.com/2010/05/solaris-automatic-creation-of-home-dirs.html
   ###########################################################
   
   Homedir=/home
   Physdir=/export/home
   User=$1 # should be in form: doug.oleary
   Dev="${Physdir}/${User}"
   
   ## home dir exists.
   if [ -d ${Dev} ]
   then
           echo "localhost:${Dev}"
           exit
   fi
   
   ## home dir doesn't exist.
   mkdir -p -m 700 ${Dev}
   for f in /etc/skel/*
   do
           cp ${f} ${Dev}/${f##*local}
   done
   
   gid=$(id ${User} | awk '{print $2}' | sed 's/(.*//g' | \
           awk -F= '{print $2}')
   [[ ${#gid} -eq 0 ]] && gid="sys"
   
   chown ${User}:${gid} ${Dev}
   
   echo "localhost:${Dev}"
   exit
   
   # chmod 1755 /usr/local/bin/mkhomedir
   

4. start autofs:

   # /etc/init.d/autofs start
   

5. Test by removing the /export/home/${user} directory and accessing the box as that user

# rm -fr /export/home/doug.oleary
# ssh -l doug.oleary localhost
Password:
Last login: Wed Aug 21 14:37:29 2013 from my_originating_host
Sun Microsystems Inc.   SunOS 5.9       Generic May 2002
bash-2.05$ pwd
/home/doug.oleary

Conversion process:

The configuration process above shows how you would configure a new solaris system out of the box. On existing systems, people will probably complain if we simply blast their home directories, so we need a conversion process as follows:

1. Obtain an outage. Disable/turn off any processes using the /home directory.

2. Verify sufficient space in /export/home for the home directories currently under /home. Troubleshoot as necessary:

   • du -sk /home

   • df -k /export/home

3. Move current home directories: mv /home/* /export/home

4. Configure the automounter as described above:

   • /etc/dfs/dfstab

   • /etc/auto_master

   • /usr/local/bin/mkhomedir

   • nfs.server

   • autofs

5. Test by accessing an existing user’s home directory then by accessing the system with a user id who’s home directory either doesn’t exist or can be removed:

   • cd /home/doug.oleary

   • cd /home/${new_user}

6. Troubleshoot as needed.

Alternatives and discussion:

The only real alternative that my research showed was compiling the pam_mkhomedir module on solaris. While this is doable, and apparently works for some, I argue against it for the following reasons:

• Unlike most other UNIX OSes, the automounter on Solaris has been fully functional, tried, tested, for over 20 years. Admins that came up in other OSes are probably very skittish about using it as the history of the automounter for any non-solaris UNIX was troubled at best. Over the past 7 - 10 years, though, the automounter has gotten quite stable on every OS on which I’ve tried it (Linux, various flavors, and HPUX) - to the point that I strongly recommend it for any NFS mounts that aren’t tempoary in nature. Short version for those admins from other flavors: Get over it.

• Tying into the first line, I’d trust the automounter on Solaris much more than I would trust a non-oracle supplied compiled program, especially one that was written for linux. The automounter’s been abused on solaris for decades. Based on the research, few people have managed to get the pam_mkhomedir even functional on solaris systems up through solaris 10.

• The automounter ties into SUN’s UNIX philosophy ie: The network is the computer. Without over anthropomorphizing, I feel it makes and admin’s job easier, in the long run, if you respect the philosophy with which the system was built. Shorter version: You don’t treat a linux box like a solaris box; you shouldn’t treat a solaris box like a linux one.

• By the way, this same logic argues against using the automounter for linux systems for the exact same reason. Even though the automounter option should work, the mkhomedir pam module is the way to go on linux systems for the exact reasons specified above.

There is a potential security concern although, if you consider it, you’ll find it’s mostly a non-player.

First, you have to configure and start two services that may not have been running previously. There are few, if any, real concerns related to the automounter itself as it simply reads configuration files and does what those tell it to. The concern w/the automounter would be to ensure that its configuraiton files are protected.

NFS, on the other hand, has a rather rich security history. Even with that, It can be, has been , and is being used in secure environments. As long as it’s configured properly, few if any security incidents will be enabled. Security audits of all flavors (PCI, SOX, etc) all allow for NFS in secure environments. Specific to the automounted home directories, these directories are being mounted from the localhost only. NFS is not leaving the box so the NFS security concern is even more mitigated.

Commands:

• /usr/lib/ldap/ldap_cachemgr: daemon to manage client connections

# /usr/lib/ldap/ldap_cachemgr -g

cachemgr configuration:
server debug level          0
server log file "/var/ldap/cachemgr.log"
number of calls to ldapcachemgr        917

cachemgr cache data statistics:
Configuration refresh information:
  Configured to NO REFRESH.
Server information:
  Previous refresh time: 2013/08/20 05:38:39
  Next refresh time:     2013/08/20 17:38:39
  server: primary.myco.com, status: UP
  server: alternate.myco.com, status: UP
Cache data information:
  Maximum cache entries:          256
  Number of cache entries:          0

• ldaplist: search/list naming information from ldap directory.

# ldaplist -l passwd doug.oleary
dn: uid=doug.oleary,ou=People,dc=corp,dc=myco,dc=com
        shadowLastChange: 15744
        mail: doug.oleary@myco.com
        objectClass: top
        objectClass: person
        objectClass: organizationalPerson
        objectClass: iorgperson
        objectClass: posixAccount
        objectClass: shadowAccount
        loginShell: /bin/bash
        sn: OLeary
        gidNumber: 600
        uidNumber: 770
        givenName: Doug
        uid: doug.oleary
        cn: Doug OLeary
        homeDirectory: /home/doug.oleary

• ldapclient: initialize ldap client or output client profile

# ldapclient list
NS_LDAP_FILE_VERSION= 2.0
NS_LDAP_BINDDN= uid=proxy,ou=ServiceAccounts,ou=People,dc=corp,dc=myco,dc=com
NS_LDAP_BINDPASSWD= [[snipped]]
NS_LDAP_SERVERS= prmary.myco.com, alternate.myco.com
NS_LDAP_SEARCH_BASEDN= dc=corp,dc=myco,dc=com
NS_LDAP_AUTH= tls:simple
NS_LDAP_CREDENTIAL_LEVEL= proxy
NS_LDAP_SERVICE_SEARCH_DESC= passwd:ou=people,dc=corp,dc=myco,dc=com?sub
NS_LDAP_SERVICE_SEARCH_DESC= group:ou=Groups,dc=corp,dc=myco,dc=com?sub
NS_LDAP_SERVICE_SEARCH_DESC= shadow:ou=People,dc=corp,dc=myco,dc=com?sub

• solaris version of ldapsearch

# ldapsearch -h ${primary}  -b "dc=corp,dc=myco,dc=com" objectclass=* cn | \
grep ^cn | head
cn=Directory Administrators,dc=corp,dc=myco,dc=com
cn=Directory Administrators
[[snipped]]

• Native ldapsearch doesn’t support ssl; however, /usr/iplanet/ds5/shared/bin/ldapsearch does. Verifying ssl is functional can be done as follows:

# alias ldapsearch=/usr/iplanet/ds5/shared/bin/ldapsearch
# ldapsearch -Z -h ${primary} -b dc=corp,dc=myco,dc=com uid=doug.oleary
SSL initialization failed: error -8174 (security library: bad database.)
# ldapsearch -Z -P /var/ldap/cert7.db -h ${primary} \
-b dc=corp,dc=myco,dc=com uid=doug.oleary homedirectory
version: 1
dn: uid=doug.oleary,ou=People,dc=corp,dc=myco,dc=com
homedirectory: /home/doug.oleary

• ldapaddent: Creates ldap entries from corresponding /etc/files.

Summary:

So, the shortest, cleanest, and most supportable method of automatically creating user home directories upon first access appears to be the automounter. This document covers how to initially configure a solaris system to use an executable map for automounted home directories and how to convert an existing system to this paradigm. Additionally, I documented some of the commands that I’ve found while searching for this process and troubleshooting the authentication issues.

Let me know if you have any questions, comments, or concerns.

Doug O’Leary