Directory Information Tree - Organizational Structure

Organizational Structure

The elements of an organization represented in the directory (e.g., people, roles, or devices) in a DIT may be modeled by a variety of techniques. The determining factors include:

• requirements of the applications which will be searching and updating the directory
• the requirement to provide a unique name for each entry
• the desire for stability of the directory structure
• the desire for human-readability of the Distinguished Names of entries in the directory
• the ease of importing data into the directory from existing databases and other directories

Early deployments of X.500 within corporations and institutions with entries representing the employees of those organizations often used a DIT structure which mirrored the organizational structure, with organizational unit entries corresponding to departments or divisions of the organization. The relative distinguished names of the entries for employees were often formed from the common names of the individual employees. An example DN of an early X.500/LDAP deployment might be "cn=Joe Bloggs, ou=Marketing, ou=Operations, o=Example Corporation, st=CA, c=US". The disadvantage of this approach is that it when the organizational structure is changed, or if employees change their legal name, it can require the moving or renaming of entries in the directory, which adds both complexity and overhead and can also upset applications not designed to deal gracefully with such moves.

Today, many large deployments of X.500 or LDAP use a single, flat namespace for the entries, and choose to name the entries for individuals based on a relative distinguished name that is an organizationally-assigned identifier, such as a username or an employee number. Today, a DN might resemble "uid=00003,ou=People, dc=example, dc=com". The advantage of this structure is that entries need not be moved even when employees change their name, or are transferred to different departments. These changes can be effected through just an attribute modification, and applications which may be using the DN as a unique identifier (e.g. in a database) do not need to be touched.