It is also common for there to be sub-hierarchies (often called branches) below the naming context.
APACHE DIRECTORY STUDIO ACRONYM LIST FREE
You are, of course, free to use however many RDN components and whatever attributes you wish to comprise the naming contexts for your directory service. It is not uncommon for DITs with a country-based naming context to also include other geographic information in the hierarchy, as well as the name of the organization (e.g., o=Example Corp,l=Austin,st=Texas,c=US), as was also the convention in X.500 and is commonly used in certificate subject naming. This was a common style of naming for X.500 deployments, but is no longer all that common in the LDAP world (except perhaps for directories that primarily exist to serve as PKI registries, because this kind of structure is commonly used for certificate subjects), especially among multinational organizations (or organizations that aspire to be multinational organizations).
APACHE DIRECTORY STUDIO ACRONYM LIST CODE
The value of the c attribute should be the two-character ISO 3166 country code for the country in which the server resides (e.g., c=US). The entry has an object class of country and a naming attribute of c. The value of the o attribute may be the name of the organization (e.g., o=Example Corp), but it is also a fairly common practice to make it the DNS domain name for the organization (e.g., o=).
The entry has an object class of organization and a naming attribute of o. It is perfectly legal for a naming context to have multiple components, so just because the server has an entry with a DN of dc=example,dc=com there does not necessarily have to be an entry with a DN of dc=com. For example, if the organization has a domain of, then the naming context would probably be something like dc=example,dc=com. This convention is derived from the specification contained in RFC 2247, in which the naming context is comprised of multiple components that make up the DNS domain of the organization with which it is associated. The entry has an object class of domain and a naming attribute of dc (which is short for domain component). In a large number of deployments, the entry that serves as the naming context for a tree falls into one of the following categories: However, there are some common conventions. There is no standard that mandates any particular structure for LDAP DITs, so directory servers may hold entries in any kind of hierarchical arrangement. Note, however, that it is acceptable for servers to have DITs that are outside the declared set of naming contexts if those entries are intended to provide some operational purpose for the server (e.g., to expose the server configuration, to provide monitoring information about the health of the server, to provide schema information, etc.) rather than holding data supplied by users of the directory service.
This entry will be described in detail below, but one of the operational attributes that it exposes is called namingContexts, which provides a list of all of the DNs that act as naming contexts for the DITs that may be held in the server. This isn’t universally the case, but it is nevertheless a common occurrence.Īll LDAP servers must expose a special entry, called the root DSE, whose DN is the zero-length string. Note, however, that despite the tree analogy, LDAP DITs are often pretty flat, with the vast majority of entries being leaf entries (i.e., entries that do not have any children), and only a relatively small number of non-leaf entries. Each tree has a single root entry, which is called the naming context (or in some servers, a suffix). This structure is called the Directory Information Tree, or DIT. LDAP directory servers present data arranged in tree-like hierarchies in which each entry may have zero or more subordinate entries.
0 kommentar(er)
