It is important to shed some light on the basics of LDAP like What is LDAP? Why do we use LDAP? What are the terminologies used with LDAP? Here this article is a LDAP tutorial for beginners so that they can understand LDAP in brief before they can actually start working on this area.
Lightweight Directory Access Protocol (LDAP) is actually a set of open protocols used to access and modify centrally stored information over a network. LDAP is based on the X.500 standard (X.500 is an International Organization for Standardization [ISO] standard that defines an overall model for distributed directory services) but is a more lightweight version of the original standard. RFC 2251 explains the relationship like so: “LDAP is designed to provide access to directories supporting the X.500 models, while not incurring the resource requirements of the X.500 directory access protocol. Like traditional databases, an LDAP database can be queried for the information it stores.”
LDAP Basics
The term LDAP stands for Lightweight Directory Access Protocol. As the name indicates, LDAP was originally designed to be a network protocol that provided an alternative form of access to existing directory servers, but as the idea of LDAP—and the technologies surrounding it—matured, the term LDAP became synonymous with a specific type of directory architecture. We use the term LDAP when referring to directory services that comply with that architecture, as defined in the LDAP specifications.
Here are some popular LDAP implementations:
- OpenLDAP, an open source LDAP suite
- Microsoft Active Directory
- 389 Directory Server
- IBM Security Directory Server
- NetIQ eDirectory
How LDAP Works
As with most network services, LDAP adheres to the usual client/server paradigm. A typical interaction between the client and the server goes like this:
- An LDAP client application connects to an LDAP server. This process is also referred to as “Binding to a server”.
- The process of binding qualifies the client using a valid user ID and password. If the user ID and password are omitted, the server assumes the client wishes a connection as an “anonymous user,” a user with the lowest access rights (if any).
- Assuming the server accepts, the client has the choice of querying the directory server, browsing the information stored on the server, or attempting to modify /update the information on the LDAP server.
- Again, based on access restrictions, the server can allow or deny any of the operations attempted by the client. In the event that the server cannot answer a request, it may forward or refer the client to another upstream LDAP server that may have a more authoritative response to the request.
One client can send multiple requests to an LDAP server, but there is no guarantee that the server will answer the requests in the order they are posted.
In contrast to TCP, LDAP is a message-oriented protocol. What does this mean? In a conversation on your network, you always have one sending computer and one receiving computer. For a message-oriented protocol, such as LDAP, the logical unit transferred is a message, i.e., as soon as a complete message arrives, the “receive” operation is finished. TCP instead is a stream-oriented protocol, which means that the “receive” operation stops only when a specified number of bytes have arrived. One consequence of this behavior is that LDAP does not need a type of “\r\n” delimiter to specify the end of a request.
Understanding LDAP Architecture
LDAP can be better understood by considering the four models upon which it is based:
- Information: Describes the structure of information stored in an LDAP directory
- Naming: Describes how information in an LDAP directory is organized and identified
- Functional: Describes what operations can be performed on the information stored in an LDAP directory
- Security: Describes how the information in an LDAP directory can be protected from unauthorized access
The informational model
The basic unit of information stored in the directory is called an entry. Entries represent objects of interest in the real world such as people, servers, organizations, and so on. Entries are composed of a collection of attributes that contain information about the object. Every attribute has a type and one or more values. The type of the attribute is associated with a syntax. The syntax specifies what kind of values can be stored. For example, an entry might have a attribute. The syntax associated with this type of attribute would specify that the values are telephone numbers represented as printable strings optionally followed by keywords describing paper size and resolution characteristics. It is possible that the directory entry for an organization would contain multiple values in this attribute—that is, that an organization or person represented by the entity would have multiple fax numbers. The relationship between a directory entry and its attributes and their values is shown in below image:
The Naming model
The LDAP naming model defines how entries are identified and organized. Entries are organized in a tree-like structure called the Directory Information Tree (DIT). Entries are arranged within the DIT based on their distinguished name (DN). A DN is a unique name that unambiguously identifies a single entry. DNs are made up of a sequence of relative distinguished names (RDNs).
Each RDN in a DN corresponds to a branch in the DIT leading from the root of the DIT to the directory entry. Each RDN is derived from the attributes of the directory entry. In the simple and common case, an RDN has the form <attribute name> = <value>. A DN is composed of a sequence of RDNs separated by commas.
The example is very simple, but can be used to illustrate some basic concepts. Each box represents a directory entry. The root directory entry is conceptual, but does not actually exist.
The Functional model
The LDAP functional model is comprised of three categories of operations that can be performed against a LDAPv3 directory service:
- Authentication: Bind, Unbind, and Abandon operations used to connect and disconnect to and from an LDAP server, establish access rights and protect information.
- Query: Search for and Compare entries for entries meeting user-specified criteria.
- Update: Add an entry, Delete an entry, Modify an entry, and modify the distinguished name (ModifyRDN) or relative distinguished name of an entry.
The Security model
The security model is based on the bind operation. There are several different bind operations possible, and thus the security mechanism applied is different as well. One possibility is when a client requesting access supplies a DN identifying itself along with a simple clear-text password. If no DN and password is declared, an anonymous session is assumed by the LDAP server. The use of clear text passwords is strongly discouraged when the underlying transport service cannot guarantee confidentiality and may therefore result in disclosure of the password to unauthorized parties.
LDAP V3 comes along with a bind command supporting the Simple Authentication and Security Layer (SASL) mechanism. This is a general authentication framework, where several different authentication methods are available for authenticating the client to the server; one of them is Kerberos.
Directory security
Security is of great importance in the networked world of computers, and this is true for LDAP as well. When sending data over insecure networks, internally or externally, sensitive information may need to be protected during transportation. There is also a need to know who is requesting the information and who is sending it. This is especially important when it comes to the update operations on a directory. The term security, generally covers the following four aspects:
- Authentication: Assurance that the opposite party (machine or person) really is who he/she/it claims to be.
- Integrity: Assurance that the information that arrives is really the same as what was sent.
- Confidentiality: Protection of information disclosure by means of data encryption to those who are not intended to receive it.
- Authorization: Assurance that a party is really allowed to do what he/she/it is requesting to do. This is basically achieved by assigning access controls, like read, write, or delete, to user IDs or common names.
The following sections focus on the first three aspects (since authorization is not yet contained in the LDAP Version 3 standard): Authentication, integrity and confidentiality. There are several methods that can be used for this purpose; the most important ones are discussed here. These are:
- No authentication.
- Basic authentication.
- Simple Authentication and Security Layer (SASL).
Let's Explore Example LDAP Entry
An LDAP entry, or record, is the directory unit that stores information about an individual item in the directory.
Attribute
An entry is composed of a DN and one or more attributes. The DN serves as a unique identifier within an LDAP directory information tree. Attributes provide information about that entry. Let's transform a sample telephone directory entry into an LDAP record:
dn: o=Acme Services, l=Chicago, st=Illinois, c=US
o: Acme Services
postalAddress: 123 West First Street
l: Chicago
st: Illinois
postalCode: 60616-1234
c: US
telephoneNumber: +1 773 555 8943
telephoneNumber: +1 800 555 9834
objectclass: organization
The first line is the DN. All other lines in this record represent attributes.
An attribute describes a specific type of information. There are eight attributes here in our example, representing the following:
- Organization Name (
o
) - Mailing address (
postalAddress
) - Locality (
l
), which may be the name of a city, town, village, and so forth - State or Province (
st
) - Postal Code or ZIP Code (
postalCode
) - Country (
c
) - Telephone Number (
telephoneNumber
) - Object Class (
objectclass
), which specifies what type (or types) of record this entry is
An attribute may have one or more attribute names, where these names are synonyms. For example c
and countryName
are both names for the attribute type that identify a country. Both identify the same information, and LDAP will treat the two names as describing the same type of information.
Attribute names are not case sensitive. The attribute name o
is treated as synonymous with the name O
. Likewise, GivenName
, givenname
, and givenName
are all evaluated as the same attribute name.
Object Class Attribute
The last attribute in the given record is the objectclass
attribute. This is a special attribute that provides information about what type of record (or entry) this is.
An object class determines what attributes may be given to a record. The object class, organization
, indicates that this record describes an organization. According to this object class's definition, an organization
record can contain a locality (l
), and a postal code (postalCode
), and all of the other attributes present in the record.
Given the object class attribute, which is required for any entry, the directory can determine what attributes must, can, and cannot be present in the entry. As with other attributes, the objectclass
attribute may have multiple values, though which values may be given are subject to the object class definition and schema definition
The Directory Information Tree
So far, we have been comparing an LDAP directory to an address book or a telephone directory. But now I am going to introduce one of the primary differences between the structure of the data in an LDAP directory server, and that of many other forms of directories.
The information in a telephone directory is typically stored in one long alphabetical list. But in an LDAP directory the organizational structure is more sophisticated.
Information in an LDAP directory is organized into one or more hierarchies where, at the top of the hierarchy, there is a base entry, and other entries are organized in tree-like structures beneath the base entry. Each node on the hierarchy is an entry, with a DN and more than one attributes.
This hierarchically organized collection of entries is called a directory information tree, sometimes referred to simply as a directory tree or DIT.
To understand this method of organizing information, consider the organizational chart of a company.
LDAP directories store data in hierarchical relationships, too. At the top of the directory information tree is the root entry. Beneath that is a subordinate entry, which, in turn, may have its own subordinate entries. Each of these records has its own DN, and its own attributes.
Note that the DN of each entry contains information about its superior entry (the record above it). In fact, a DN is composed of two parts: the first part is the relative DN (RDN), and contains one or more attributes from the entry. The second part is the full DN of the superior entry.
Uses of LDAP
Let me give you some of the uses of LDAP in our article on LDAP tutorial for beginners. LDAP is a distributed directory service and can be used as storage for various types of information. Just about any kind of information can be stored in an LDAP directory—information as varied in nature as plain textual information, images, binary data, or public key certificates and so on.
Over the years, various LDAP schemas have been created to allow the storage of different data sources in an LDAP directory. Here are some example uses for LDAP:
- LDAP can serve as a complete identity management solution for an organization. It can provide authentication and authorization services for users. In fact, the services provided by the Network Information Service (NIS) can be completely replaced by LDAP.
- The information stored in DNS records can be stored in LDAP.
- LDAP can be used to provide “yellow pages” services for an organization (for instance, users’ or employees’ contact information—phone numbers, addresses, departments, and so on).
- Mail routing information can be stored in LDAP.
- A Samba schema exists that allows a Samba server to store extensive object attributes in LDAP. This allows Samba to function as a robust drop-in replacement for Microsoft Windows domain controllers in environments where redundancy and replication are needed.
What is OpenLDAP
By default, Linux systems keep a local registry of all their users. That registry is the /etc/passwd
file. In this file, we can see a line for every registered user. So, in order to access a computer, we must have a user defined in that computer. This is OK when we have only a few computers, but if we have tens or hundreds of computers, it could be a nightmare to create new users or change a password in all of them.
The solution is to centralize user account management , that is, to have a common database in which to keep all information related to user accounts. There are many ways to accomplish this, but probably the most used today is the Lightweight Directory Access Protocol (LDAP) in one of its many variants.
LDAP keeps a central database in which users, computers, and, generally speaking, all network objects are registered. There are many implementations of the protocol, for example, Active Directory from Microsoft or eDirectory from Novell. Here we’ll use OpenLDAP, a free implementation of the protocol.
OpenLDAP is the open source implementation of LDAP that runs on Linux/UNIX systems. OpenLDAP is a suite of programs, made up of slapd, slurpd, various utilities, and libraries, that implements the LDAP protocol along with various client- and server-side utilities.
Server-Side Daemons
The server side consists of two main daemons:
- slapd: This is a stand-alone LDAP daemon that listens for LDAP connections from clients and responds to the LDAP operations it receives over those connections.
- slurpd: This is a stand-alone LDAP replication daemon that is used to propagate changes from one slapd database to another. This daemon is used for synchronizing changes from one LDAP server to another. It is needed only when more than one LDAP server is in use.
Lastly I hope this article on LDAP Tutorials for Beginners and understanding OpenLDAP on Linux was helpful. So, let me know your suggestions and feedback using the comment section. For more information you can refer OpenLDAP Documentation
great!
Thank you, really helpful!