new blog 2.0


0x05. [LPIC-301] LDAP - make use of LDAP: nss_ldap and pam_ldap

Note: if you configure this for the first time, make sure you pick a proper Linux distribution (clients). I have tested it on different Linuces and especially distros being "too user friendly" and those "security-enhanced" ones might have a little confusing pre-defined configuration and things won't go as described below, at least not quite.

As our directory is a little more secure than it used to be, we can start serving some sensitive data like personal information, preferences or, more importantly, login credentials. Creating an LDAP users database from scratch can be a tedious process, especially if you already have a ready /etc/passwd file or a NIS/NIS+ infrastructure. This is where PADL MigrationTools come in handy. The software can be downloaded from the PADL website. Once we have our databases migrated, we can start pulling information about our user from the OpenLDAP server and authenticate them with pam_ldap, both plug-ins are downloadable from

I will kick off with a few words of introduction to every package.
MigrationTools - a collection of perl and shell scripts which help you convert your existing NIS, NIS+, NetInfo or flat file databases like fstab, hosts, services etc into ldap-readable LDIF format. It is also possible to dump these databases directly to the ldap server either with ldapadd (with running slapd) or with slapadd (slapd is down, dump goes directly into the database file).
MigrationTools do not require too much customization. You should remember to change $DEFAULT_MAIL_DOMAIN, $DEFAULT_BASE and $DEFAULT_MAIL_HOST in according to your dc base, otherwise your LDIF entries will contain "dc=padl,dc=com" suffix.

Let's say, I want to migrate two entries from my /etc/passwd file:
porta MigrationTools-47 # grep -E "princess|spitfire" /etc/passwd > passwd
porta MigrationTools-47 # cat passwd
princessnatalka:x:1001:100:Princess Natalka,1,085313373,087654321,Sharp:/home/princessnatalka:/bin/bash
spitfire:x:1002:100:Spit Fire,2,(1231)1029384756,6574839201,If I was in WWII they'd call me spitfire:/home/spitfire:/bin/bash
porta MigrationTools-47 # ./ ./passwd passwd.ldif
porta MigrationTools-47 # cat passwd.ldif
dn: uid=princessnatalka,ou=People,dc=padl,dc=com
uid: princessnatalka
cn: Princess Natalka
objectClass: account
objectClass: posixAccount
objectClass: top
objectClass: shadowAccount
userPassword: {crypt}$1$fMFhgCEB$v44E8xfZA2PSIGv5.QXmY.
shadowLastChange: 13849
shadowMax: 99999
shadowWarning: 7
loginShell: /bin/bash
uidNumber: 1001
gidNumber: 100
homeDirectory: /home/princessnatalka
gecos: Princess Natalka,1,085313373,087654321,Sharp
nss_ldap - This is a plug-in for Name Service Switch on a Linux / Solaris system. If you think you need to catch up with NSS, I recommend the manual (5) page for nsswitch.conf file. Basically, we want the system calls, e.g. struct passwd *getpwent(), to grab the information about users from LDAP if the users are not found in /etc/passwd file. nss_ldap binds to the LDAP server, looks up the appropriate entry, translates the content into getpwent-readable format of username:password:uid:gid:gecos:home:shell and points the function to it.
This library very often comes pre-compiled with the distribution. In case it's not, you can download it from PADL website and compile it.
In order to enable nss_ldap you need to edit /etc/nsswitch.conf. An example file follows:
# /etc/nsswitch.conf:

passwd: files ldap
shadow: files ldap
group: files ldap

hosts: files dns
networks: files dns
I have placed my "ldap" entries behind "files". As a result, if there are two accounts with the same posix name in /etc/passwd and LDAP database, NSS will read the local entry and ignore the one from LDAP. In other words, local entries have higher priority and the LDAP entries will be read in every time when there is no matching local account.

nss_ldap configuration file is ldap.conf. Refer to the manual page for details.

NOTE: If after changing your nsswitch.conf you are having hard times booting up you may want to set the bind_policy to soft in ldap.conf. It will soften the policy of reconnecting to an unavailable LDAP server. The default hard_open keeps reconnecting thus preventing the system to boot.

Now, let's see the outcome of our changes:
$ finger spitfire
Login: spitfire Name: Spit Fire
Directory: /home/spitfire Shell: /bin/bash
Office: 2, (1231)1029384756 Home Phone: 657-483-9201
Last login Sun Dec 2 18:11 (GMT) on pts/1 from
No Mail.
No Plan.

On many systems nss_ldap is enough to authenticate an LDAP user on the local system. If you want to have extended functionality for LDAP users, e.g. password changing, keep reading...
pam_ldap - finally authenticating users. Fortunately, configuring PAM is quite easy, especially, if you have common-[auth|password|account] files in your /etc/pam.d/ directory. These files will be included into all authentication services as their common part. Please find my sample common-* files from an OpenSUSE installation below:
auth required
auth sufficient try_first_pass
auth required
account sufficient
account required
password requisite nullok cracklib
password sufficient try_first_pass
password required nullok use_authtok

Given an example of my sshd pam-aware daemon, if the configuration file looks like as follows...
auth requisite
auth include common-auth
account include common-account
password include common-password
session required
session include common-session

... my sshd service will be fully LDAP enabled. The same about other services which include common-* files.

NOTE: It's a good idea to add use_first_pass or try_first_pass options to in the PAM configuration files, otherwise both modules will ask you for your password separately. In the worst case, if you try to change your password over LDAP with the passwd command, you will be prompted for your password as many as 4 times!!!

In order to be able to change passwords we should apply specific ACLs. This will be discussed in the next post, for now a very ugly ACL. Append these two lines to your slapd.conf
access to *
by * write
Let's perform a test...

$ ssh spitfire@princess
Have a lot of fun...
spitfire@princess:~> passwd
Changing password for spitfire.
Enter login(LDAP) password:
New Password:
Reenter New Password:
LDAP password information changed for spitfire

No comments: