An Introduction to LDAP

MichaelDonnelly

If you workin the computing industry, the chances are good that you've heard of LDAPby now. Wondering what all the excitement is about? Want to know a littlemore about the underlying technology? You've come to the right place. Thisintroduction - the first in a series of articles describing howto design, implement, and integrate an LDAP environment at your company- will familiarize you with the concepts behind LDAP while leaving thereally hardcore details for later. Here, we'll touch on the following topics:

• Whatis LDAP, anyway?
• Whenshould you use LDAP to store your data?
• Thestructure of an LDAP directory tree
• IndividualLDAP records
• Customizingyour directory's object classes
• Anexample of an individual LDAP entry
• LDAPreplication
• Securityand access control

Tostart with, what's happening with LDAP today is exciting. A company-wideLDAP implementation can enable almost any application, running on almostany computer platform, to obtain information from your LDAP directory.And that directory can be used to store a broad range of data: email addressand mail routing information, HR data, public security keys, contact lists,and much more. By making an LDAP directory a focal point in your systemsintegration, you're providing one-stop shopping whenever people go lookingfor information within your company - even if the primary source of thedata lives elsewhere.

Butwait, you say. You're already using an Oracle, Sybase, Informix, or MicrosoftSQL database to store much of that same data. How is LDAP different? Whatmakes it better? Read on.

Whatis LDAP, anyway?

TheLightweight Directory Access Protocol, better known as LDAP, is based onthe X.500 standard, but significantly simpler and more readily adaptedto meet custom needs. Unlike X.500, LDAP supports TCP/IP, which is necessaryfor Internet access. The core LDAP specifications are all defined in RFCs -- a complete list of LDAP-related RFCs may be found at theLDAPman RFC page.

Using"LDAP" in a sentence
Ineveryday conversation, you'll hear well-intentioned people say things like,"Should we be storing that in LDAP?" or "Just get that data from the LDAPdatabase," or "How do we go about tying LDAP into an RDB?" Strictly speaking,though, LDAP isn't a database at all, but a protocol used to access informationstored in an information directory (also known as an LDAP directory). Amore precise formulation might look something like this: "Using LDAP, datawill be retrieved from (or stored in) the correct location within our informationdirectory." But you won't find me correcting anyone on this point: eitherway, you get the idea across, and that's what counts.

Isan LDAP information directory a database?
Justas a Database Management System (DBMS) from Sybase, Oracle, Informix, orMicrosoft is used to process queries and updates to a relational database,an LDAP server is used to process queries and updates to an LDAP informationdirectory. In other words, an LDAP information directory is a typeof database, but it's not a relational database. And unlike databasesthat are designed for processing hundreds or thousands of changes per minute- such as the Online Transaction Processing (OLTP) systems often used ine-commerce - LDAP directories are heavily optimized for read performance.

Theadvantages of LDAP directories
Nowthat we've straightened that out, what are the advantages of LDAP directories?The current popularity of LDAP is the culmination of a number of factors.I'll give you a few basic reasons, provided you keep in mind that it'sjust part of the story.

Perhapsthe biggest plus for LDAP is that your company can access the LDAP directoryfrom almost any computing platform, from any one of the increasing numberof readily available, LDAP-aware applications. It's also easy to customizeyour company's internal applications to add LDAP support.

TheLDAP protocol is both cross-platform and standards-based, so applicationsneedn't worry about the type of server hosting the directory. In fact,LDAP is finding much wider industry acceptance because of its status asan Internet standard. Vendors are more willing to write LDAP integrationinto their products because they don't have to worry about what's at theother end. Your LDAP server could be any one of a number of open-sourceor commercial LDAP directory servers (or perhaps even a DBMS server withan LDAP interface), since interacting with any true LDAP server involvesthe same protocol, client connection package, and query commands. By contrast,vendors looking to integrate directly with a DBMS usually must tailor theirproduct to work with each database server vendor individually.

Unlikemany relational databases, you do not have to pay for either client connectionsoftware or for licensing.

MostLDAP servers are simple to install, easily maintained, and easily optimized.

LDAPservers can replicate either some or all of their data via push or pullmethods, allowing you to push data to remote offices, to increase security,and so on. The replication technology is built-in and easy to configure.By contrast, many of the big DBMS vendors charge extra for this feature,and it's far more difficult to manage.

LDAPallows you to securely delegate read and modification authority based onyour specific needs using ACIs (collectively, an ACL, or Access ControlList). For example, your facilities group might be given access to changean employee's location, cube, or office number, but not be allowed to modifyentries for any other fields. ACIs can control access depending on whois asking for the data, what data is being asked for, where the data isstored, and other aspects of the record being modified. This is all donethrough the LDAP directory directly, so you needn't worry about makingsecurity checks at the user application level.

LDAPis particularly useful for storing information that you wish to read frommany locations, but update infrequently. For example, your company couldstore all of the following very efficiently in an LDAP directory:

• Thecompany employee phone book and organizational chart
• Externalcustomer contact information
• Infrastructureservices information, including NIS maps, email aliases, and so on
• Configurationinformation for distributed software packages
• Publiccertificates and security keys

Whenshould you use LDAP to store your data?

MostLDAP servers are heavily optimized for read-intensive operations. Becauseof this, one can typically see an order of magnitude difference when readingdata from an LDAP directory versus obtaining the same data from a relationaldatabase server optimized for OLTP. Because of this optimization, however,most LDAP directories are not well suited for storing data where changesare frequent. For instance, an LDAP directory server is great for storingyour company's internal telephone directory, but don't even think of usingit as a database back end for your high-volume e-commerce site.

Ifthe answer to each of the following questions is Yes, then storing yourdata in LDAP is a good idea.

• Wouldyou like your data to be available cross-platform?
• Doyou need to access this data from a number of computers or applications?
• Dothe individual records you're storing change a few times a day or less,on average?
• Doesit make sense to store this type of data in a flat database instead ofa relational database? That is, could you effectively store all the datafor a given item in a single record?

Thisfinal question often gives people pause, because it's very common to accessa flat record to obtain data that's relational in nature. For example,a record for a company employee might include the login name of that employee'smanager. It's fine to use LDAP to store this kind of information. Ruleof thumb: If you can imagine storing your data in a large electronic Rolodex,you can store it easily in an LDAP directory.

Thestructure of an LDAP directory tree

LDAPdirectory servers store their data hierarchically. If you've seen the top-downrepresentations of DNS trees or UNIX file directories, an LDAP directorystructure will be familiar ground. As with DNS host names, an LDAP directoryrecord's Distinguished Name (DN for short) is read from the individualentry, backwards through the tree, up to the top level. More on this pointlater.

Whybreak things up into a hierarchy? There are a number of reasons. Here area few possible scenarios:

• Youmay wish to push all your US-based customer contact information to an LDAPserver in the Seattle office (which is devoted to sales), whereas you probablydon't need to push the company's asset management information there.
• Youmay wish to grant permissions to a group of individuals based on the directorystructure. In the example listed below, the company's asset managementteam might need full access to the asset-mgmt section, but not to otherareas.
• Combinedwith replication, you can tailor the layout of your directory structureto minimize WAN bandwidth utilization. Your sales office in Seattle mightneed up-to-the minute updates for US sales contacts, but only hourly updatesfor European sales information.

Gettingto the root of the matter: Your base DN and you
Thetop level of the LDAP directory tree is the base, referred to as the "baseDN." A base DN usually takes one of the three forms listed here. Let'sassume I work at a US electronic commerce company called FooBar, Inc.,which is on the Internet at foobar.com.

o="FooBar, Inc.", c=US
(baseDN in X.500 format)
Inthis example, o=FooBar, Inc. refers to the organization, whichin this context should be treated as synonymous with the company name.c=USindicates that the company headquarters is in the US. Once upon a time,this was the preferred method of specifying your base DN. Times and fashionschange, though; these days, most companies are (or plan to be) on the Internet.And what with Internet globalization, using a country code in the baseDN probably made things more confusing in the end. In time, the X.500 formatevolved into the other formats listed below.

o=foobar.com
(baseDN derived from the company's Internet presence)
Thisformat is fairly straightforward, using the company's Internet domain nameas the base. Once you get past the o= portion (which stands fororganization=),everyone at your company should know where the rest came from. This was,until recently, probably the most common of the currently used formats.

dc=foobar,dc=com
(baseDN derived from the company's DNS domain components)
Aswith the previous format, this uses the DNS domain name as its basis. Butwhere the other format leaves the domain name intact (and thus human-readable),this format is split into domain components: foobar.com becomesdc=foobar,dc=com. In theory, this could be slightly more versatile, though it'sa little harder for end users to remember. By way of illustration, considerfoobar.com. When foobar.com merges with gizmo.com, you simply start thinkingof "dc=com" as the base DN. Place the new records into your existing directoryunder dc=gizmo, dc=com, and you're ready to go. (Of course, this approachdoesn't help if foobar.com merges with wocket.edu.) This is the formatI'd recommend for any new installations. Oh, and if you're planning touse Active Directory, Microsoft has already decided for you that this isthe format you wanted.

Timeto branch out: How to organize your data in your directory tree
Ina UNIX file system, the top level is the root. Beneath the root you havenumerous files and directories. As mentioned above, LDAP directories areset up in much the same manner.

Underneathyour directory's base, you'll want to create containers that logicallyseparate your data. For historical (X.500) reasons, most LDAP directoriesset these logical separations up as OU entries. OU stands for "OrganizationalUnit," which in X.500 was used to indicate the functional organizationwithin a company: sales, finance, et cetera. Current LDAP implementationshave kept the ou= naming convention, but break things apart bybroad categories like ou=people, ou=groups, ou=devices,and so on. Lower level OUs are sometimes used to break categories downfurther. For example, an LDAP directory tree (not including individualentries) might look like this:

    dc=foobar, dc=com 
        ou=customers 
            ou=asia 
            ou=europe 
            ou=usa 
        ou=employees 
        ou=rooms 
        ou=groups 
        ou=assets-mgmt 
        ou=nisgroups 
        ou=recipes

IndividualLDAP records

What'sin a name? The DN of an LDAP entry
Allentries stored in an LDAP directory have a unique "Distinguished Name,"or DN. The DN for each LDAP entry is composed of two parts: the RelativeDistinguished Name (RDN) and the location within the LDAP directory wherethe record resides.

TheRDN is the portion of your DN that is not related to the directory treestructure. Most items that you'll store in an LDAP directory will havea name, and the name is frequently stored in the cn (Common Name)attribute. Since nearly everything has a name, most objects you'll storein LDAP will use their cn value as the basis for their RDN. IfI'm storing a record for my favorite oatmeal recipe, I'll be using cn=OatmealDeluxe as the RDN of my entry.

• Mydirectory's base DN is dc=foobar,dc=com
• I'mstoring all the LDAP records for my recipes in ou=recipes
• TheRDN of my LDAP record is cn=Oatmeal Deluxe

Givenall this, what's the full DN of the LDAP record for this oatmeal recipe?Remember, it reads backwards - just like a host name in DNS.

cn=OatmealDeluxe,ou=recipes,dc=foobar,dc=com

Peopleare always more trouble than inanimate objects
Nowit's time to tackle the DN of a company employee. For user accounts, you'lltypically see a DN based either on the cn or on the uid(User ID). For example, the DN for FooBar's employee Fran Smith (loginname: fsmith) might look like either of these two formats:

uid=fsmith,ou=employees,dc=foobar,dc=com
(login-based)
LDAP(and X.500) use uid to mean "User ID", not to be confused withthe UNIX uid number. Most companies try to give everyone a unique loginname, so this approach makes good sense for storing information about employees.You don't have to worry about what you'll do when you hire the next FranSmith, and if Fran changes her name (marriage? divorce? religious experience?),you won't have to change the DN of the LDAP entry.

cn=FranSmith,ou=employees,dc=foobar,dc=com
(name-based)
Herewe see the Common Name (CN) entry used. In the case of an LDAP record fora person, think of the common name as their full name. One can easily seethe downside to this approach: if the name changes, the LDAP record hasto "move" from one DN to another. As indicated above, you want to avoidchanging the DN of an entry whenever possible.

Customizingyour directory's object classes

You can useLDAP to store data on almost any type of object, as long as that objectcan be described in terms of various attributes. Here are a few examplesof information you might store:

• Employees: What'sthe employee's full name, login name, password, employee number, manager'slogin, mail server?
• Asset tracking:What's the computer name, IP address, asset tag, make and model information,physical location?
• Customer contactlists: What's the customer's company name? The primary contact's phone,fax, and email information?
• Meeting room information:What's the room name, location, seating capacity, telephone number? Isthere wheelchair access? Is there an overhead projector?
• Recipe information:Give the name of the dish, the list of ingredients, the type of cuisine,and instructions for preparing it.

Because your LDAPdirectory can be customized to store any type of text or binary data, whatyou store is really up to you. LDAP directories use the concept of objectclasses to define which attributes are allowed for objects of any giventype. In almost every LDAP implementation, you'll want to extend the basicfunctionality of your LDAP directory to meet your specific needs, eitherby creating new object classes or by extending existing ones.

LDAP directoriesstore all information for a given record's entries as a series of attributepairs, each one consisting of an attribute type and an attribute value.(This is completely different from the way relational database serversstore data, in columns and rows.) Consider this portion of my recipe record,as stored in an LDAP directory:

  dn: cn=Oatmeal Deluxe, ou=recipes, dc=foobar, dc=com 
  cn: Instant Oatmeal Deluxe 
  recipeCuisine: breakfast 
  recipeIngredient: 1 packet instant oatmeal 
  recipeIngredient: 1 cup water 
  recipeIngredient: 1 pinch salt 
  recipeIngredient: 1 tsp brown sugar 
  recipeIngredient: 1/4 apple, any type

Note that in thiscase, each ingredient is listed as a value of attribute type recipeIngredient.LDAP directories are designed to store multiple values of a single typein this fashion, rather than storing the entire list in a single databasefield with some sort of delimiter to distinguish the individual values.

Because thedata is stored in this way, the shape of the database can be completelyfluid - you don't need to recreate a database table (and all its indexes)to start tracking a new piece of data. Even more important, LDAP directoriesuse no memory or storage to handle "empty" fields - in fact, having unusedoptional fields costs you nothing at all.

Anexample of an individual LDAP entry

Let's lookat an example. We'll use the LDAP record of Fran Smith, our friendly employeefrom Foobar, Inc. The format of this entry is LDIF, the format used whenexporting and importing LDAP directory entries.

  dn: uid=fsmith, ou=employees, dc=foobar, dc=com
  objectclass: person
  objectclass: organizationalPerson
  objectclass: inetOrgPerson
  objectclass: foobarPerson
  uid: fsmith
  givenname: Fran
  sn: Smith
  cn: Fran Smith
  cn: Frances Smith
  telephonenumber: 510-555-1234
  roomnumber: 122G
  o: Foobar, Inc.
  mailRoutingAddress: [e-mail]
  mailhost: mail.foobar.com
  userpassword: {crypt}3x1231v76T89N
  uidnumber: 1234
  gidnumber: 1200
  homedirectory: /home/fsmith
  loginshell: /usr/local/bin/bash

To start with,attribute values are stored with case intact, but searches against themare case-insensitive by default. Certain attributes (like password) arecase-sensitive when searching.

Let's breakthis entry down and look at it piece by piece.

  dn: uid=fsmith, ou=employees, dc=foobar, dc=com

This is the fullDN of Fran's LDAP entry, including the whole path to the entry in the directorytree. LDAP (and X.500) use uid to mean "User ID," not to be confusedwith the UNIX uid number.

  objectclass: person 
  objectclass: organizationalPerson 
  objectclass: inetOrgPerson 
  objectclass: foobarPerson

One can assignas many object classes as are applicable to any given type of object. Thepersonobject class requires that the cn (common name) and sn(surname) fields have values. Object Class person also allowsother optional fields, including givenname, telephonenumber, and so on.The object class organizationalPerson adds more options to thevalues from person, and inetOrgPerson adds still moreoptions to that (including email information). Finally, foobarPersonis Foobar's customized object class that adds all the custom attributesthey wish to track at their company.

  uid: fsmith 
  givenname: Fran 
  sn: Smith 
  cn: Fran Smith 
  cn: Frances Smith 
  telephonenumber: 510-555-1234 
  roomnumber: 122G 
  o: Foobar, Inc.

As mentioned before,uidstands for User ID. Just translate it in your head to "login" wheneveryou see it.

Note that thereare multiple entries for the CN. As mentioned above, LDAP allows some attributesto have multiple values, with the number of values being arbitrary. Whenwould you want this? Let's say you're searching the company LDAP directoryfor Fran's phone number. While you might know her as Fran (havingheard her spill her guts over lunchtime margaritas on more than one occasion),the people in HR may refer to her (somewhat more formally) as Frances.Because both versions of her name are stored, either search will successfullylook up Fran's telephone number, email, cube number, and so on.

  mailRoutingAddress: [e-mail] 
  mailhost: mail.foobar.com

Like most companieson the Internet, Foobar uses Sendmail for internal mail delivery and routing.Foobar stores all users' mail routing information in LDAP, which is fullysupported by recent versions of Sendmail.

  userpassword: {crypt}3x1231v76T89N 
  uidnumber: 1234 
  gidnumber: 1200 
  gecos: Frances Smith 
  homedirectory: /home/fsmith 
  loginshell: /usr/local/bin/bash

Note that Foobar'ssystems administrators store all the NIS password map information in LDAPas well. At Foobar, the foobarPerson object class adds this capability.Note that the user password is stored in UNIX crypt format. The UNIX uidis stored here as uidnumber. Mind you, there's a whole RFC onstoring NIS information in LDAP. I'll talk about NIS integration in a futurearticle.

LDAPreplication

LDAP serverscan be set to replicate some or all of their data, on a push or a pullbasis, using simple authentication or certificate-based authentication.

For example,Foobar has a "public" LDAP server running on ldap.foobar.com, port 389.This server is used by Netscape Communicator's pinpoint email addressingfeature, the "ph" command from UNIX, and other locations where a user wouldwant to query for the phone number of an employee or customer contact.The company's master LDAP server is running on the same system, but onport 1389 instead.

You wouldn'tnecessarily want employees searching the directory to query against assetmanagement or recipe data, nor would it be desirable to see IT accounts(like "root") showing up on the company directory. To accomodate theseunpleasant realities, Foobar replicates selected directory subtrees fromits master LDAP server to its "public" server. The replication excludessubtrees containing data they wish to hide. To keep things current at alltimes, the master directory server is set to do immediate push-based synchronization.Note that this approach is designed for convenience, not security: theidea is to allow power users to simply query the other LDAP port if theywant to search all available data.

Let's say Foobaris managing its customer contact information via LDAP, over a low bandwidthconnection between Oakland and Europe. They might set up replication fromldap.foobar.com:1389 to munich-ldap.foobar.com:389 as follows:

  periodic pull: ou=asia,ou=customers,o=sendmail.com
  periodic pull: ou=us,ou=customers,o=sendmail.com
  immediate push: ou=europe,ou=customers,o=sendmail.com

The pull connectionswould keep things in sync every 15 minutes, which would probably be justfine in this scenario. The push connection would guarantee that any changemade to the European contact information would be pushed out to Munichimmediately.

Given thisreplication scheme, where would users connect to access their data? Usersin Munich could simply connect to their local server. If they were makingchanges to the data, the local LDAP server would refer those changes tothe master LDAP server, which would then push all the changes back to thelocal LDAP server to keep it in sync. This is of tremendous benefit tothe local user: all their LDAP queries (mostly reads) are against theirlocal server, which is substantially faster. When it's time to make a changeto their information, end users needn't worry about reconfiguring theirclient software, because the LDAP directory servers handle the data exchangefor them.

Securityand access control

LDAP providesfor a complex level of access control instances, or ACIs. Because the accesscan be controlled on the server side, it's much more secure than securitymethods that work by securing data through client software.

With LDAP ACIs,you can do things like:

• Grant users theability to change their home phone number and home address, while restrictingthem to read-only access for other data types (such as job title or manager'slogin).
• Grant anyone inthe group "HR-admins" the ability to modify any user's information forthe following fields: manager, job title, employee ID number, departmentname, and department number. There would be no write permission to otherfields.
• Deny read accessto anyone attempting to query LDAP for a user's password, while still allowinga user to change his or her own password.
• Grant managersread-only permission for the home phone numbers of their direct reports,while denying this privilege to anyone else.
• Grant anyone inthe group "host-admins" to create, delete, and edit all aspects of hostinformation stored in LDAP.
• Via a Web page,allow people in "foobar-sales" to selectively grant or deny themselvesread access to subsets of the customer contact database. This would, inturn, allow these individuals to download the customer contact informationto their local laptops or to a PDA. (This will be most useful if your salesforce automation tool is LDAP-aware.)
• Via a Web page,allow any group owner to add or remove any entries from groups they own.For example, this would allow sales managers to grant or remove accessfor salespeople to modify Web pages. This would allow owners of mail aliasesto add and remove users without having to contact IT. Mailing lists designatedas "public" could allow users to add or remove themselves (but only themselves)to or from those mail aliases. Restrictions can also be based on IP addressor hostname. For example, fields can be made readable only if the user'sIP address begins with 192.168.200.*, or if the user's reverse DNS hostnamemaps to *.foobar.com.

This will giveyou an idea what's possible using access control with LDAP directories,but be aware that a correct implementation requires much more informationthan is given here. I'll discuss access control in greater detail in afuture article.

 

---

That's it fornow. I hope you've found this article useful. If you have comments or questions,send email to [e-mail].

28 april 2000