Notes - Small Scale LDAP HOWTO

[Last 5] [Last 10] [Index] [RSS Feed] [Full .plan]
Contact Me
Todo Chart (aka: How busy is Dylan?)


ZFS Timeline Forensics
Honours Thesis
BSDCan 2014 Presentation
ZFS/ZDB Plaso Parsers


C and C++
more notes...


Assorted little scripts and apps.
Commandline/Android ToDo list stored in a text file.
Android Apps
more software...

Game Mods

A Max Payne 2 mod - more realistic and deadly.
more mods...


C Helpdesk Resources
Customising Your CS Account
more RMITCS stuff...

Roleplaying Games

Shadowrun Notes(4th ed)
Heavy Gear Notes(2nd ed)
more RPG stuff...


Examples of my University work.


Old Image Gallery
Trombone slide position chart [PDF]
[Back to home page]
[Back to Index]

[Raw XML]
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.

LDAP Data Model Introduction

This is the most important thing to learn, and get right, first. This affects how your database and directory are set up.

How to format entries (LDIF) - Part 1

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

# 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

Things to note about the example:

Structure of your tree (DIT)


Directory Structure/Hierarchy:

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.

Choosing ObjectClasses

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:

Person Classes:

Must have sn (surname) and cn (common name) - optionally may have userPassword, telephoneNumber, seeAlso, description. As this isn't much, subclasses of person are usually used.
Inherits from person; no more required attributes, but includes many optional ones such as postal address, and lots of junk like teletexTerminalIdentifier.
The most common class to represent a person in an organisation.
Inherits from organizationalPerson; no extra required attributes; many useful optional attributes including employeeNumber, givenName, mobile, uid, mail... even jpegPhoto.

Account Classes:

Must have a userid; may have description, organizationalUnitName, host and a few others.
For Unix/Posix account details. Could be used as an alternative to one of the person classes above.
Compulsory: cn, uid, uidNumber, gidNumber, homeDirectory; Optional: userPassword, loginShell, gecos, description

Other Common Classes:

Used for DNS components (see examples above), this has one required attribute (DC), and no others.
Used to represents organisational units at any level or scale, up to an including the organisation itself.
"ou" (organisational unit name) is the only required attribute; optional ones include userPassword (for shared account passwords), description, many forms of address and phone/fax numbers.
Often used to set up Roles which may be filled by one or more users, like "WebAdmin", "TechSupport", "Postmaster", "SecurityOfficer" "etc.
Similar structure to organizationalUnit, but requires "cn" (common name) instead of "ou" and has no userPassword attribute.

Less Common Classes:

Requires "o" (organisation name); similar in structure to organizationalUnit, even includes userPassword.
Requires "cn", optional attributes include serialNumber, owner, "ou" and "o"

Using LDAP as a contact directory

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!)

Work in Progress

TODO: Installation and choosing backends, Slapd configuration, the bad-security defaults, etc.

Generated Sat, 17 Jan 2015 11:14:49 +1100
Copyright © 2002-2014 Dylan Leigh.
[HTML 4.01 Transitional]