LDAP is a network protocol used to perform queries and changes in a distributed directory service. The protocol from the TCP / IP protocol stack is specified in the RFCs 4510, 4511 and 4532.

LDAP itself is not a directory, but a protocol with which one can retrieve information from an LDAP directory. LDAP requires that all participating systems be able to exchange data on port 389 for unsecured transmission and port 636 for secure connection (TLS).

The idea behind LDAP is simple: A directory in a tree structure distributed over different servers should be searchable. See the video below for more high level overview.

The tree structure of the directory is broadly defined. The origin is the “root directory” and this branches into various groups such as organisations, organisational units and individuals etc.

Note: The latter may be users, persons, printers, scanners, computers, servers as the case may be. Although the system allows a high degree of flexibility in the mapping of structures, the definition of the elements in the schema is rather strict. Here are some uses cases for LDAP.

• User administration
• System administration
• Protocol
  
• NIS information
• Boot information
• File system mount point management
• Organisation of alias names in e-mail systems
• Administration of DNS zone data
• Organisation of DHCP servers

LDAP implementation in Active Directory
LDAP is widely implemented in Microsoft Active Directory (AD) and it is the fourth major component of Active Directory. Other components are Kerberos, CIFS, and DNS. In Active Directory environment, the LDAP directory provides information about users, computers, and their group membership. But other objects, such as the certificates of a computer, are stored in the directory.

LDAP basic structure is simple. LDAP consists of objects and follows largely the approach of object-oriented programming with classes, inheritance, polymorphism and the objects themselves. A directory service entry consists of a list of attributes and a “mandatory object” – the name of the object itself, the “Distinguished Name”.

This name is similar to a filename and shares the same property with the filename convention: it is not possible to have the same name in the same level. Objects named “OU” represent containers in which other objects can be created. Here are some attributes used with LDAP.

CN: commonName 
L: localityName 
ST: stateOrProvinceName 
O: organisationName 
OU: organisationalUnitName 
C: countryName 
STREET: streetAddress 
DC: domainComponent 
UID: userid

At first glance, this seems to be rather ambiguous, confusing and complex. Lets go into details and try to make sense of these attributes.

Let’s say an Active Directory is named techdirectarchive.local and a new user with the name “Martin, brown” is created while the selection on the root directory techdirectarchive.local is created. Here is how the attribute would look like.

CN = Martin brown, DC =  techdirectarchive, DC = local

Now the object is moved to an Organisation Unit (OU) with the title “persons” and the DN is looked at again:

CN = Martin brown, OU = persons, DC = techdirectarchive, DC = local

Within the OU people, another OU for better grouping of users due to job roles. This should be called “Accounting Employees” and the user object of Martin brown is assigned to this new OU. Thus, the DN is:

CN = Martin brown, OU = Accounting Employees, OU = persons, DC = techdirectarchive, DC = local

Now the logic is almost automatic. The commonName , the name of the object itself, is on the left side, while the assignment from the right side starts with the domain structure local , followed by techdirectarchive.

Conveniently, there are a large number of programs that can query a directory structure using LDAP; For Microsoft Windows, for example, the “LDAP Admin” by T. Karlovic is a compact and practical solution. On the other hand, there are many script variants to determine information via LDAP. Below is the PowerShell script:

$ strFilter = "(& (objectCategory = User))" 
$ objDomain = New-Object System.DirectoryServices.DirectoryEntry 
$ objSearcher = New-Object System.DirectoryServices.DirectorySearcher 
$ objSearcher.SearchRoot = $ objDomain 
$ objSearcher. PageSize = 1000 
$ objSearcher.Filter = $ strFilter 
$ objSearcher.SearchScope = "Subtree" 
$ colProplist = "name" 
foreach ($ i in $ colPropList) {$ objSearcher.PropertiesToLoad.Add ($ i)} 
$ colResults = $ objSearcher. FindAll () 
foreach ($ objResult in $ colResults) 
  {$ objItem = $ objResult.Properties; $ objItem.name}

It returns the usernames of the employees from the department (see first line department = editorial ). If the script is looking for something else, for example, employees whose login names contain a special sequence of letters, the first line looks something like this:

$ strFilter = "(& (objectCategory = User) (sAMAccountName = Me *))"

The asterisk behind “Me” acts as a wildcard here. The lower part of this PS command sequence (from the Microsoft homepage) can therefore be used quite well for other purposes. But, it’s also much, much easier – with a one-liners in the PowerShell:

Get-ADUser filter {Name -Like "*"} -Searchbase "OU = PEOPLE, DC = techdirectarchive, DC = local"

For example, if the administrator wants to read out the phone numbers, this one command will expand a bit:

Get-ADUser -filter {Surname -Like "*"} -properties cn, telephoneNumber -SearchScope Subtree-SearchBase "OU = People, DC = techdirectarchive, DC = local" | select-object Surname, Givenname, telephoneNumber

Surname is the surname here, while Givenname represents the first name.

For more training on LDAP, please watch this video below.

And See the following link https://help.ubuntu.com/lts/serverguide/openldap-server.html for more information on LDAP. Source: ip-insider