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 a more high-level overview. Here is a guide on generating a self-signed SSL certificate: How to enable LDAP over SSL with a self-signed certificate.

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.

What is Lightweight Directory Access Protocol

Note: The latter may be users, persons, printers, scanners, computers, or servers, as the case may be. Although the system allows a high degree of flexibility in mapping structures, the definition of the elements in the schema is rather strict. Here are some use 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 the Active Directory environment, the LDAP directory provides information about users, computers, and their group membership. But other objects, such as computer certificates, 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. Let’s 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.

What is Lightweight Directory Access Protocol

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-liner 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

Furthermore, Surname is the surname here, while the Given name represents the first name. However, See the following link for more information on LDAP. I hope you found this blog post helpful. Moreover, Please let me know in the comment session if you have any questions.