 |
SelfADSI - The LDAP / ADSI Scripting Tutorial |
   |
Regarding ADSI, the LDAP protocol is very important as ADSI actually is an interface for the use of LDAP with self developed scripts and applications. This section of the SelfADSI Tutorial describes the Lightweight Directory
Access Protocol (LDAP).
The following topics are available:
LDAP History and Standards
Originally, LDAP was established in conjunction with the OSI Recommendation X.500
for directory services. Most directory services today refer somehow to X.500. The equivalent for X.500 in the world of ISO specifications is called ISO/IEC standard 9594. However, all relevant documents are not available online for free, but can be purchased e.g. at ITU Online Bookshop or at ISO Online Store.
The X.500 standard was defined in its original form between 1984 and 1988 - the Data Model, the Informational Model, the Functional Model, the Namespace Model as well as an Authentication Framework for directory services are described here. In the course of this, an accessing protocol for directory services was specified too: the Directory Access Protocol (DAP). DAP is a quite complex application protocol which fulfills all the requirements of the OSI Model and is, furthermore, based only upon the relevant OSI transport protocols - and not upon TCP/IP.
One of the most important books concerning X.500 is available online: Understanding X.500 - The Directory by David Chadwick.
Due to the immense complexity of X.500 and DAP, the University of Michigan
designed the Lightweight Directory Protocol in 1993 - despite the name, it offers all operations necessary for accessing a directory service. Moreover, it is based upon TCP/IP - this fact was virtually more important for the success of LDAP than its clear protocol structure. In the beginning, LDAP was a mere Front End for
X.500 server but has become mainstream as an independant directory system since 1995. LDAP directory servers do not neccessarly need to be X.500 servers but utilize all the hierarchies and naming described in the X.500 specification.
In 1995, the LDAP version 2 was adopted in RFC
1777 by the IETF working group ( 'Access
Searching and Indexing of Directories ASID').
The current LDAP version 3 was finally set up in RFC
2251 in 1997. In this process, most notably an upgrade of the authentification via LDAP was added (in version
2 there were only anonymous or unencrypted logons). In addition, by establishing UTF-8 and
Unicode, the formatting of the data within a directory was modernised.
RFC Standards
Concerning LDAP, there are lots of RCF documents that play an important role (outdated
standards are highlighted in black, main standards are bold):
 |
RFC 1484: Using the OSI Directory to achieve User Friendly Naming |
|
RFC 1485: A String Representation of Distinguished Names |
|
RFC 1487: X.500 Lightweight Directory Access Protocol |
|
RFC 1488: The X.500 String Representation of Standard Attribute Syntaxes |
|
RFC 1588: A String Representation of LDAP Search Filters |
|
RFC 1777: Lightweight Directory Access Protocol (replaces 1487) [LDAP v2] |
|
RFC 1778: The String Representation of Standard Attribute Syntaxes (replaces 1488) [für LDAP v2] |
|
RFC 1779: A String Representation of Distinguished Names (replaces 1485) |
|
RFC 1781: Using the OSI Directory to Achieve User Friendly Naming (replaces 1484) |
|
RFC 1798: Connection-less Lightweight X.500 Directory Access Protocol |
|
RFC 1823: The LDAP Application Program Interface |
|
RFC 1959: An LDAP URL Format |
|
RFC 1960: A String Representation of LDAP Search Filters (replaces RFC 1588) |
|
RFC 2251: Lightweight Directory Access Protocol (v3) |
|
RFC 2252: Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions |
|
RFC 2253: Lightweight Directory Access Protocol (v3): UTF-8 String Representation of Distinguished Names (replaces RFC 1779) |
|
RFC 2254: The String Representation of LDAP Search Filters (replaces RFC 1960) |
|
RFC 2255: The LDAP URL Format |
|
RFC 2256: A Summary of the X.500(96) User Schema for use with LDAPv3 |
|
RFC 2307: An Approach for Using LDAP as a Network Information Service |
|
RFC 2559: Internet X.509 Public Key Infrastructure Operational Protocols - LDAPv2 |
|
RFC 2696: LDAP Control Extension for Simple Paged Results Manipulation |
|
RFC 2820: Access Control Requirements for LDAP |
|
RFC 2829: Authentication Methods for LDAP |
|
RFC 2830: Lightweight Directory Access Protocol (v3): Extension for Transport Layer Security |
|
RFC 3377: Lightweight Directory Access Protocol (v3): Technical Specification (specifies the valid LDAP-RFCs) |
|
RFC 3352: Connection-less Lightweight Directory Access Protocol (CLDAP) to Historic Status (replaces RFC 1798) |
|
RFC 3494: Lightweight Directory Access Protocol version 2 (LDAPv2) to Historic Status (describes the outdated LDAPv2 RFCs) |
|
RFC 3698: Lightweight Directory Access Protocol (LDAP): Additional Matching Rules |
|
RFC 3771: The Lightweight Directory Access Protocol (LDAP) Intermediate Response Message (extends RFC 2251) |
|
RFC 4370 : Lightweight Directory Access Protocol (LDAP) Proxied Authorization Control |
|
RFC 4373 : Lightweight Directory Access Protocol (LDAP) Bulk Update/Replication Protocol (LBURP) |
|
RFC 4517 : Lightweight Directory Access Protocol (LDAP): Syntaxes and Matching Rules (replaces RFC 2252, 2256) |
The Communication Model
Within an LDAP communication, a client establishes a TCP connection to a directory server. According to X.500 habits, the server is also called DSA (Directory
Service Agent). Meanwhile, there are implementations of a connectionless LDAP protocol available where queries are sent directly via UDP.
In doing so, TCP/UDP Port 389
is normally used, whereas Port 636 comes into operation if connecting via SSL/TLS (Secure Socket
Layer/Transport Level Security).
The server can refer a client to another server.
This referral was established in LDAP version
3 and allows load balancing in larger directory systems being provided by different server.
Servers are able to synchronize their directories among each other. However, there are no specific LDAP requests designed for this task - but the servers can use the standard
LDAP protocol commands or synchronize their databases by the use of other mechanisms.
During the communication, the client transmits one or more requests to the server which gives the equivalent response.
This communication need not to be strictly synchronous,
i.e. the client can send several requests before the server
responds the first one and it also hasn't to consider the order of the incoming requests for its responds. A single client's request can also be responded with several messages from the server.
The Structure of LDAP Packets
An LDAP request is structured as follows:
The content of an LDAP message is encoded like in the LDAP RFCs in ASN.1
(Abstract Syntax Notation) (shown in a shortened notation here). The actual, precice data representation
within the network packets is implemented with BER
(Basic Encoding Rules). This might be a bit confusing at the beginning, however, the most important parts of the data (e.g. object and attribute names) are shown in ASCII
so that they can be identified directly in the hex code of a packet sniffer.
The detailed technical structure can be gathered from the standard specification
in RFC
2251. The individual commands are further explained
later in this SelfADSI section. Anyhow, I'd like to check out one example for a detailed analysis of an LDAP message on the basis of an
LDAP search. Please have a look onto the packet record of an LDAP session.
The decoding states that the examined packet would be an LDAP search for user objects in the entire naming context "dc=karakorum,dc=net". Returned shall be the attribute displayName.
Let's focus on the hexadecimal section of the LDAP message one more time
(highlighted dark above) - and together with the ASN.1 definition of an LDAP search operation. In order to understand the exact codification, you will neccessarily need to know about the specifications of Basic
Encoding Rules (BER). Move your mouse
over the values for further explanations:
LDAP Commands
From a technical point of view, the different
LDAP commands could rather be regarded as protocol operations.
One of these operations was studied in detail in the last paragraph. An in-depth examination of all LDAP command aspects
can be found in
RFC
2251.
| [0] | Bind Request : |
Logon of a client to an
LDAP server. Different procedures for SASL authentication
(Simple Authentication and Security Layer) are supported.
Even a clear text authentication ist possible - or an anonymous bind operation, where no logon data is passed. How an
ADSI scripting implements a bind operation can be read in the section 'Connecting with the directory and objects' here in the SelfADSI tutorial.
|
| [1] | Bind Response: |
LDAP server reply to a BindRequest.
|
| [2] | UnBind Request: |
By using this command, the client ends the LDAP protocol session which will NOT be responded by the server, but all requests still due become disallowed at once and the connection is ended. ADSI scripts don't need to process this operation explicitly - after completing a script the LDAP connection is automatically discarded by a time-out of the server.
|
| [3] | Search Request: |
This command searches for one or more objects within the directory where
several attributes are given back which the client can pass in the search request.
|
| [4] | Search ResultEntry: |
With this protocol operation the server gives back a matching entry for a SearchRequest. There can be several of those packages in one response frame in case that more than one object of a single search shall be given back as a match. However, the return of the matches can occur via several independent network frames.
|
| [5] | Search ResultDone: |
For completing a SearchRequest, the LDAP server returns a SearchResultDone. This reply is given back immediately if a search was unsuccessful or inaccurate.
|
| [6] | Modify Request: |
This command allows access to attributes of an object.
The use of ADD, REPLACE and DELETE operations are possible, however these possibilities do not refer to the entire object but only to the attributes inside the object.
|
| [7] | Modify Response: |
LDAP server reply to a ModifyRequest.
|
| [8] | Add Request: |
A directory object can be created with this call. In ADSI scripts
an AddRequest is used if the Create() method called in container objects.
|
| [9] | Add Response: |
LDAP server reply to an AddRequest.
|
| [10] | Del Request: |
A directory object can be deleted here. An AddRequest is used in ADSI by calling the function Delete() for container objects.
|
| [11] | Del Response: |
LDAP server reply to a DelRequest.
|
| [12] | ModifyDN Request: |
This command can rename an object - the
Relative Distinguished Name of the object then is changed in the directory. The remaining pathname of the object can be changed, too: through this, the object is moved to another container.
|
| [13] | ModifyDN Response: |
LDAP server reply to a ModifyDNRequest.
|
| [14] | Compare Request: |
At the server, clients can check if attributes of objects possess certain values. This LDAP operation isn't used directly in ADSI.
|
| [15] | Compare Response: |
LDAP server reply to a CompareRequest.
|
| [16] | Abandon Request: |
With this command a running LDAP request can be stopped by the client. This is mainly important for complex and extensive search requests possibly drawing high server performance but whose results are no longer needed by the client.
|
| [19] | SearchResult Reference: |
A special reply of an LDAP server to a client's request. The results are not given back by the server directly but the server refers to other LDAP servers containing relevant directory objects or sections and at which the client can carry on the search.
|
| [23] | Extended Request: |
This kind of request was specified in the LDAP standard for providing diverse implemetations with the possibility to add some more operations, e.g. signed LDAP requests. The several sub types of the ExtendedRequests are defined by so-called OBJECT IDENTIFIER OIDs. These definitions are subject to one's sole discretion.
|
| [24] | Extended Response: |
LDAP server reply to an ExtendedRequest.
|
| [25] | Intermediate Response: |
This type of LDAP reply has been specified in RFC 3771 after the actual LDAPv3 definition. The server can give back 'provisional replies' to a client. Especially relevant for client's requests that have to be completed by the server in several steps, e.g. deleting whole sub structures in the directory or designing and synchronising new replicas onto other servers. |
The Data Model of the Directory
LDAP servers save objects' data in a hierarchical tree structure, the so-called Directory Information Tree (DIT). The notation 'Naming Context' is in use, too. The LDAP server itself is often called DSA (Directory Services Agent) aund can contain several DIT tree structures / naming contexts.
An LDAP hierarchy consists of objects containing 0 to n subordinate child objects. However, each child object possesses exactly one parent object, it can't be contained in several containers. An exception is the Root object at the top of the Naming Context hierarchy - it doesn't possess an superior object. Customary examples for normal container objects are Organizational Units (OUs).
-
Each object has a name that needs to be unique within its container - this is the Relativ Distinguished Name (RDN). If you concatenate now the RDNs of the object and all its superior parent container objects, then you get an unambigious identifier of the object within the LDAP hierarchy - this is the complete Distinguished Name (DN) of the object. An example:
-
You get detailed explanations concerning the design of LDAP pathnames in the equivalent section of the SelfADSI tutorial.
Object Classes and Attributes
Objects within an LDAP hierarchy are divided into classes. Each class is defined by a name and a certain amount of attributes. Some of the attributes are mandatory in all objects of a specific class ('MUST' attributes). Other attributes are optional - they either can be written with no value or can be missing in these objects at all ('MAY' attributes).
-
The definition of the classes and their attributes is stored in the service directory system itself. Again, the classes are organised in a hierarchical manner: classes can orginate from other classes - objects then inherit all the attributes of their hierachical superior classes, additional to the properties of their own class (the so-called structural object class). The directory service system often has an abstract object class namend 'top' all other classes orginate from.
-
The RootDSE Object
RootDSE is a set of information by which general attributes of an LDAP server can be retrieved. You could say that RootDSE is a specific server entry being available at the root of the directory tree (DIT - Directory Information Tree) without being part of the name context itself.
-
In a technical sense, RootDSE is an object that can be retrieved directly from a server without further specification of an LDAP path:
rootDSE = GetObject("LDAP://server/rootDSE")
Via an LDAP query (e.g. ADO) the RootDSE object can be retrieved by using an empty base DN ("") and the following LDAP query filter: "(objectClass=*)".
This request should also be possible as anonymous LDAP user on every LDAP server if it supports LDAP v3. Correspondingly, RootDSE is specified as standard attribute of an LDAP server in RFC 2251 - Lightweight Directory Access Protocol (v3). All in all, seven main attributes are mentioned for the RootDSE object in the LDAP standard, that should at least be given back by an LDAP server:
- namingContexts
- subSchemaSubentry
- altServer
- supportedExtensions
- supportedControl
- supportedSASLMechanisms
- supportedLDAPVersion
Moreover, the different LDAP servers give back some additional attributes. Please inform yourself in the links of the accordant provider websites:
Free and Commercial LDAP Software
Since LDAP has become common standard
for directory systems and accesses, the range of software for LDAP clients and LDAP servers has increased.
The following types of servers can be differentiated:
- Pure
LDAP directory servers (e.g. OpenLDAP, Sun iPlanet, Siemens
DirX)
- X.500
servers, offering an LDAP interface (e.g. Isode M-Vault
X.500)
- Diverse
application servers, providing an LDAP interface (e.g.
Microsoft ADS, Novell eDirectory, IBM Lotus Domino)
- Database server,
providing an LDAP interface (e.g. Oracle Internet Directory)
