Our guide to LDAP is intended to save you time, make you more productive, and remove some of the frustrations that LDAP tends to create.
A Guide to LDAP for System Administrators
This guide to LDAP primarily serves as an introduction. If you are just starting out, this guide to LDAP should be just what you are looking for. Well, we hope it is. However, you may still find our guide to LDAP useful even if you think you know all there is to know about LDAP!
LDAP – Lightweight Directory Access Protocol
LDAP is a protocol for accessing information directories. It is used in e-mail programs and web browsers to allow lookup queries to be run. LDAP is also used by Active Directory, and if you run a large website, it can be useful to use LDAP for authentication. LDAP is also used for management systems. The main advantage of LDAP is it is quick and has been developed for high speed reads.
Forget about SQL for access. LDAP doesn’t use it. Instead ldapmodify and ldapsearch commands are used. LDAP also uses different search criteria, something referred to as Polish notation.
For example, you could perform a lookup:
(& (cn=Holmes)(st=122b Baker Street)
That search would be used to find all individuals with a common name (cn) of Holmes, who are living in (st) 122b Baker Street.
Common name is used for the main attribute of the search and will locate the record. LDAP also uses Uid.
You must include the operator & (AND) which will connect the two criteria. A “|” (pipe) is OR in Polish notation.
However, it is much simpler to perform searches if you don’t use Polish notation.
In the above example, the search criteria used would be cn=Holmes, and the attributes to return are detailed in the last three fields (cn uid st)
What does an LDAP record look like?
The DN should be familiar to you as it is the same as that used in an SSL certificate. Using our example, the LDAP record would look like this:
Pay attention to the objectclass attribute. This is just like a table schema. Each objectclass is used for a different additional attribute, which could be any number of fields such as telephone number, assigned mysteries, etc. etc.
If you want to check the LDAP schema, you can query cn=schema
DN (Domain Name)
The DN or domain name is the first line in an LDAP record. It will tell you the exact address in the Directory Tree (DIT). This will tell you which organizational unit (ou) the record belongs to.
dn: cn=detectives, dc=Britain, dc=com
The records can belong to groups, in this case the group is “detectives.”
The uniqueMember group attribute is used to keep track of members of the group. The DN is listed for each of the unique members of the group in the above example.
You will find that some LDAP servers will list groups in two ways. For example, Novell eDirectory will list the members of the group on the group record, and the individual groups that each user is a member of on the user record. The attribute “MemberOf” is used in this regard.
LDAP servers have LDAP records stored in native format. LDIF (LDAP interchange format) is used to add and delete records. To delete a record, we would use the following (Note the second line of the record is the operation.)
And to add a record…
You are likely to find that your main problem with the operation of LDAP, and providing LDAP support, is ensuring that replication continues to work. You are likely to discover quite quickly that replication of one LDAP server will result in a substantial cache backlog.
If you are conducting a round robin operation, and your configuration has the web server looking at a number of different LDAP servers, an error condition may be caused.
A situation could arise where someone signs up for a website and is prevented from logging on. This is because it could take time for a user to be added on a record on one LDAP server and for that entry to be replicated on a second LDAP server.
Ldapsearch commands are used to monitor replication. For example, if you use Oracle, you would conduct a search using cn=replica
LDAP cache management
It is important to use as large a cache as possible if you have a high capacity, high volume LDAP server. That said, make sure you know the available memory on the machine. If you have sufficient memory, it should be possible to cache the full LDAP database. By doing this you will be able to reduce seek time for search operations.
LDAP account maintenance
As a system administrator you are likely to have to spend a considerable amount of your time resetting user passwords. This is one of the main ways you can determine if it is a user error that is preventing an individual from being able to login, or whether the problem is something more serious.
If possible, set up your website so the user can reset their own password. If not, use the Sun LDAP or Active Directory graphical interface to reset passwords.
Since you have much better uses of your time than resetting user passwords, if you find that a big chunk of your day is spent resetting passwords, try this…
Save an LDIF file and use ldapmodify against it to change the uid of the user. This will save you quite a bit of time, plus it is easier than using the graphical interface!
Recipient verification and sender authentication are essential if you want to maintain secure email flow.
A large proportion of spam email – and malware contained in those emails – can be blocked once you have identified trusted senders.
SpamTitan can be configured to ‘synchronize’ with your LDAP server, and by doing so, will create accounts for domain users automatically.
Bear in mind that ArcTitan can be used to archive LDAP records. We hope that you never have a need for disaster recovery, but if you do, recovery is easy as your LDIF records will be kept in the same permanent storage.