About this document
Original author: Jason Nance <jbnance>
Research by: John-Paul Robinson <jpr>
This doc is an overview of the configuration of pam_ldap for user authentication using UAB's ldap server for password validation and your own ldap server for account enumeration.
NOTE :: This doc does NOT detail the setup of your ldap server, but does assume you have a working configuration and a knowledge of how to add/modify entries.
Introduction
The primary role of a sys admin is to keep machines secure, stable, and efficient for users to get work done on without hindering their progress with obscure setups or crazy security procedures. Given the wide spectrum of computer (il)literacy amongst the users we support, it's nice when some tool comes along that not only helps keep our systems more secure, but also simplifies the lives of the users we support. When used appropriately, pam_ldap is one such tool.
Disclaimer
This document has been written in good faith as a guide to setting up a service on your server. That being said, I cannot be held responsible for any actions described within that result in damage, data loss, or any other undesired effect. This is a guide, not a bible. Do research, read other documentation, use common sense, have backups, follow basic system administration standards and practices - including security - and above all, think about what you are doing.
Requirements
- An installed Unix (Linux) system with pam_ldap, nss_ldap, and, optionally, pam_access.
- Right to create/modify entries on a working ldap server.
- root privileges on the system(s) that are to be configured.
Important: The pam_ldap and nss_ldap libraries are packaged differently on various linux distributions.
You should check to ensure that both libraries are installed prior to following these instructions to avoid
confusion. It is known that RedHat packages both libraries in the nss_ldap RPM whereas SuSE packages each
library in it's own RPM, pam_ldap and nss_ldap respectively.
The files edited in this guide all require root privileges. I recommend you use sudo.
Password Validation
We want users' passwords to be validated off of UAB's ldap server. To do this, we will setup a special config file for the pam_ldap library in the auth stack (covered later). You can call this file whatever you want.
/etc/auth_ldap.conf:
ssl start_tls
ssl on
ssl on
uri ldaps://ldap.uab.edu/
base ou=People,dc=uab,dc=edu
Pay special attention to the ssl start_tls and ssl on lines. Failure to add these results in your users having their BlazerID and password sent in clear text over the network!
Note: It is likely that you will also need to include a "tls_cacertfile" or "tls_cacertdir" configuration parameter whenenver using the "ssl start_tls" in each of your ldap configuration files. According to
the OpenLDAP FAQ, versions of OpenLDAP 2.1 and above will not make TLS connections unless this parameter is set and correctly specifies a trusted certificate authority for your LDAP server. Later model Linux distributions should come with a ca-bundle file in the OpenSSL distribution that includes the root certificates for the CA used by UAB's LDAP server. A line like the following added to the above file should work on RHEL4.
tls_cacertfile /usr/share/ssl/certs/ca-bundle.crt
User Validation
Our user validation comes from our (departmental) ldap server which we have permission to add users and groups that have access to our systems. On a standard Linux system, there are two files that need to be configured.
/etc/ldap.conf:
ssl start_tls
ssl on
suffix "dc=myDept,dc=uab,dc=edu"
ssl on
suffix "dc=myDept,dc=uab,dc=edu"
uri ldaps://myLDAP.myDept.uab.edu/
pam_password_prohibit_message Please visit http://www.uab.edu/blazerid/ to change your password.
ldap_version 3
pam_filter objectclass=posixAccount
pam_login_attribute uid
pam_member_attribute memberuid
nss_base_passwd ou=People,dc=eng,dc=uab,dc=edu
nss_base_shadow ou=People,dc=eng,dc=uab,dc=edu
nss_base_group ou=Group,dc=eng,dc=uab,dc=edu
nss_base_hosts ou=Hosts,dc=eng,dc=uab,dc=edu
scope one
The pam_password_prohibit_message directive spits out a nice little message telling users where they should actually be going to change their password when they attempt a change (ie - run passwd).
/etc/openldap/ldap.conf:
BASE dc=myDept,dc=uab,dc=edu
URI ldaps://myLDAP.myDept.uab.edu/
URI ldaps://myLDAP.myDept.uab.edu/
TLS_REQCERT allow
Your ldap server must have posix user entries that coincide with the BlazerID of the users you want to have access to your systems. Do NOT put password entries in your local ldap server - that part is handled by the UAB server.
Note: It may seem odd that there are three ldap.conf files with similar information and that the two files /etc/ldap.conf and /etc/openldap/ldap.conf are almost identical. This duplication stems from the fact that the pam_ldap and nss_ldap are distributed by PADL.com and the LDAP command-line tools are distributed by OpenLDAP.org.
By default, a system with the nss_ldap and pam_ldap packages installed will include a the file /etc/ldap.conf. This is the compiled-in default location for
LDAP configuration information that influences these two libraries. The /etc/auth_ldap.conf file is added to this configuration in order to enable pam_ldap to authenticate users against the BlazerID LDAP service. The /etc/openldap/ldap.conf is used by the OpenLDAP client commands like ldapsearch and ldapwhoami. Depending on your distribution, it may be necessary to install these LDAP client commands explicitly. The LDAP command-line tools, however, are not required for the authentication and account integration. They are simply useful tools to assist with debugging.
PAM System Stack
Recent versions of PAM include a stack module that allows for a single file full of requirements for authentication. Your system stack file should look something like this.
/etc/pam.d/system-auth:
#%PAM-1.0
auth required /lib/security/pam_env.so
auth sufficient /lib/security/pam_unix.so likeauth nullok
auth sufficient /lib/security/pam_ldap.so use_first_pass config=/etc/auth_ldap.conf
auth required /lib/security/pam_deny.so
account required /lib/security/pam_access.so
account sufficient /lib/security/pam_unix.so
account sufficient /lib/security/pam_ldap.so
account required /lib/security/pam_deny.so
password required /lib/security/pam_cracklib.so retry=3
password sufficient /lib/security/pam_unix.so nullok md5 shadow use_authtok
password sufficient /lib/security/pam_ldap.so use_authtok
password required /lib/security/pam_deny.so
session required /lib/security/pam_limits.so
session required /lib/security/pam_unix.so
session required /lib/security/pam_mkhomedir.so skel=/etc/skel/ umask=0077
session optional /lib/security/pam_ldap.so
We are doing a couple things here. First, in the auth section, we are telling PAM to use UAB's ldap server to validate the password. Second, we are telling PAM to use our ldap server to validate usernames (anyone with an account in ldap appears the same as if they had an account in /etc/passwd). This is where our last point comes in - pam_access. Since you may want to limit who can login to what machines, you can make changes to /etc/security/access.conf and limit based on username and group membership.
Name Service
Finally, we want the system to know where to look to find a list of users, groups, etc.
/etc/nsswitch.conf:
passwd: files ldap
shadow: files ldap
group: files ldap
shadow: files ldap
group: files ldap
Of course, you should leave your remaining entires for services, protocols, etc. Also, if you store a list of hosts in your ldap server, you could add that to the list.
Once all of these changes are made, you can verify that the user list is getting enumerated correctly by running:
getent passwd
You could get a list of the users not only in /etc/shadow, but on your ldap server as well.
That's it! Have fun!
LDAP Authn for Solaris
[phpwiki]
!! Setting up Solaris
These instructions are for Solaris circa 2.8 and 2.9 but may apply to later releases. Please provide feedback of experiences.
The solution is to replace the Solaris pam_ldap library with the [pam_ldap libarary from padl.com|http://www.padl.com/Contents/OpenSourceSoftware.html]. This library will do normal LDAP interaction and not expect the configuration infrastructure that Sun's implementation requires.
Compiling the library should not be too difficult, but you might find the comments in ["Compiling the PAM and nss modules"|http://www.bolthole.com/solaris/LDAP.html] useful. Specifically, I don't know if the need to compile OpenSSL still exists.
After the replacement dynamic library is compiled it can simply be referenced and hooked in for authn. See the main documentation above for guidance on the configuration of the PAM files.
Something to be aware of with *all* unix authn against UAB's LDAP is that you have to just do the authn part, not the authz/account definition lookup part (i.e. there is no posix schema in UAB's LDAP). The account definition will come either from a local /etc/passwd file or a local LDAP or NIS-base account database. If you don't have more than one box or don't mind editing multiple /etc/passwd files, you can just use the /etc/passwd file to define the accounts.
A further note: the complexities with native Solaris LDAP clients come from the expectation that the LDAP server will serve both authn and account information and that the LDAP server is part of the trusted system domain of the Solaris client. This is not the case when you simply use the UAB LDAP server for authn.
[This document|http://docs.lucidinteractive.ca/index.php/Solaris_LDAP_client_with_OpenLDAP_server] describes how to integrate Solaris LDAP clients with OpenLDAP and within them they are specifically addressing this relationship assumption. This is not the direction to follow if you just want authn but you might find it useful for a more complete understanding.