1/20/2014 Chapter 2 LDAP Concepts & Overview http://www.zytrax.com/books/ldap/ch2/ 1/14 2. LDAP Concepts & Overview If you already understand what LDAP is, what it is good for, Schemas, objectClasses, Attributes, matchingRules, Operational objects and all that jazz - skip this section. But if you are going to do anything except blindly follow HOWTOs you must understand most of this stuff. LDAP and X.500 are feet deep in terminology. Some terminology is important, some is just fluff. We have created a glossary to jog your memory. We introduce terms either because they are important or because they are frequently used in the literature. 2.1 A Brief History of LDAP 2.2 LDAP Overview 2.3 LDAP vs. RDBMS 2.3.1 LDAP Usage Summary 2.4 LDAP Data (Object) Model 2.4.1 Object Tree Structure 2.4.2 Attributes 2.4.3 Object Classes 2.4.4 Describing the Tree and Adding Data 2.4.5 Navigating the Tree 2.5 LDAP Replication and Referrals 2.5.1 Referrals 2.5.2 Replication A brief Note about case sensitivity in LDAP: It's confusing - well, we found it confusing. Truth be told we find a lot of things confusing. The only case sensitive things in LDAP are passwords and the contents of certain (very obscure) attributes based on their matchingRule. Period. You will see both in this and other documentation: objectclasses or objectClasses and even ObjectClasses. They all work. Period. And you have enough to worry about in the first six years of learning LDAP (just kidding, it will only take four years) to get in a sweat every time you approach a keyboard in case you mistype the name of something. 2.1 A Brief History of LDAP Once upon a time, in the dim and distant past (the late 70's - early 80's) the IT U (International Telecommunication Union) started work on the X.400 series of email standards. This email standard required a directory of names (and other information) that could be accessed across networks in a hierarchical fashion not dissimilar to DNS for those familiar with its architecture. This need for a global network based directory led the ITU to develop the X.500 series of standards and specifically X.519, which defined DAP (Directory Access Protocol), the protocol for accessing a networked directory service. The X.400 and X.500 series of standards came bundled with the whole OSI stack and were big, fat and consumed serious resources. Standard ITU stuff in fact. Fast forward to the early 90's and the IETF saw the need for access to global directory services (originally for many of the same email based reasons as the ITU) but without picking up all the gruesome protocol (OSI) overheads and started work on a Lightweight Directory Access Protocol (LDAP). LDAP was designed to provide almost as much functionality as the original X.519 standard but using the TCP/IP protocol - while still allowing inter-working with X.500 based directories. Indeed, X.500 (DAP) inter-working and mapping is still part of the IETF LDAP series of RFCs. A number of the more serious angst issues in the LDAP specs, most notably the directory root naming convention, can be traced back to X.500 inter-working and the need for
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
1/20/2014 Chapter 2 LDAP Concepts & Overview
http://www.zytrax.com/books/ldap/ch2/ 1/14
2. LDAP Concepts & Overview
If you already understand what LDAP is, what it is good for, Schemas, objectClasses,
Attributes, matchingRules, Operational objects and all that jazz - skip this section. But if
you are going to do anything except blindly follow HOWTOs you must understand most of
this stuff.
LDAP and X.500 are feet deep in terminology. Some terminology is important, some is just
fluff. We have created a glossary to jog your memory. We introduce terms either because
they are important or because they are frequently used in the literature.
2.1 A Brief History of LDAP
2.2 LDAP Overview
2.3 LDAP vs. RDBMS
2.3.1 LDAP Usage Summary
2.4 LDAP Data (Object) Model
2.4.1 Object Tree Structure
2.4.2 Attributes
2.4.3 Object Classes
2.4.4 Describing the Tree and Adding Data
2.4.5 Navigating the Tree
2.5 LDAP Replication and Referrals
2.5.1 Referrals
2.5.2 Replication
A brief Note about case sensitivity in LDAP: It's confusing - well, we found it
confusing. Truth be told we find a lot of things confusing. The only case sensitive things
in LDAP are passwords and the contents of certain (very obscure) attributes based on
their matchingRule. Period. You will see both in this and other documentation:
objectclasses or objectClasses and even ObjectClasses. They all work. Period. And you
have enough to worry about in the first six years of learning LDAP (just kidding, it will only
take four years) to get in a sweat every time you approach a keyboard in case you
mistype the name of something.
2.1 A Brief History of LDAP
Once upon a time, in the dim and distant past (the late 70's - early 80's) the ITU
(International Telecommunication Union) started work on the X.400 series of email
standards. This email standard required a directory of names (and other information) that
could be accessed across networks in a hierarchical fashion not dissimilar to DNS for
those familiar with its architecture.
This need for a global network based directory led the ITU to develop the X.500 series of
standards and specifically X.519, which defined DAP (Directory Access Protocol), the
protocol for accessing a networked directory service.
The X.400 and X.500 series of standards came bundled with the whole OSI stack and
were big, fat and consumed serious resources. Standard ITU stuff in fact.
Fast forward to the early 90's and the IETF saw the need for access to global directory
services (originally for many of the same email based reasons as the ITU) but without
picking up all the gruesome protocol (OSI) overheads and started work on a Lightweight
Directory Access Protocol (LDAP). LDAP was designed to provide almost as much
functionality as the original X.519 standard but using the TCP/IP protocol - while still
allowing inter-working with X.500 based directories. Indeed, X.500 (DAP) inter-working
and mapping is still part of the IETF LDAP series of RFCs.
A number of the more serious angst issues in the LDAP specs, most notably the directory
root naming convention, can be traced back to X.500 inter-working and the need for
2. The objectclass may be part of a hierarchy in which case it inherits all the
characteristics of its parent objectclasses.
There is an incomplete list of the most common objectClasses and their attributes
here.
More on objectClasses - only if you are comfortable otherwise continue here.
2.4.4 Describing the Tree and Adding Data
Eventually we want to slap some data into our directory and actually use the stupid
thing.
Describing the tree structure and initial population of data is performed by adding entries
(with their associated objectClasses and attributes) starting from the root of the DIT and
progressing down the hierarchy. Thus, a parent entry must always have been added
before attempting to add any child entries. Adding entries may be done in a variety of
ways, one of which is using LDAP Data Interchange Files (LDIF) which are fully
described in a later chapter. LDIFs are textual files that describe the tree hierarchy - the
Directory Information Tree (DIT) - and the data to be added to each attribute. The
following is a simple example of an LDIF file which sets up a root DN
(dc=example,dc=com) and adds a single child entry under a people entry.
Notes:
1. It is not important to understand what all the values in this LDIF file do at this
stage. Chapter 5 (samples) covers the details of setting up LDIF files and Chapter 8
explains LDIF files in painful detail. It is enough, at this stage, to know that LDIF
files can be used to set up the DIT and that LDIF files look like the one below.
2. Adding LDAP entries may also be done using an LDAP client such as a general
purpose LDAP Browser (see also LDAPBrowser/Editor) or a specialized application.
version: 1
## version not strictly necessary (and some implementations reject it) but generally good practice
## DEFINE DIT ROOT/BASE/SUFFIX ###### uses RFC 2377 (domain name) format
## dcObject is an AUXILIARY objectclass and MUST## have a STRUCTURAL objectclass (organization in this case)# this is an ENTRY sequence and is preceded by a BLANK line
dn: dc=example,dc=comdc: exampledescription: The best company in the whole worldobjectClass: dcObjectobjectClass: organizationo: Example, Inc.
## FIRST Level hierarchy - people # this is an ENTRY sequence and is preceded by a BLANK line
dn: ou=people, dc=example,dc=comou: peopledescription: All people in organisationobjectClass: organizationalUnit
## SECOND Level hierarchy - people entries # this is an ENTRY sequence and is preceded by a BLANK line