Newbie questions about LDAP

Matthew Seaman m.seaman at
Thu Jun 22 06:28:32 BST 2006

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: quoted-printable

Stephen Allen wrote:
> Please accept my apologies if my newbie-ness is annoying...
> I sort of know what LDAP does (in a very limited way) but before
> installing it on my test FreeBSD box (my learning box!) I'm trying to
> understand it.  I've done some reading but not really found the answers=

> I need, either because of the author's prior assumptions or my prior
> (mis)conceptions.
> I know you Active Directory uses LDAP for dishing out AD stuff.
> I know many places use LDAP for dealing with email address books.
> My conceptions were that LDAP is simply a protocol for accessing a
> database of some sort, that database could store anything, not just use=
> account information.  Also, I think I read that you need only specify a=

> skeleton dataset for LDAP and you could store whatever you liked.
> Most of the articles only mention LDAP as a way of retrieving user
> account information and it's now confused me.
> If I install an LDAP server of some sort, could I configure it to store=
> let's say... "name, address, email address, telephone" then configure i=
> also to store another dataset, for example... "part number, price,
> quantity" without having 2 separate databases lying around?
> Or have I got it wrong again... is LDAP just a method of accessing
> normal database backends?  I just can't seem to find explanations (in
> easy English) how it all fits together.

LDAP is, as you say, a database (and as the name suggests, a
protocol for accessing that database.)  The big deal is that it
is a hierarchical database, more similar to the DNS in organization
than it is to MySQL or PostgreSQL type relational databases.

Where the basic structure in a relational database is a table of data,
with many rows each containing the same types of data; the basic
structure of an LDAP database is a tree where each node has a parent
and may have children. The data stored at each node does not have to
bear any relationship to parents, siblings or children.

The consequences of this structure are that with LDAP, horizontal
scaling is easy and natural: if your server is overloaded, you can
delegate a chunk of its namespace onto a different server -- something
that really isn't possible with a RDBMS.  It's also relatively simpler
to create multiple servers all serving the same tree of data for load
sharing, although doing similar replication tricks with RDBMSes is
pretty routine as well.

One consequence of the hierarchical structure is that data schemas
work rather differently under LDAP.  Instead of writing a custom data
schema to service  what ever application is using the database (as you
would with a RDBMS), you generally start out with a standard object
class such as eg. inetOrgPerson, and extend it. The object types are
defined centrally, often Internet wide by RFC.  Each node in the LDAP
tree can have one basic Structural Object type, to which can be added
various different overlays and extensions -- so you might add a samba
object on top of your inetOrgPerson objects to add the capability to
provide Samba account authentication. Objects of either type consist
of any number of data fields, a number of which will be mandatory but
many of which will be optional.  Entries may also be defined to be
unique, or there may be several copies of the same item in each object.
So the data for an inetOrgPerson object can have only one 'cn'
(Canonical Name) field, but may any number of 'mail' (E-mail Address)

In answer to your question above -- yes you can store two entirely
disparate types of data within the one LDAP tree.  Generally you'ld creat=
a couple of 'organisationalUnit' nodes at the top level of your tree,
say 'people' and 'inventory', and then populate those nodes with children=

of the appropriate types.  But you don't have to -- you could decide to
create subdirectories based on each of several different locations at
which your business operates, or based on the organisational structure
of your business.

The book 'LDAP System Administration' by Gerald Carter (O'Reilly 1st Ed
2003, ISBN 1565924916) is well worth getting hold of, and should answer
pretty much any questions you may have.



Dr Matthew J Seaman MA, D.Phil.                       7 Priory Courtyard
                                                      Flat 3
PGP:         Ramsgate
                                                      Kent, CT11 9PW

Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

Version: GnuPG v1.4.3 (FreeBSD)
Comment: Using GnuPG with Mozilla -



More information about the Ukfreebsd mailing list