{"id":317,"date":"2009-12-29T11:16:00","date_gmt":"2009-12-29T11:16:00","guid":{"rendered":"https:\/\/questy.org\/?p=317"},"modified":"2024-09-26T19:12:57","modified_gmt":"2024-09-26T19:12:57","slug":"ldap-administration-iii-odds-n-ends","status":"publish","type":"post","link":"https:\/\/questy.org\/index.php\/2009\/12\/29\/ldap-administration-iii-odds-n-ends\/","title":{"rendered":"LDAP Administration III – “Odds ‘n Ends”"},"content":{"rendered":"\n

By now you should have a functional LDAP server, a properly configured client, and the ability to authenticate against your server.  However, the last couple \u201ccogs in the wheel\u201d are left to manage.<\/p>\n\n\n\n

Generally speaking, when you add a user in UNIX-land, part of the process of the adduser command also sets their shell, creates a home directory for them and so forth.  As you may notice, there is no particular method to make this happen in Linux-LDAP.  You just have a store and a tool to manage the store.<\/p>\n\n\n\n

Have no fear, it\u2019s PAM to the rescue.<\/p>\n\n\n\n

As we said in our first installment, the following packages are all that is necessary to have the basic plumbing of LDAP to work:<\/p>\n\n\n\n

openldap
openldap-servers
openldap-clients
openldap-devel<\/p>\n\n\n\n

While that is true, there are a couple more packages that put the finishing touches on this to make it sing.  Those are:<\/p>\n\n\n\n

nss nss_ldap nscd<\/p>\n\n\n\n

NSS is a glibc mechanism or interface allowing access to the common UNIX databases such as the password or hosts database.  It is most commonly used to provide an interface to both local \/etc\/passd and \/etc\/shadow files and usually for the purposes of interfacing with LDAP or NIS.<\/p>\n\n\n\n

NSS_LDAP is a set of C library extensions which allows X.500 and LDAP directory servers to be used as a primary source of name service information such as users, hosts, groups, and other such data historically managed via local flat files or a NIS infrastructure.<\/p>\n\n\n\n

NSCD is a name services caching daemon that provides a cache for the most common name requests.  While useful in speeding up response to queries, nscd has it\u2019s own set of problems.  I\u2019ll cover only some of it\u2019s usefulness, and you should circumspectly determine whether you will need caching at all based on your organization\u2019s size and the size of your serving infrastructure.<\/p>\n\n\n\n

Home Directories<\/strong><\/p>\n\n\n\n

First and foremost, to make the login process as pleasurable\/smooth an experience as possible, there are some things that we generally do in standard administration practices that ease the user\u2019s experience.  Namely, we setup a standard set of configuration and environment files to provide a consistent user experience of the shell.  These are usually their home directory files such as:<\/p>\n\n\n\n

.bashrc .bash_profile .bash_logout .vimrc .mozilla<\/p>\n\n\n\n

Usually these are handled in the usual way via the useradd command, which also copies one of everything from the \/etc\/skel directory to your user\u2019s home.<\/p>\n\n\n\n

As you can see, simply adding a user to the LDAP store would not give occasion for this to happen.  PAM to the rescue!  PAM contains a module that is their \u201cmkhomedir\u201d module.  Depending on your architecture, this lives in the \/lib or the \/lib64 directories under \u201csecurity\u201d:<\/p>\n\n\n\n

\/lib\/security\/pam_mkhomedir.so \/lib64\/security\/pam_mkhomedir.so<\/p>\n\n\n\n

What these modules do when properly invoked is on the first connection of a user that is validated as a proper user\/password combination via LDAP, PAM sees that they have no home directory, and creates the home directory for them just as if you, the administrator had created it with the adduser <\/strong>script.<\/em><\/p>\n\n\n\n

This, by far, is one of the handiest modules provided by PAM.<\/p>\n\n\n\n

Turning on the PAM<\/strong><\/p>\n\n\n\n

To turn on the mkhomedir facility for your servers and clients, simply do the following:<\/p>\n\n\n\n

In \/etc\/pam.d there are a number of configuration files for handling login defs for varying circumstances.  What we are interested in is system-auth<\/em>.  System-auth is also sourced by the sshd option, so this will work for both console logins and ssh\/remote logins.<\/p>\n\n\n\n

The last stanza of the system-auth configuration file is the \u201csession\u201d section.  On the second-to-last line between the pam_unix and pam_ldap designations, add the following:<\/p>\n\n\n\n

session     required     pam_mkhomedir.so<\/p>\n\n\n\n

This is a keyword set that tells Linux to load up and perform the functions offered by the pam_mkhomedir module.  Now, whenever you connect to a system configured in this way, it will automatically create the user\u2019s skel information and change ownerships to the proper settings so the user can login.<\/p>\n\n\n\n

Security<\/strong><\/p>\n\n\n\n

You may note that I also referred to using group-based security.  In LDAP\/PAM-land, this is just as simple as the above PAM setup.  Look into the individual system\u2019s \/etc\/security directory for a file called access.conf.  This file allows you to grant\/deny access to individual users, groups, and also where they can connect to this machine from.  The syntax is clearly explained in the file itself, but here\u2019s an example.<\/p>\n\n\n\n

Let\u2019s say I only want root, wheel, and the admins group to be able to access a certain system.  let\u2019s say they can access this system from anywhere.  Now let\u2019s say I also want the backup group to access the same system, but only from one host.  The setup is quite simple.  First, let\u2019s allow complete access to the people we wish to be able to connect from everywhere.  At the end of the \/etc\/security\/access.conf file, add the following line:<\/p>\n\n\n\n

+: root wheel admins : ALL<\/p>\n\n\n\n

This tells the system to add access for root, wheel, and admins from ALL hosts.  Now, let\u2019s put in those backup admins, but only allow them to connect from the host we want them to come from:<\/p>\n\n\n\n

+: backup : 10.1.10.10<\/p>\n\n\n\n

This means the backup group can access this host, but only from the host 10.1.10.10.  There are many other methods of allowing and denying access in this file.  The documentation is contained within the file, so feel free to look through it for more information.<\/p>\n\n\n\n

The MOST important line is the last line, however.  After you\u2019ve setup all the people you WANT to access the system, that does no good if all access is still left on for everyone, everywhere.  The final line in the file should be to deny all access to anyone else not specified above, and would look like this:<\/p>\n\n\n\n