Set up an OpenLDAP server
The Doctor shows you how to centralise your user account information 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 replication of data and scaleth not to large networks." And the Sun said, "Fear not, for we bring you Yellow Pages, which centraliseth 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 disenchantment 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 hierarchical namespace and access control in abundance." But the sysadmins complained a third time, because they comprehendeth it not.
And so it came to pass that a great consortium was created to draw up the X.500 specification. 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 information.
An LDAP primer (just the first coat)
LDAP stands for Lightweight Directory Access Protocol, but generally when we talk about LDAP we also mean the server that actually speaks the protocol and stores the information in the directory. In principle, you could store any kind of information 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 departments, and so on. In particular, it can store user account information – the sort of things that were traditionally stored in /etc/passwd and /etc/shadow.
An LDAP directory stores information in a tree structure, much like the file system does (or the DNS, for that matter). This tree is called a DIT (Directory Information Tree). Each entry in the tree is identified by a 'distinguished name': something like uid=mary,ou=People,dc=example,dc=com. The first part of this ( uid=mary) is called the relative distinguished name and the rest is the distinguished 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 – distinguished 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 distinguished 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 organisation's DNS name ( example.com) because this is guaranteed to be unique. Setting the naming context to be simply dc=com is not appropriate 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 programming 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 telephoneNumber: 01263 987654 telephoneNumber: 07639 123456 because the real-life Mary has two phones.
Every entry in the directory must have an attribute called objectClass. 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 objectClass: inetOrgPerson objectClass: posixAccount