LDAP stands for Lightweight Directory Access Protocol and it is a software protocol for allowing anyone to locate data about organizations, individuals and other resources such as files and devices in a network — whether on the public internet or on a corporate intranet. LDAP is a “lightweight”  version of Directory Access Protocol (DAP), which is part of X.500, a standard for directory services in a network. A directory tells the user where in the network something is located. On TCP/IP networks (including the internet), the domain name system (DNS) is the directory system used to relate the domain name to a specific network address (a unique location on the network). However, the user may not know the domain name. LDAP allows a user to search for an individual without knowing where they’re located

LDAP offers itself enormously well to things like access control and authorization. Which groups is a user in? Only users in the detective group should have access to the signals application, so when someone attempts to log in, ensure they are in the proper group before granting access. But how does one gain access to all of those records? The process is straight forward from a flow outlook:

1. A session begins with a client binding to an LDAP server (DSA, Directory System Agent), default port 389
2. The client then sends an operation request (often a search or compare request, for example) to the server, asking for a particular set of information.
3. The server then processes this query, and supplies a response.
4. The client receives the response and unbinds, then processes the data.

Lightweight Directory Access Protocol (LDAP) is an internet protocol works on TCP/IP, used to access information from directories. LDAP protocol is basically used to access an active directory

Directories:
Directories are set of object with similar attributes, organised in a logical and hierarchical manner. For example, Telephonic Directories. It is a distributed database application used to manage attributes in a directory.

LDAP defines operations for accessing and modifying directory entries such as:

• Searching for user specified criteria
• Adding an entry
• Deleting an entry
• Modifying an entry
• Modifying the distinguished name or relative distinguished name of an entry
• Comparing an entry

LDAP Models:
LDAP can be explained by using four models upon which it based:

1. Information Model:
   This model describes structure of information stored in an LDAP Directory.In this basic information is stored in directory is called an entity. Entries here represents object of interest in real world such as people, server, organization, etc. Entries contain collection of attributes that contain information about object.Every attribute has a type and one or more values. Here types of attribute is associated with syntax and syntax specifies what kind of values can be stored
2. Naming Model:
   This model describes how information in an LDAP Directory is organized and identified. In this entries are organized in a Tree-Like structure called Directory Information Tree (DIT). Entries are arranged within DIT based on their distinguished name DN. DN is a unique name that unambiguously identifies a single entry.
3. Functional Model:
   LDAP defines operations for accessing and modifying directory entries . In this we discuss about LDAP operations in a programming language independent manner LDAP operations can be divided into following categories:

   • Query
   • Update 
   • Authentication

4. Security Model:
   This model describes how information in LDAP directory can be protected from unauthorized access. It is based on BIND operation. There are several bind operation can be performed.

LDAP Client and Server Interaction:
It is quite similar to any other client-server interaction. In this client performs protocol functions against server.The interaction takes place as follows:-

1. A protocol request is send to server by client.
2. Server perform operations on directory such as search, update, delete, etc.
3. The response is sent back to the client.

Microsoft, Open LDAP, Sun, etc can easily be made an LDAP server. if the user don’t want to install directory service but want to use LDAP instruction for available LDAP server then user can use four11, bigfoot etc. Making an LDAP client is quite simple as there are SDK’s in many programming languages such as C, C++, Perl, Java, etc.

User has to perform certain task to be LDAP client:

(i) Go get SDK for your language
(ii) Use function of SDK to connect to LDAP 
(iii) Operate on LDAP

LDAP functions / operations:

• (a) For Authentication:
  It includes bind, unbind and abandon operations used to connect and disconnect to and from an LDAP server, establish access rights and protect information. In authentication, client session is established and ended using the functions

  -> BIND/UNBIND
  -> Abandon

• (b) For Query:
  It includes search and compare operations used to retrieve information from a directory. In query, server performs action using function

  -> Search
  -> Compare Entry

• (c) For Update:
  It includes add, delete, modify and modify RDN operations used to update stored information in a directory. In update, we can make changes in directories by using function

  -> Add an entry
  -> Delete an entry
  -> Modify an entry

• Client establishes session with server (BIND) using Hostname/IP/and Port Number. For security purposes, user set USER-ID and Password based authentication.
• Server perform operations such as read, update, search, etc.
• Client end session using UNBIND or Abandon function.

Advantages of LDAP:

• Data present in LDAP is available to many clients and libraries.
• LDAP support many types of application.
• LDAP is very general and has basic security.

LDAP Basics

LDAP is a protocol for accessing a specially tailored database that is used for a variety of things, such as directory service. This directory can be used to store all sorts of information. The directory can be regarded as a database of sorts. But unlike traditional databases, an LDAP database is especially suited for read, search, and browse operations instead of write operations. It is with reads that LDAP shines.

Here are some popular LDAP implementations:

• OpenLDAP, an open source LDAP suite
• Microsoft Active Directory
• 389 Directory Server
• IBM Security Directory Server
• NetIQ eDirectory

Client/Server Model

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:

1. An LDAP client application connects to an LDAP server. This process is also referred to as “binding to a server.”
2. Based on the access restrictions configured on the server, the LDAP server either accepts or refuses the bind/connection request.
3. 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.
4. 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.
6. 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.

The way that LDAP displays data to users is very dependent upon the interaction of and relationship between some defined structural components.

Attributes

The data itself in an LDAP system is mainly stored in elements called attributes. Attributes are basically key-value pairs. Unlike in some other systems, the keys have predefined names which are dictated by the objectClasses selected for entry (we’ll discuss this in a bit). Furthermore, the data in an attribute must match the type defined in the attribute’s initial definition.

Setting the value for an attribute is done with the attribute name and the attribute value separated by a colon and a space. An example of an attribute called mail, which defines an email address would look like this:

mail: admin@example.com

When referring to an attribute and its data (when not setting it), the two sides are instead joined by an equals sign:

mail=example.com

The attribute values contain most of the actual data you want to store and access in an LDAP system. The other elements within LDAP are used for structure, organization, etc.

Entries

Attributes by themselves are not very useful. To have meaning, they must be associated with something. Within LDAP, you use attributes within an entry. An entry is basically a collection of attributes under a name used to describe something.

For instance, you can have an entry for a user in your system or for each item in an inventory. This is roughly analogous to a row in a relational database system or to a single page within an address book (the attributes here would represent the various fields in each of these models). While an attribute defines a quality or characteristic of something, an entry describes the item itself by simply collecting these attributes under a name.

An example entry as displayed in the LDIF (LDAP Data Interchange Format) would look something like this:

dn: sn=Ellingwood,ou=people,dc=digitalocean,dc=com
objectclass: person
sn: Ellingwood
cn: Justin Ellingwood

The above example could be a valid entry within an LDAP system.

DIT

It is easy to recognize that the data defined by attributes only represents part of the available information about an object. The rest is found the entry’s placement within the LDAP system and the relationships that this implies.

One way to distinguish between entries of different types is by establishing relationships and groups. This is largely a function of where the entry is placed when it is created. Entries are all added to an LDAP system as branches on trees called Data Information Trees, or DITs.

A DIT represents an organizational structure similar to a file system where each entry (other than the top-level entry) has exactly one parent entry and may have any number of child entries beneath it. Since entries in an LDAP tree can represent just about anything, some entries will be used mainly for organizational purposes, similar to directories within a filesystem.In this way, you may have an entry for “people” and an entry for “inventoryItems”. Your actual data entries could be created as children of these to better distinguish their type. Your organizational entries can be arbitrarily defined to best represent your data.

In the example entry in the last section, we see one indication of the DIT in the dn line:

dn: sn=Ellingwood,ou=people,dc=digitalocean,dc=com

This line is called the entry’s distinguished name (more on this later) and is used to identify the entry. It functions like a full path back to the root of the DIT. In this instance, we have an entry called sn=Ellingwood, which we are creating. The direct parent is an entry called ou=people which is probably being used as a container for entries describing people. The parents of this entry derived from the digitalocean.com domain name, which functions as the root of our DIT.

Defining LDAP Data Components

Let’s start from the bottom in terms of complexity again and work our way up.

Attribute Definitions

Attributes are defined using fairly involved syntax. They must indicate the name for an attribute, any other names that can be used to refer to the attribute, the type of the data that may be entered, as well as a variety of other metadata. This metadata can describe the attribute, tell LDAP how to sort or compare the attribute’s value, and tell how it relates to other attributes.

For example, this is the definition for the name attribute:

attributetype ( 2.5.4.41 NAME 'name' DESC 'RFC4519: common supertype of name attributes'
        EQUALITY caseIgnoreMatch
        SUBSTR caseIgnoreSubstringsMatch
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{32768} )

The 'name' is the name of the attribute. The number in the first line is a globally unique OID (object ID) assigned to the attribute to differentiate it from every other attribute. The rest of the entry defines how the entry can be compared during searches and has a pointer telling where to find information for the data type requirements of attribute.

One important part of an attribute definition is whether the attribute may be defined more than once in an entry. For instance, the definition may define that a surname may only be defined once per entry, but an attribute for “niece” may allow that attribute to be defined multiple times in a single entry. Attributes are multi-value by default, and must contain the SINGLE-VALUE flag if they may only be set once per entry.

Attribute definitions are much more complicated than using and setting attributes. Fortunately, for the most part you will not have to define your own attributes because the most common ones are included with most LDAP implementations and others are available to import easily.

ObjectClass Definitions

Attributes are collected within entities called objectClasses. ObjectClasses are simply groupings of associated attributes that would be useful in describing a specific thing. For instance, “person” is an objectClass.

Entries gain the ability to use an objectClass’s attributes by setting a special attribute called objectClass, naming the objectClass you wish to use. In fact, objectClass is the only attribute you can set in an entry without specifying a further objectClass.

So if you are creating an entry to describe a person, including objectClass person (or any of the more specific person objectClasses derived from person — we’ll cover this later) allows you to use all of the attributes within that objectClass:

dn: . . .
objectClass: person

You would then have the ability to set these attributes within the entry:

• cn: Common name
• description: Human-readable description of the entry
• seeAlso: Reference to related entries
• sn: Surname
• telephoneNumber: A telephone number
• userPassword: A password for the user

The objectClass attribute can be used multiple times if you need attributes from different objectClasses, but there are rules that dictate what is acceptable. ObjectClasses are defined as being one of several “types”.

The two main types of ObjectClasses are structural or auxiliary. An entry must have exactly one structural class, but may have zero or more auxiliary classes used to augment the attributes available to the class. A structural objectClass is used to create and define the entry, while the auxiliary objectClasses add additional functionality through extra attributes.

ObjectClass definitions determine whether the attributes that they provide are required (indicated by a MUST specification) or optional (indicated by a MAY specification). Multiple objectClasses can provide the same attributes and an attribute’s MAY or MUST categorization may vary from objectClass to objectClass.

As an example, the person objectClass is defined like this:

objectclass ( 2.5.6.6 NAME 'person' DESC 'RFC2256: a person' SUP top STRUCTURAL
  MUST ( sn $ cn )
  MAY ( userPassword $ telephoneNumber $ seeAlso $ description ) )

This is defined as a structural objectClass, meaning that it can be used to create an entry. The entry created must set the surname and commonname attributes, and may choose to set the userPassword, telephoneNumber, seeAlso, or description attributes.

Schemas

ObjectClass definitions and attribute definitions are, in turn, grouped together in a construct known as a schema. Unlike traditional relational databases, schemas in LDAP are simply collections of related objectClasses and attributes. A single DIT can have many different schemas so that it can create the entries and attributes it needs.

Schemas will often include additional attribute definitions and may require the attributes defined in other schemas. For example, the person objectClass that we discussed above requires that the surname or sn attribute be set for any entries using the person objectClass. If these are not defined within the LDAP server itself, a schema containing these definitions could be used to add these definitions to the server’s vocabulary.

The format of a schema is basically just a combination of the above entries, like this:

. . .

objectclass ( 2.5.6.6 NAME 'person' DESC 'RFC2256: a person' SUP top STRUCTURAL
  MUST ( sn $ cn )
  MAY ( userPassword $ telephoneNumber $ seeAlso $ description ) )

attributetype ( 2.5.4.4 NAME ( 'sn' 'surname' )
  DESC 'RFC2256: last (family) name(s) for which the entity is known by' SUP name )

attributetype ( 2.5.4.4 NAME ( 'cn' 'commonName' )
  DESC 'RFC4519: common name(s) for which the entity is known by' SUP name )

. . .

Data Organization

We’ve covered the common elements that are used to construct entries within an LDAP system and talked about how these building blocks are defined within the system. However, we haven’t talked much about how the information itself is organized and structured within an LDAP DIT yet.

Placing Entries within the DIT

A DIT is simply the hierarchy describing the relationship of existing entries. Upon creation, each new entry must “hook into” the existing DIT by placing itself as a child of an existing entry. This creates a tree-like structure that is used to define relationships and assign meaning.

The top of the DIT is the broadest categorization under which each subsequent node is somehow descendent. Typically, the top-most entry is simply used as a label indicating the organization that the DIT is used for. These entries can be of whatever objectClasses desired, but usually they are constructed using domain components (dc=example,dc=com for an LDAP managing info associated with example.com), locations (l=new_york,c=us for an organization or segment in NY), or organizational segments (ou=marketing,o=Example_Co).

Entries used for organization (used like folders) often use the organizationalUnit objectClass, which allows the use of a simple descriptive attribute label called ou=. These are often used for the general categories under the top-level DIT entry (things like ou=people, ou=groups, and ou=inventory are common). LDAP is optimized for finding information laterally along the tree rather than up and down within the tree, so it is often best to keep the DIT hierarchy rather shallow, with general organizational branches and further subdivision indicated through the assignment of specific attributes.

Naming and Referencing Entries within the DIT

We refer to entries by their attributes. This means that each entry must have an attribute or group of attributes that is unambiguous at its level in the DIT hierarchy. This attribute or group of attributes is called the entry’s relative distinguished name or RDN and it functions like a file name.

To refer to an entry unambiguously, you use the entry’s RDN combined with all of its parent entries’ RDNs. This chain of RDNs leads back up to the top of the DIT hierarchy and provides an unambiguous path to the entry in question. We call this chain of RDNs the entry’s distinguished name or DN. You must specify the DN for an entry during creation so that the LDAP system knows where to place the new entry and can ensure that the entry’s RDN is not being used by another entry already.

As an analogy, you can think of an RDN as a relative file or directory name, as you would see in a file system. The DN, on the other hand is more analogous to the absolute path. An important distinction is that LDAP DNs contain the most specific value on the left-hand side, while file paths contain the most specific information on the right-hand side. DNs separate the RDN values with a comma.

For instance, an entry for a person named John Smith might be placed beneath a “People” entry for an organization under example.com. Since there might be multiple John Smiths in the organization, a user ID might be a better choice for the entry’s RDN. The entry might be specified like this:

dn: uid=jsmith1,ou=People,dc=example,dc=com
objectClass: inetOrgPerson
cn: John Smith
sn: Smith
uid: jsmith1

We had to use the inetOrgPerson objectClass to get access to the uid attribute in this instance (we still have access to all of attributes defined in the person objectClass, as we will see in the next section).

LDAP Inheritance

When it comes down to it, much of the way that data in an LDAP system relates to one another is a matter of hierarchies, inheritance, and nesting. LDAP initially seems unusual to many people because it implements some object-oriented concepts in its design. This mainly comes from its use of classes, as we have previously discussed, and the availability of inheritance, which we will talk about now.

ObjectClass Inheritance

Each objectClass is a class that describes the characteristics of objects of that type.

However, unlike simple inheritance, objects in LDAP can be and often are instances of multiple classes (some programming languages provide similar functionality through multiple inheritance). This is possible because LDAP’s conception of a class is simply a collection of attributes that it MUST or MAY have. This allows multiple classes to be specified for an entry (although only one STRUCTURAL objectClass can and must be present), resulting in the object simply having access to the merged collection of attributes with the strictest MUST or MAY declaration taking precedence.

In its definition, an objectClass can identify a parent objectClass from which to inherit its attributes. This is done using SUP followed by the objectClass to inherit from. For instance, the organizationalPerson objectClass begins like this:

objectclass ( 2.5.6.7 NAME 'organizationalPerson' SUP person STRUCTURAL
 . . .

The objectClass following the SUP identifier is the parent objectClass. The parent must share the objectClass type of the objectClass being defined (for instance STRUCTURAL or AUXILIARY). The child objectClass automatically inherits the attributes and attribute requirements of the parent.

When assigning an objectClass in an entry, you only need to specify the most specific descendent of an inheritance chain to have access to the attributes all the way up. In the last section, we used this to specify inetOrgPerson as the sole objectClass for our John Smith entry while still having access to the attributes defined in the person and organizationalPerson objectClasses. The inetOrgPerson inheritance hierarchy looks like this:

inetOrgPerson -> organizationalPerson -> person -> top

Almost all objectClass inheritance trees end with a special objectClass called “top”. This is an abstract objectClass whose only purpose is to require that objectClass itself be set. It is used to indicate the top of the inheritance chain.

Attribute Inheritance

In a similar way, attributes themselves can list a parent attribute during their definition. The attribute will then inherit the properties that were set in the parent attribute.

This is often used for making more specific versions of a general attribute. For instance, a surname is a type of name and can use all of the same methods to compare and check for equality. It can inherit these qualities to get the general form of a “name” attribute. In fact, the actual surname definition may contain little more than a pointer back to the parent attribute.

This is useful because it allows for the creation of a specific attribute that is useful for people interpreting the element, even when its general form remains unchanged. The inheritance of the surname attribute we discussed here helps people distinguish between a surname and a more general name, but other than the value’s meaning, there is little difference between a surname and name to the LDAP system.

LDAP Protocol Variations

We mentioned at the beginning that LDAP is actually just the protocol that defines the communication interface for working with directory services. This is generally just known as the LDAP or ldap protocol.

It is worth mentioning that you might see some variants on the regular format:

• ldap://: This is the basic LDAP protocol that allows for structured access to a directory service.
• ldaps://: This variant is used to indicate LDAP over SSL/TLS. Normal LDAP traffic is not encrypted, although most LDAP implementations support this. This method of encrypting LDAP connections is actually deprecated and the use of STARTTLS encryption is recommended instead. If you are operating LDAP over an insecure network, encryption is strongly recommended.
• ldapi://: This is used to indicate LDAP over an IPC. This is often used to connect securely with a local LDAP system for administrative purposes. It communicates over internal sockets instead of using an exposed network port.

All three formats uses the LDAP protocol, but the last two represents  additional information about how it is being used.–

LDAP Admin is a free Windows LDAP client and administration tool for LDAP directory management. This application lets you browse, search, modify, create and delete objects on LDAP server. It also supports more complex operations such as directory copy and move between remote servers and extends the common edit functions to support specific object types

LDAP Admin is owned by LDAP Admin(http://www.ldapadmin.org/) and they own all related trademarks and IP rights for this software.

LDAP on cloud for AWS

 Few important features of LDAP are mentioned below:

LDAP Is an Open Standard Protocol

Selecting a NoSQL database, is mostly like barring yourself into that one type of database because each one has its own protocol. If you change the server, you have to change all the clients at the same time. You could write your own API compatibility layer that sits between applications and the database, but you’re still on the hook for finding a database that supports all the same functionality. If you go with an RDBMS, then you’ll find that SQL is much more standardized, and you may be lucky enough to just install a new database driver. But that still means updating all of your clients to ensure that they can talk to the new database, and you’ll find that most relational databases have their own unique interpretation of what SQL really means.

LDAP is a well-defined protocol. RFC 4511 explicitly specifies how clients should encode requests and how servers should encode responses. There are a wide variety of directory servers and client APIs available, so choosing one doesn’t mean that you’re stuck with it forever.

It is true that not all LDAP servers provide the same set of features. Different servers may support different sets of controls, extended operations, and SASL mechanisms, but in those cases, the server’s root DSE should advertise what it does support, and clients can look at that to decide what kind of requests to send.

Additional, there are some things that LDAP specifications don’t cover, like how to interact with the server configuration. But most applications don’t need to interact with the server configuration, except maybe when setting them up (for example, to ensure that an appropriate set of indexes are defined), and a properly designed application should provide some mechanism for performing manual setup.

LDAP Is Mature but Evolving

LDAP has been everywhere for a while. The most recent version of the specification, LDAPv3, was officially released in December of 1997. Previous versions of LDAP were around for a few years before that. And LDAP is itself a lightweight version of X.500, which was developed for the telecommunications industry in the late 1980s. It’s factually a carrier-grade protocol and service.

Though, that’s not to say that it’s motionless. There have been revisions and clarifications of the protocol since then, and there is still active standards work. In addition, because LDAP is a critical component of most large enterprises and Internet-scale companies, there’s a lot of competition between vendors that keeps driving performance, scalability, and innovation forward. If you looked at LDAP a long time ago but haven’t checked it out recently, your impression of it may be very out of date.

LDAP Is Lightweight

That’s what the “L” in LDAP stands for. It’s technically a lightweight version of X.500, but it’s also very lightweight in comparison to most other “modern” protocols. LDAP messages are encoded with ASN.1 BER, which is a compact binary format that is very efficient to encode and decode. It’s much more streamlined than something like JSON or XML over HTTP.

LDAP also uses persistent connections for communicating with a directory server. Whereas many modern HTTP-based protocols use relatively short-lived connections, LDAP connections can live for hours or days or even longer. This can make a big difference when it comes to performance and scalability because establishing a new connection is significantly more expensive than using one that’s already available, especially when using secure connections that require negotiating or resuming a TLS session. And because the server can associate state information with the connection, it’s not necessary for the client to include identifying information with each request, which makes them even smaller and more efficient.

LDAP Is Secure

LDAP directory servers are often used as an authentication repository, and are often used to store sensitive information like passwords and other account details. As such, security is an important aspect of most directory servers. This includes a great deal of password policy functionality, like strong encoding mechanisms and constraints that can prevent users from selecting weak passwords, but it also includes support for a variety of authentication types through SASL (the simple authentication and security layer), including the possibility of two-factor options through mechanisms like one-time passwords.

LDAP applications characteristically perform operations as the end user, which better guarantees that their activities are properly controlled, and also provides a improved inspection track.

Major Features of LDAP