Skip to content

System Administrators Guide to LDAP

Posted by Geraldine Hunt on Wed, Jan 14th, 2015

This System Administrators Guide to LDAP will show you efficient and smart ways to use LDAP that will make your life easier?  If you already understand what LDAP is, what it’s used for and the specific vocabulary of LDAP then you may still find this article useful. Here we present a  brief introduction to LDAP for system administrators and programmers - if you’ve ever been concerned in the past about any aspect of LDAP, this article is for you!

LDAP is the Light Weight Directory Access Protocol.

It is a protocol used to access information directories such as addresses and phone numbers. It is implemented in Web browsers and e-mail programs to enable lookup queries. Very large web sites use LDAP for authentication as does Active Directory. The reason for that is LDAP is tuned for high speed reads. Identity Management systems also are often driven by LDAP.

LDAP does not use SQL for access.  Instead you using the ldapsearch or ldapmodify commands. Both are included in most Linux distributions.

The search criteria for LDAP uses something called Polish notation.  For example:  (&(cn=Cameron)(st=10 Downing Street))

That means list everyone who lives on 10 Downing Street (st) whose cn (common name) is Cameron. The common name give the main attribute, like a key, used to locate a record.  Uid is used as well.

In Polish notation, the operator & (AND) connects the two filters with and.  The operator OR is the pipe “|”.

LDAP searches are usually simpler with no Polish notation, like this:

ldapsearch -D cn=directory manager -w password -p port -h hostname -b dc=example,dc=com -b"  objectclass=person   cn uid st

with these command line options:

-D is the DN of user who is running this query. See below for an explanation of DN. In this example it is the Sun super user Directory Manager.

-w their password.

-p is port. The default port is 386.

–s sub option means search scope. In this example it means search below and including the –b base (dc=example,dc=com).  For example the base could be dc=example,dc=com or ou=employees, dc=example,dc=com.  Writing a domain like in two words like this is called domain components.

cn=Cameron is the search criteria 

The last three fields tell which attributes to return (cn uid st  in this case).

LDAP Record

The DN in an LDAP record is the same as the DN in an SSL certificate.  For example, an LDAP record can look like this:

dn: uid=Cameron, ou=politicians, dc=Britain, dc=com

            objectclass: person

            objectclass: organizationalPerson

            objectclass: inetOrgPerson

            uid: cameron

            userpassword: {crypt}23232GGHSS

Notice the objectclass attribute. Think of objectclass like a table schema. Each object classes add additional attributes like telephone number and so forth.  You can check the LDAP schema by querying cn=schema.


The first line in an LDAP record is the dn (domain name).  This gives the exact address in the DIT (directory tree) or where the record is located.  It also shows to which organizational unit (ou) the record belongs, in this case it is ou=politicians.  Think of organizational units as groups, except the word “group” has a quite distinct meaning in LDAP (see below).  An LDAP record belongs to one organizational unit but can belong to many groups.

The LDAP record for the organization unit looks like this:

dn: cn=politicians, dc=Britain, dc=com

objectclass: OrganizationalUnit


where cn is the name of the group.


People who can also belong to groups like this:

dn: cn=Conservative, dc=Britain, dc=com

objectclass: Group


uniqueMember: cn=Cameron, ou=politicians, dc=Britain, dc=com

uniqueMember: cn=Thatcher, ou=politicians, dc=Britain, dc=com

uniqueMember: cn=Heath, ou=politicians, dc=Britain, dc=com

This group keeps track of who are members of the group by the uniqueMember group attribute.  The DN of each unique member is there. 

Some LDAP servers, like Novell eDirectory, do this in two ways.  They list who belongs to each group on the group record and which groups the user belongs to on the user record using the MemberOf attribute.

LDIF Format

LDAP records are stored in native format in LDAP servers.  But to add or delete record you use LDIF (LDAP interchange format).  The second line of the record is the operation.  For example, this entry deletes a record:

dn: uid=Cameron, ou=politicians, dc=Britain, dc=com

changetype: delete

And this one adds a record:

dn: uid=Cameron, ou=politicians, dc=Britain, dc=com

changetype: add

objectclass: top

objectclass: person

objectclass: organizationalPerson

objectclass: inetorgPerson

LDAP Replication

For a systems administrator, the main issues with LDAP support and operation is keeping replication working.  Replication from one LDAP server of write operations can develop a significant cache backlog (queue).  This could cause an error condition in a round-robin operation where the web server is configured to look at multiple LDAP servers.  For example, if a user is added a record on LDAP server 1, it could take a few microseconds for the record to show up in LDAP server 2. So someone could sign up for a website and then not be able to log on if such operations take place on two different servers.

The way you monitor replication on LDAP is often done using ldapsearch commands.  For example, with Oracle you search for cn=replica.

LDAP Cache Management

For a high capacity high volume LDAP server the cache should be set as large as possible keeping in mind the available memory on the machine.  This reduces seek time for search operations which is important for web site login latency.  It is possible to cache the entire LDAP database if the memory is sufficient.

That should be enough general information to get you started with LDAP.  Remember than we archive LDAP records at ArcTitan and can keep your LDIF records in same, permanent storage and for disaster recovery.

LDAP Account Maintenance

Because LDAP is often used for website authentication, the LDAP administrator will spend a lot of time resetting user passwords when users cannot login or ruling out password problems as the reason they cannot login.  

If you website has self-service feature then the user’s can reset the password themselves.  If not you can reset their password using the graphical interface of Active Directory or Sun LDAP.  But If you find yourself changing passwords frequently, you could save an LDIF file and then run ldapmodify against that just changing the user’s uid.  This is much quicker than using a graphical interface.

Here is the password.ldif to use:


changetype: modify

replace: userPassword

userPassword: newPassword

ldapmodify command:

ldapmodify -c -a -f password.ldif -h hostname -p port -D cn=Directory Manager -w password

Here is how you can prove that the user’s password is working.  You are basically logging in as them and then looking up their record.

ldapsearch -D uid=user,dc=example,dc=com -w newPassword -p port -h hostname -b dc=example,dc=com -b  uid=user

Sender authentication and recipient verification are vital to maintaining the secure flow of email both in and out of your organization. Once you identify trusted senders and recipients you can block a large percentage of spam, viruses and malware from your network.  With SpamTitan you can 'synchronize' with your existing LDAP server to automatically create accounts for users in the domain.  

You might also like to read our article on the 7 Habits of Highly Effective System Administrators

Related Articles

Never Miss a Blog Post

Sign-up for email updates...

Get Your 14 Day Free Trial

Talk to Our Email and DNS Security Team

Call us on US +1 813 304 2544

Contact Us