Introduction to LDAP and how to set up a SOHO LDAP server..
This document assumes:
Examples are for FreeBSD and may need adjusting for other OS.
This is the most important thing to learn, and get right, first. This affects how your database and directory are set up.
LDIF is the LDAP Data Interchange Format, and is generally how LDAP entries are inserted into and exported from the system (regardless of how they are stored internally).
e.g.: User Dylan, part of organisational unit students, at the foobar Australian university at foobar.edu.au: # Suffix / Root / Base: rootdn: dc=foobar,dc=edu,dc=au # The student group: dn: ou=student,dc=foobar,dc=edu,dc=au ObjectClass: organizationalUnit cn: student # The staff group: dn: ou=staff,dc=foobar,dc=edu,dc=au ObjectClass: organizationalUnit ou: staff # My entry: dn: cn=Dylan,ou=students,dc=foobar,dc=edu,dc=au ObjectClass: person cn: Dylan sn: Leigh userPassword: secret telephoneNumber: 01234567
Note the use of the "staff" and "student" organisational units in the example above. The directory structure can be as simple or complex as you wish, but it is often best to go with a simpler (i.e. flatter) structure, and put details such as the department or school in an attribute of the entry. A flatter structure is easier to search, write queries for, and maintain in general.
You will often want to perform a search on all users. With a complex hierarchy, a recursive search on a large chunk of the tree to find all users is more complex and risks missing some by getting the query wrong. On the other hand, if all users are in one group or unit, the search is simple. The opposite problem (performing a query on just one department or school) is easily accomplished in a flat hierarchy by filtering on an attribute such as "school=science".
A modification example: When Alice changes major from Science to Engineering you can just change the "school" or "department" attribute. If the schools were seperated in the hierarchy, you have to move her entry in the tree. This is a more complex operation, and involves changing the canonical name of her entry, possibly breaking something which depended on that name, and possibly causing a name clash.
For these reasons, non-complex organisations are best served by a very flat hierarchy - the structure below is common:
Suffix / Root / Base: dc=xyzzy,dc=org The people group, with everyone: ou=people,dc=xyzzy,dc=org Everyone's DN: cn=[username],ou=people,dc=xyzzy,dc=org
A hierarchical structure is most important when you have multiple servers and are delegating some of the work to others (beyond the scope of this document). Also, where entries have significantly different requirements, such as between staff and students, or employees and customers, these should generally be seperated in the hierarchy. But don't put things like school, office, or department in the hierarchy - these should be attributes.
One particular use of a hierarchy with OrganisationalUnit is where you want to create a shared account on a service between all users. Look at the Object Class below for more details.
This should be easy, but its not. LDAP comes with schemas of many classes, most of which almost (but not quite) do what you want, but include lots of other stuff you don't care about.
Note that classes themselves have a hierarchy like OOP classes; some inherit from others, and inherit the compulsory and noncompulsory attributes of their parent class. Some example classes and their attributes:
As can be seen from the attributes above, a lot more can be stored in LDAP than just usernames, passwords and access rights. You can store address and other contact details of your organisation, other organisations you work with, device inventory....
The disadvantage of putting everything in LDAP is that it means merging your authorization database and your contact database. You may not want to expose the same system you use to store passwords and determine access rights to use as a general purpose phone directory. It is best for security to keep your security systems free from other tasks.
That said, there are some hardware devices which do their authentication and authroization and contact information lookups all via LDAP. If you're working with those, to make use of their capabilities you will need to store contact details in LDAP and make sure the access control is set so they have access to contact attributes but not secret attributes (like userPassword!)
TODO: Installation and choosing backends, Slapd configuration, the bad-security defaults, etc.