Before going into the LDAP, we have to look into what are Directory Services and X500 Model.
Directory Service
- Directory Service can be characterized as a hierarchical tree-based naming system that offers numerous distributed system advantages:
- Unique names can be determined by concatenating hierarchical naming components starting at a root node (e.g., "com")
- Object-oriented schema and data model supports very fast search operations (uses Key-based querying).
- Due named sub-tree partitions, the features like Distribution, Replication and Delegated or Autonomous Administration are supported.
- Supports Authentication and Fine-Grained Access Control mechanisms.
- Few examples of directories are DNS, NOS, Novell's NDS, Microsoft's Active Directory.
- Directories are designed and optimized for more READ/ SEARCH operations, than WRITE/ UPDATE operations.
- In real world example, a telephone directory is a directory system that contains a list of subscribers with an address and a phone number in a dictionary format, than in a tree-based fashion.
![]() |
Telephone Directory |
X500 Model
- X.500 is a series of computer networking naming standards and models for Directory Service.
- The primary concept of X.500 is that there is a single Directory Information Tree (DIT), a hierarchical organization of Entries and these can be called using:
- Distinguished Name (DN) is a unique Distinguished Name. Much like a "path" to a filename in a file system.
- For eg: cn=alice, ou=People, dc=example.com
- Relative Distinguished Name (RDN) is a component of the distinguished name. Much like a "filename" in a file system.
- For eg: cn=alice, ou=People is a RDN relative to the root RDN dc=example.com
![]() |
Directory Information Tree (DIT) |
- DNs are also called as naming contexts, because it describes the namespace where the entry lives.
- X500 Model suggest the way how directory service can be designed in a DIT to have a database to fetch information for a given entry.
- Directory Access Protocol (DAP) is one of the protocol defined in X.500 that says how to access the entries in the DIT on TCP/IP stack.
LDAP
- The Lightweight Directory Access Protocol (LDAP) is an open, vendor-neutral, industry standard Application Layer protocol interface for accessing and maintaining distributed directory information services over an Internet Protocol (IP) network.
- The latest specification is Version 3, published as RFC 4511.
- LDAP is based on:
- A simpler subset of standards within X.500 model, hence sometimes LDAP is called as X.500-lite.
- DAP to access X500 model directory, hence it is called as Lightweight DAP.
Naming Model
Schema Model
- An Attribute defines as a piece of information that the directory entries contain.
- Attribute is similar to DB column name.
- The most widely used naming attributes are defined in the following table:
Attr.
|
Abbreviations
|
Explanations
|
Examples
|
dc
|
domainComponent
|
An element of a DNS
domain name
|
dc=acme,dc=com
|
uid
|
userid
|
A person's account
name
|
uid=jdoe
|
cn
|
commonName
|
Full name of a
person, group, device, etc.
|
cn=John Doe
|
l
|
localityName
|
Name of a geographic
region
|
l=Bay Area
|
st
|
stateOrProvinceName
|
State or Province
|
st=CA
|
o
|
organizationName
|
Organization name
|
o=Acme
|
ou
|
organizationalUnitName
|
Organization unit
name
|
ou=Sales
|
c
|
countryName
|
Two letter country
code
|
c=US
|
- An LDAP schema is a set of rules that define what can be stored as entries in a LDAP directory.
- We have similar concept in RDBMS, where DB schema contains information about database structure, tables, columns, data types and constraints.
- The schema model consists of two types of elements:
- Object Classes:
- Defines as a placeholder for attributes.
- Similar to DB tables.
- Object classes come in one of three kinds:
Abstract
|
Structural
|
Auxiliary
|
|
|
|
There are only two abstract classes:
|
For example:
Object classes such as: organization, person,
organizationalPerson
or device.
|
For example:
Object class strongAuthenticationUser
allows the
attribute userCertificate;binary
be present, but this class could be used in an entry with
object class person, device or
some other structural class.
|
![]() | ||
|
- Attribute Types:
- Defines the data types of attribute values.
- Similar to DB column's data types.
- Attribute Type Definition specifies:
Syntax
|
Matching
Rules
|
Defines the data format in
which an attribute value is stored.
|
A matching rule encapsulates a set
of logic that may be used to perform some kind of matching operation against
two LDAP values
|
For example:
Directory String, Integer, and
JPEG are examples of standard LDAP syntaxes.
|
For example:
Comparison, Sort and Order
|
Protocol Overview
- A client starts an LDAP session by connecting to an LDAP server, called a Directory System Agent (DSA), by default on TCP and UDP port 389, or on port 636 for LDAPS.
- The client may request the following LDAP operations:
Operations
|
Explanations
|
StartTLS
|
Use the LDAPv3-TLS connection
|
Bind
|
Authenticate and specify LDAP
protocol version
|
Search
|
Search for and/or retrieve
directory entries
|
Compare
|
Test if a named entry contains a
given attribute value
|
Add
|
Add a new entry
|
Delete
|
Delete an entry
|
Modify
|
Modify an entry
|
Modify Distinguished Name (DN)
|
Move or rename an entry
|
Abandon
|
Abort a previous request
|
Extended Operation
|
Generic operation used to define other
operations
|
Unbind
|
Close and exit the connection
|
LDIF
- LDAP Data Interchange Format (LDIF) is a standard text-based representation for LDAP data.
- LDIF conveys directory content as a set of records, one record for each entry.
- It also represents update requests, such as Add, Modify, Delete, and Rename, as a set of records, one record for each update request.
- This is an example of a simple directory entry with several attributes, represented as a record in LDIF:
dn: cn=John Doe,dc=example,dc=com
cn: John Doe
givenName: John
sn: Doe
telephoneNumber: +1 800 800 8888
telephoneNumber: +1 800 800 9999
mail: jdoe@example.com
manager: cn=Eliza Beth,dc=example,dc=com
objectClass: inetOrgPerson
objectClass: organizationalPerson
objectClass: person
objectClass: top
Other Useful Notes
Other Useful Notes
- In LDAP 3.0, there is a special root called rootDSE (where DSE stands for “DSA-specific entry”) is defined as the root of the DIT server.
- The purpose of the rootDSE is to provide data about the directory server itself.
- i.e., rootDSE is not part of any namespace, but it contains namingContexts, which provides a list of all DNs in the the DIT.
- Directory servers publish internal schema as an entry in the directory.
- It can be retrieved by LDAP clients performing a baseObject search on the a special entry that is defined by the directory server to publish schema information (e.g., cn=schema), with the attributes attributeTypes and objectClasses specified as part of the search criteria.
- Each LDAP directory has some default schema, which developers can customize, or "extend," by adding elements to it.
No comments:
Post a Comment