Directory Services – Implementation Best Practices
(Authored by Ullas Tharakan and Bernard Diwakar)


With the global directory consolidation initiative, Directory services are becoming the foundation of the Identity Management programs. A robust and solid design based on patterns and best practices will ensure that once implemented it will have a long way to go.

1) Decouple LDAP layer and Application Layer – The DIT design changes should have minimum to zero dependency on the application layer. Application change should have a least impact on directory an vice versa

2) Expose API for LDAP Access – Applications should not be given direct LDAP access, All LDAP connections details should always be encapsulated and Application should be always oblivious about the port and other internal details of LDAP

3) Shallow Tree – Depth of the tree is inversely proportional to performance – Following this, a general rule of thumb says that the DIT should be reasonably shallow unless there are strong reasons to design deep branching levels down the directory tree.

4) Reduce Information Overload – Define and use standard object class that is defined by Standard LDAP RFC. Refrain from storing application specific information in the LDAP. Profile information attribute should focus not to exceed the number 20.

5) Flexibility - General pattern says that 95% of time the directories being designed are based on the organizational structure. Choosing to branch a directory tree based on the organizational structure, such as departments, can lead to a large administrative overhead if the organization is very dynamic and changes often.

6) But in cases where the organizational structures are pretty rigid and have impact and has less inter business interactions the model may be viable. A branching methodology that is flexible, and which still reflects enough information about the organization, must be created. Because the structure of organizations often changes considerably over time, the aim should be to branch the tree in such a way as to minimize the number of necessary changes to the directory tree once the organization has changed. Note that renaming a department entry, for example, has the effect of requiring a change of the DNs of all entries below its branch point. This has an undesirable impact on the service and application layer for several reasons. The example below reflects the impact of renaming branches -

When adding employees to their respective departments, it would be possible to create distinguished names (DN) like cn=Ullas Tharakan, ou=ESS, l=hyd, and dc=esswipro.com. If Ullas Tharakan should at a later time move to another department, his DN will have to change. This results in changing all entries regarding access rights and more. If Ullas Tharakan’s DN had been set to cn=Ullas Tharakan, ou=employees, l=hyd, dc= esswipro.com, then this would not be a problem. An attribute describing which department he belongs to (ou=marketing) could be added to his entry to include this information.

7) Physical or Cultural split criteria: Other criteria that may or should be considered when branching the directory tree include physical or cultural splits in the organization and the nature of the client (human or application).In case if an organization has separate units that are either physically separated or have their own management authorities, you might have a natural requirement to split and separate parts of the DIT.

9) Geographically Based Criteria: In a time where Global presences in terms of acquisitions or mergers are just the order of the day, there are situations where the employees, business partners, vendors, contractors etc are geographically distributed. It is a best practice to cater to this by designing the DIT on different geographic regions for eg, EMEA, North America, and Asia Pacific. By doing this there is flexibility in terms of managing the data and the Directory Topology in a effective manner. This also provided flexibility to cater to the different data laws in each of the regions.

10) Schema Design: The default ldap v3 schema provided in terms of objectclasses and attributes 9 out of 10 times does cater to most of the implementations, however there may be a need to define some custom objectclasses and attributes. In such a situation the rule of thumb is to define auxiliary classes and by doing this the schema is flexible enough to be used across the enterprise directory.

11) High Availability: This is one of the key considerations in any of the Enterprise Directory Implementations considering the fact that the directory services form the heart of any Identity Management Solutions. The leading directory services vendors in the market do provide robust replications mechanisms that enable high availability and fail over scenarios , however its very essential to consider some of the factors before the replication topologies are finalized upon --

a) Clients accessing the directory services should be replication aware and should process the referrals which basically let the client know which server to communicate for a particular request.
b) Most of the Identity Management products have limitations the way the directory topology is designed and this should be understood before designing any fault tolerant solution.
c) The peak loads in terms of the number of reads and writes need to be also considered.
d) The different data centers where the directory servers will be deployed.