The big picture

We plan to use information stored on a networked LDAP server to authenticate users who are logging in to your client machines. LDAP is a protocol to access structured information – and “structured information” is about as precise as it gets because you can define the exact items of information you want to store in your LDAP server yourself. For most common uses there are already such definitions available and we will use only stock definitions. LDAP servers are handy for this purpose because of their flexibility and some other features like ease of replication.

The authentication process works about like this: A user “foo” who wants to login to machine “client” enters her user name at the login prompt. Client uses the user name to look up the user’s record in the LDAP database, retrieves her password hash and prompts the user to enter her password. The password gets hashed, too, and compared against the hashed password from the LDAP server. If the two are the same, the user is granted access to her account. Please note that the LDAP server does not do the authentication. It only stores data about the users of your network.

The only difference between the above procedure and the “normal” (AKA the “traditional”) way of authenticating a user is that the password hash is retrieved from an LDAP server instead of a plain file. Because of this we use a library for authentication and related work that can be configured exactly where to take the relevant data from. This library is the name server switch or NSS library. The nice effect of using this library is that is it transparent for the affected programs. They only ask the NSS library for the information or services they want and the NSS library does the real work. The NSS library also gives proper information about the groups a user or a file belongs to and other important things.

To speed up the process and reduce network traffic we use the name service cache daemon, NSCD. If something does not work in your setup, your first try should be to restart the NSCD to make sure you are not working with cached data that is already out-dated.

The other piece of Linux infrastructure we are dealing with is PAM – pluggable authentication modules. The idea is similar as for the deployment of the NSS library: many programs and services have very similar needs for user authentication so the authentication process gets bundled at a central point that uses modules for easy extension.

Conventions

In the following setup we use a mix of locally defined accounts and groups and those that reside in the LDAP server. To avoid ID clashes we use group ids in the range of 6000 and up. The same holds for user ids. The standard Debian IDs are lower than 1000 and the first users get IDs around 1000 so this should give us enough space.

On the clients

Because you might probably want your network users and groups also be known on your LDAP server the following steps should be also performed on the server itself – not only on just the “real” clients.

Installation

 # apt-get install libnss-ldap nscd
 # reboot

Maybe it is actually necessary to also install libpam-ldap. We will check that later and edit this file accordingly.

The reboot is super important to make your Linux box actually use the NSS stuff. If you don’t reboot the machine you might end up with a system that does not work like you want without giving any reason why. (This is first hand knowledge – I spent like 4 hours in various log files before I went home. When I came back I “just” tried if it worked and it did – the only difference between the unsuccessful and the successful tries being the reboot. You could hear me smacking my head throughout the building.)

Configuration

Now that the NSS library is installed and working you have to create a couple of files from these templates:

/etc/nsswitch.conf

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

hosts: files dns networks: files

protocols: db files services: db files ethers: db files rpc: db files

netgroup: nis

The use of files ldap allows you to login as root even if the LDAP server is down. Plus you don’t have to copy all users over to the LDAP server – only those that are not part of the Debian base install.

Edit /etc/libnss-ldap.conf to contain these definitions and else nothing but comments:

host ldap.icafe.az-muelheim.de
base o=NIS
ldap_version 3
rootbinddn cn=admin,o=NIS
bind_policy soft
pam_filter objectclass=posixAccount
pam_login_attribute uid
pam_password crypt

/etc/ldap.secret

test

The file ldap.secret contains the password that is used to gain root privileges on the LDAP server so your next command really should be:

 # chmod 600 /etc/ldap.secret

On the server

Installation

 # apt-get install slapd
 # mkdir /var/lib/ldap-accounts

Configuration

Edith /etc/ldap/slapd.conf to look like this:

 # This is the main slapd configuration file. See slapd.conf(5) for more
 # info on the configuration options.

####################################################################### # Global Directives:

# Features to permit #allow bind_v2

# Schema and objectClass definitions include /etc/ldap/schema/core.schema include /etc/ldap/schema/cosine.schema include /etc/ldap/schema/nis.schema include /etc/ldap/schema/inetorgperson.schema

# Schema check allows for forcing entries to # match schemas for their objectClasses's schemacheck on

# Where the pid file is put. The init.d script # will not stop the server if you change this. pidfile /var/run/slapd/slapd.pid

# List of arguments that were passed to the server argsfile /var/run/slapd.args

# Read slapd.conf(5) for possible values loglevel 256 #loglevel 4095

# Where the dynamically loaded modules are stored modulepath /usr/lib/ldap moduleload back_bdb moduleload back_ldbm

####################################################################### # Specific Backend Directives for bdb: # Backend specific directives apply to this backend until another # 'backend' directive occurs backend bdb checkpoint 512 30

####################################################################### # Specific Backend Directives for 'other': # Backend specific directives apply to this backend until another # 'backend' directive occurs #backend

# DB #1 include /etc/ldap/slapd.accounts.conf

In this setup slapd.conf contains global config options. Options for the databases are put in separate files – in our example slapd.accounts.conf. Thus, the next file to create is slapd.accounts.conf like this:

 #######################################################################
 # Database specific directives apply to this databasse until another
 # 'database' directive occurs
database        bdb

# The base of your directory in database #1 suffix "o=NIS"

rootdn "cn=admin,o=NIS" rootpw "test"

# Where the database file are physically stored for database #1 directory "/var/lib/ldap-accounts"

# Indexing options for database #1 index objectClass eq index uid,cn,sn,mail pres,eq,approx,sub

# Save the time that the entry gets modified, for database #1 lastmod on

# Where to store the replica logs for database #1 # replogfile /var/lib/ldap/replog

# The userPassword by default can be changed # by the entry owning it if they are authenticated. # Others should not be able to see it, except the # admin entry below # These access lines apply to database #1 only access to attrs=userPassword by dn="cn=admin,o=NIS" write by anonymous auth by self write by * none

# Ensure read access to the base for things like # supportedSASLMechanisms. Without this you may # have problems with SASL not knowing what # mechanisms are available and the like. # Note that this is covered by the 'access to *' # ACL below too but if you change that as people # are wont to do you'll still need this if you # want SASL (and possible other things) to work # happily. access to dn.base="" by * read

# The admin dn has full write access, everyone else can read everything. access to * by dn="cn=admin,o=NIS" write by * read

Now the server is configured and we have to populate the LDAP database with a directory structure. For this purpose we first create a file that contains the needed information. Just save the following lines as template.ldif:

dn: o=NIS
objectclass: organization
o: NIS

dn: cn=admin, o=NIS objectclass: person cn: admin sn: admin description: "Admin of the account database"

dn: ou=people, o=NIS objectclass: organizationalUnit ou: people

dn: ou=group, o=NIS objectclass: organizationalUnit ou: group

Then issue at the command prompt:

 # /etc/init.d/slapd stop
 # slapadd -n 1 -l template.ldif
 # /etc/init.d/slapd start

You can use the following LDIF file to create a group (edit the details to suit your needs, then import the LDIF like template.ldif was added above):

dn: cn=groupname, ou=group, o=NIS
objectclass: top
objectclass: posixGroup
cn: groupname
gidnumber: 6000
memberuid: userid1
memberuid: userid2 ...

The following file can be used to add a user account:

dn: cn=SomeNameForThisAccount, ou=people, o=NIS
cn: SomeNameForThisAccount
sn: Second Name
objectclass: top
objectclass: person
objectclass: posixAccount
objectclass: shadowAccount
uid: username-in-the-linux-system
userpassword:password
uidnumber: 6000
gidnumber: 6000
gecos: Additional Info (GECOS)
loginShell:/bin/bash
homeDirectory: /home/username-in-the-linux-system
shadowLastChange:10877
shadowMin: 0
shadowMax: 999999
shadowWarning: 7
shadowInactive: 0
shadowExpire: 0
shadowFlag: 0

These examples are very short and probably won’t work. The field userpassword should contain a crypted hash of the user’s password because in /etc/libnss_ldap.conf we used the option pam_password crypt.

We strongly encourage you to use the program gq to actually change anything in the LDAP database and to create user accounts and groups. The following section deals with creating a user and assigning a password.

Creating a User

Stay tuned for more.