LDAP Introduction: What is a directory? What is a directory service? What is LDAP? Who uses LDAP?

LDAP: Structure Information Model Naming Model Functional Model Version 3 Interconnectivity Evolving "web" Structure An LDAP browser?

What is a directory? Like a database, in that you can store information in it for later retrieval. However, a directory is designed for streamlined retrieval, not data manipulation. Contents are retrieved much more often then they are changed. No support for transactions or roll-back schemes. Inconsistencies between replicated versions tolerated as long as they get in into synchronization eventually.

What is a directory service? A directory service is a network protocol used for access plus the directory itself. May also involve schemes for data replication and distribution. Local services provide information in a limited context from a single directory, while global services are usually distributed. DNS is an example of a global directory service with a uniform namespace (stanford.edu, cs.stanford.edu). Email addresses are an example of both (henry.berg@stanford.edu). LDAP directories implement distributed reads, centralized writes.

What is LDAP? LDAP, the Lightweight Directory Access Protocol, is a client-server protocol for accessing and managing directory information. Originally developed as a lightweight front end to the X.500 Directory Access Protocol, an industrial strength directory service. X.500 too complicated and resource intensive for internet applications and PC users. LDAP runs directly over TCP/IP using simple string formats for data transport. Although originally used as a proxy for X.500 servers, LDAP is evolving into a standalone protocol for directories everywhere.

Who uses LDAP? Most major vendors of directory client and server products either support LDAP or have announced plans to support LDAP. Companies with LDAP intentions: Novell, Sun, HP, IBM/Lotus, SGI, AT&T, Banyan. Netscape Communicator and Eudora both support LDAP. Universities and government agencies are implementing LDAP servers for different kinds of information.

LDAP Structure Information model defines what kind of information can be stored in directory and how that information is structured. Naming model defines how information is organized and referenced. Like domain names, the name of any entry should be unique across all LDAP servers. Functional model defines how directory information is retrieved and modified.

LDAP Information Model LDAP central concept is the entry. Entries often composed around real-world concepts, people, organizations, objects, etc.. An entry is a named collection of attributes, which have type and value. Type of attribute has associated syntax defining allowed information. Which kind of schema is enforced for a given type of object is defined by values given to the objectclass attribute. The base object class is called the structural object class, additional classes added are auxiliary. Example: objectclass = person requires sn (surname), cn (common name) and allows a list of other attributes.

 Example attributes (*=defined in original RFC): cn *common name l *locality name st *state or province name o *organization name ou *organizational unit name (department, etc..) c *country name street *street address. jpegPhoto jpg picture A single attribute may have multiple values. My entry in Stanford's LDAP server: dn: cn=Henry Guyer Berg, ou=People, o=Stanford University, c=US cn: Henry.Berg sn: Berg userid: hgberg objectclass: person The relative distinguished name (RDN) in this case is "cn=Henry Guyer Berg"

LDAP Naming Model Directory entries arranged in a hierarchical treelike structure that reflects political, geographic or organizational boundaries. Countries are at the top (c=US, c=France, etc..). Position of entry in a hierarchy given by it's distinguished name (DN). Each component of a DN is called a relative distinguished name (RDN). Similar to a file system, except names are little endian with comma separators. Also, both leaf nodes and non leaf nodes may have content. All children of a parent entry must have different RDNs. An RDN may be composed of one or more attribute/value pairs (usually one). Alias entries are allowed, so the hierarchical structure can be circumvented.

LDAP Functional Model Supported operations: Interrogation: Search (node, one level down, whole sub-tree), Compare Update: Add, Delete, Modify, Modify RDN Authentication: Bind, Unbind, Abandon Searches require a combination of: A base DN to begin the search. A filter to determine which entries are of interest. A scope: the DN level, one level down, or the whole sub-tree. Modify RDN changes the RDN, hence the DN of a node. Bind and unbind begin and end a session, with or without authenticating (clear-text DN and password). Abandon cancels an operation in progress.

LDAP Version 3 Currently deployed LDAP is version 2. Internet Engineering Task Force (IETF) is working on LDAP version 3: Free LDAP completely from X.500 hangover. URL and LDAP referrals Enable access to LDAP server schema not just contents. UTF-8 multiple byte character sets for internationalization. (ASCII same in UTF-8). Password protection, digital certificates, SSL access.

Interconnectivity X.500 directory servers provide self-resolving referral (chaining), meaning that a request would be resolved if possible even if other servers had to be contacted. As a front end to X.500 LDAP was able to do this, but as it evolved into a standalone service this was abandoned. Currently existing gateways: LDAP to X.500 and X.500 to LDAP HTTP to LDAP whois to LDAP finger to LDAP Email to LDAP Current ways of accessing LDAP Text searches, manual specification. Ugly! Eudora, Communicator: Specify name, looks for email/phone. User never sees DN.

Evolving "web" Structure Goal: A universal directory, more structure than anarchical web. Asking Stanford's LDAP server for the parent level gives 122 institutions. Can only refer you to other known LDAP servers. Evolving system of distributing indexes of a server's content to other servers to support referrals. URL syntax for LDAP requests: ldap://ldap.netscape.com ldap://ldap.netscape.com/ou=Sales, o=Netscape, c=US?postalAddress?one Netscape supporting DX (like MX for email?) records in DNS system for referrals: LDAP client asks for email address of FAA employee (o=FAA). LDAP server doesn't know, responds with DX://faa.gov Client asks DNS for DX records at faa.gov DNS returns ldap://ldap.faa.gov Netscape wants web search-engines to crawl LDAP as well.

What would an LDAP browser look like? Do we want to browse the structures inherent in LDAP hierarchies? Visual representation of a tree: Vertical w/root at top middle or bottom middle. Hyperbolic or circular tree with root in middle. Click on entry to see attributes or attributes shown at bottom of screen. Form: fill in known values to specify query? What happens when LDAP directories start containing non-textual information?