Getting Started with OpenLDAP, Part 5

In Part 4, we created an OpenLDAP-based address book with basic data. In this article, we will focus on centralised network authentication—a basic requirement of the networked world.

Modern-day users centrally authenticate to a plethora of services that range from webmail service providers and office desktop passwords to ticket-booking sites for travel, entertainment, etc. Most of these sites and office servers save at least the username/password attributes in a centralised directory. In this article, we will configure Linux clients for authentication through a centralised directory.

The address book we created in in Part 4 can be extended to include various attributes, such as photograph, date of birth, home address, work address and many more, if required. For customised requirements, we can create our own ObjectClasses and attributes, but generally we should avoid this, since it can create issues of compliance and standardisation.

The LDAP-based addressbook is very useful, especially when creating a centralised organisational global address list to be used with e-mail clients such as Thunderbird, Evolution, MS Outlook, etc. Another very important use of LDAP within organisations is to provide centralised authentication and authorisation.

We are going to configure Linux clients for authentication through a centralised directory. The proposed setup is as described below:

  • Directory Server: OpenLDAP server on RHEL 5.4 (openldap-servers-2.3.43-3.el5 RPM installed), with a configured IP address of 192.168.122.1.
  • Network client: Fedora Core 12 with the IP address 192.168.122.244 (leased by a DHCP server in the network).

Currently, the client uses its own authentication files: /etc/passwd and /etc/shadow. The possible entries in its user database can be checked using the getent command, as shown below:

[vbg@vbg-work openldap]$ getent passwd
root:x:0:0:root:/root:/bin/bash
bin:x:1:1:bin:/bin:/sbin/nologin
daemon:x:2:2:daemon:/sbin:/sbin/nologin
adm:x:3:4:adm:/var/adm:/sbin/nologin
lp:x:4:7:lp:/var/spool/lpd:/sbin/nologin
.
.
.
vbg:x:500:501:Varad Gupta:/home/vbg:/bin/bash

The /etc/passwd file provides certain fields required for authentication. Each line represents one database entry. As an example, look at the last line of the above output. The format for the above entry is:

login (or uid):x:UID Number:GID Number:GECOS:Home Directory:Login Shell

The password, as we all know, comes from the /etc/shadow file.

To authenticate from a central LDAP directory, we need an ObjectClass that provides all of these required attributes. The ObjectClasses that provide us the attributes for Linux/UNIX authentication are: posixAccount and shadowAccount.

These are defined in the nis.schema schema file, and are also mentioned below:

objectclass ( 1.3.6.1.1.1.2.0 NAME 'posixAccount'
        DESC 'Abstraction of an account with POSIX attributes'
        SUP top AUXILIARY
        MUST ( cn $ uid $ uidNumber $ gidNumber $ homeDirectory )
        MAY ( userPassword $ loginShell $ gecos $ description ) )

objectclass ( 1.3.6.1.1.1.2.1 NAME 'shadowAccount'
        DESC 'Additional attributes for shadow passwords'
        SUP top AUXILIARY
        MUST uid
        MAY ( userPassword $ shadowLastChange $ shadowMin $
              shadowMax $ shadowWarning $ shadowInactive $
              shadowExpire $ shadowFlag $ description ) )

We can use the above ObjectClasses to create a directory of users with passwords. However, Linux authentication also requires groups (as listed in the /etc/group file). The corresponding object class, posixGroup is defined thus:

objectclass ( 1.3.6.1.1.1.2.2 NAME 'posixGroup'
        DESC 'Abstraction of a group of accounts'
        SUP top STRUCTURAL
        MUST ( cn $ gidNumber )
        MAY ( userPassword $ memberUid $ description ) )

As you can see from the above, posixAccount and shadowAccount ObjectClasses are both auxiliary. We will need a structural class to create the entry. Normally, the ObjectClass account is used to provide a structural class to the entry.

An LDIF file containing the required entries for all users of an organisation can be created. Alternatively, various GUI tools can be used to enter this data into the directory.

Fortunately, the openldap-servers RPM also installs a migration tool, which contains a set of scripts in the /usr/share/openldap/migration/ directory. These scripts are very handy when it comes to creating LDIF files from files.

Pages: 1 2 3

Leave a Reply

Your email address will not be published. Required fields are marked *