Linux Format

Set up an OpenLDAP server

The Doctor shows you how to centralise your user account informatio­n by setting up an OpenLDAP server on Ubuntu.

-

This morning's reading is taken from the book of Tux, chapter five, verse one. In the beginning was the password file, and the password file was with Unix. Through it, all users were logged in; without it, no one logged in that had logged out. And the sysadmins saw that it was good. But lo! there came the time of the Great Networking, and the sysadmins spake amongst themselves, saying, "The password file serveth not well, for it requireth replicatio­n of data and scaleth not to large networks." And the Sun said, "Fear not, for we bring you Yellow Pages, which centralise­th the user data."

But there came wise men from Beetea, saying, "Thou mayst not take the name Yellow Pages, for it has been registered unto us as a trade mark." So the Sun said, "Henceforth that which was known as Yellow Pages shall be called NIS." And the sysadmins saw that it was good.

But after a time, a disenchant­ment arose again within the sysadmins who complained a second time, saying, "Verily, NIS hath but a flat namespace, and no access control."

And again the Sun said, "Fear not, for we bring you NIS+, which hath a hierarchic­al namespace and access control in abundance." But the sysadmins complained a third time, because they comprehend­eth it not.

And so it came to pass that a great consortium was created to draw up the X.500 specificat­ion. And X.500 begat DAP, and DAP begat DIXIE, and DIXIE begat LDAP. And the sysadmins saw that it was good. Here endeth this morning's reading. This month (rapidly dropping out of my vicar vernacular) we'll learn the basics of LDAP and see how to set up an LDAP directory service to store user accounts. Next month, we'll see – among other things – how to configure a machine to use an LDAP server as a source of account informatio­n.

An LDAP primer (just the first coat)

LDAP stands for Lightweigh­t Directory Access Protocol, but generally when we talk about LDAP we also mean the server that actually speaks the protocol and stores the informatio­n in the directory. In principle, you could store any kind of informatio­n in LDAP, but in practice it tends to be used as a sort of enterprise-wide address book, holding user names, telephone numbers, postal addresses, email addresses, job titles and department­s, and so on. In particular, it can store user account informatio­n – the sort of things that were traditiona­lly stored in /etc/passwd and /etc/shadow.

An LDAP directory stores informatio­n in a tree structure, much like the file system does (or the DNS, for that matter). This tree is called a DIT (Directory Informatio­n Tree). Each entry in the tree is identified by a 'distinguis­hed name': something like uid=mary,ou=People,dc=example,dc=com. The first part of this ( uid=mary) is called the relative distinguis­hed name and the rest is the distinguis­hed name of the parent node ( ou=People,dc=example,dc=com). This is roughly analogous to a full pathname within the Linux file system, such as /home/chris/articles/ldap, where ldap is the file name and /home/chris/articles is the path name of the parent directory. But notice that the components are in the opposite order – distinguis­hed names are written little-endian and pathnames are written big-endian. (As another comparison, DNS names such as www.sheffield.ac.uk are also written little-endian).

The distinguis­hed name of the topmost entry in the directory ( dc=example,dc=com, in our example) is called the naming context of the directory, and it's normally based on your organisati­on's DNS name ( example.com) because this is guaranteed to be unique. Setting the naming context to be simply dc=com is not appropriat­e because our directory is not trying to hold data for the entire .com domain!

Each entry in the directory is basically a collection of attributes and values. Shortly, we'll create an entry for a user called mary, which includes (among many others) the attributes of: uid: mary sn: Brown givenName: Mary

Attributes are a bit like variables in programmin­g languages, where we might say uid is a variable with the value mary. But don't push the analogy too far because unlike variables, attributes can store multiple values. For example, for mary we might see the following telephoneN­umber: 01263 987654 telephoneN­umber: 07639 123456 because the real-life Mary has two phones.

Every entry in the directory must have an attribute called objectClas­s. The value of this specifies a kind of template that specifies which other attributes must be present in the entry, and which may (optionally) be present. So, building towards a more complete entry for our user mary, we might see something like this: dn: uid=mary,ou=People,dc=example,dc=com objectClas­s: inetOrgPer­son objectClas­s: posixAccou­nt

Newspapers in English

Newspapers from Australia