Directory Information Tree
Encyclopedia
A directory information tree (DIT) is data represented in a hierarchical tree-like structure consisting of the Distinguished Names (DNs) of directory service
entries.
Both the X.500
protocols and the Lightweight Directory Access Protocol
(LDAP) use directory information trees as their fundamental data structure.
Typically, an X.500 or LDAP deployment for a single organization will have a directory information tree that consists of two parts:
The original assumption of X.500 was that all directory servers would be interconnected to form a single, global namespace
. The entries at the top level of the tree corresponded to countries, identified by their ISO 3166
two letter country code. The entries subordinate to a country's entry would correspond to states or provinces, and national organizations. The naming system for a particular country was determined by that country's national standards body or telecommunications provider.
A limitation of the original directory information tree structure was the assumption that applications searching for an entry in a particular organization would navigate the directory tree by first browsing to the particular country where that organization was based, then to the region where that organization was based, then locate the entry for the organization itself, and then search within that organization for the entry in question. The desire to support searching more broadly for an individual person when all the particulars of that person's location or organization were not known led to experiments in directory deployment and interconnection, such as the Common Indexing Protocol
.
Today, most LDAP deployments, and in particular Active Directory
deployments, are not interconnected into a single global naming space, and do not use national country codes as the basis for naming. Instead, these deployments follow a directory structure which at the top level mirrors that of the Domain Name System
, as described by RFC 2247. For example, the entry for an organization with domain name "example.com" would have a distinguished name of "dc=example, dc=com", and all entries in that organization's directory information tree would contain that distinguished name suffix.
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.
Directory service
A directory service is the software system that stores, organizes and provides access to information in a directory. In software engineering, a directory is a map between names and values. It allows the lookup of values given a name, similar to a dictionary...
entries.
Both the X.500
X.500
X.500 is a series of computer networking standards covering electronic directory services. The X.500 series was developed by ITU-T, formerly known as CCITT, and first approved in 1988. The directory services were developed in order to support the requirements of X.400 electronic mail exchange and...
protocols and the Lightweight Directory Access Protocol
Lightweight Directory Access Protocol
The Lightweight Directory Access Protocol is an application protocol for accessing and maintaining distributed directory information services over an Internet Protocol network...
(LDAP) use directory information trees as their fundamental data structure.
Typically, an X.500 or LDAP deployment for a single organization will have a directory information tree that consists of two parts:
- a top level name structure for the name of the organization itself
- a representation of the data model structure within the organization
Top level naming
The top levels of a directory information tree frequently represent political and geographic divisions.The original assumption of X.500 was that all directory servers would be interconnected to form a single, global namespace
Namespace (computer science)
A namespace is an abstract container or environment created to hold a logical grouping of unique identifiers or symbols . An identifier defined in a namespace is associated only with that namespace. The same identifier can be independently defined in multiple namespaces...
. The entries at the top level of the tree corresponded to countries, identified by their ISO 3166
ISO 3166
ISO 3166 is a standard published by the International Organization for Standardization . It defines codes for the names of countries, dependent territories, special areas of geographical interest, and their principal subdivisions . The official name of the standard is Codes for the representation...
two letter country code. The entries subordinate to a country's entry would correspond to states or provinces, and national organizations. The naming system for a particular country was determined by that country's national standards body or telecommunications provider.
A limitation of the original directory information tree structure was the assumption that applications searching for an entry in a particular organization would navigate the directory tree by first browsing to the particular country where that organization was based, then to the region where that organization was based, then locate the entry for the organization itself, and then search within that organization for the entry in question. The desire to support searching more broadly for an individual person when all the particulars of that person's location or organization were not known led to experiments in directory deployment and interconnection, such as the Common Indexing Protocol
Common Indexing Protocol
The Common Indexing Protocol was an attempt in the IETF working group FIND during the mid-1990s to define a protocol for exchanging index information between directory services....
.
Today, most LDAP deployments, and in particular Active Directory
Active Directory
Active Directory is a directory service created by Microsoft for Windows domain networks. It is included in most Windows Server operating systems. Server computers on which Active Directory is running are called domain controllers....
deployments, are not interconnected into a single global naming space, and do not use national country codes as the basis for naming. Instead, these deployments follow a directory structure which at the top level mirrors that of the Domain Name System
Domain name system
The Domain Name System is a hierarchical distributed naming system for computers, services, or any resource connected to the Internet or a private network. It associates various information with domain names assigned to each of the participating entities...
, as described by RFC 2247. For example, the entry for an organization with domain name "example.com" would have a distinguished name of "dc=example, dc=com", and all entries in that organization's directory information tree would contain that distinguished name suffix.
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.