Snip
|
Directory structure
|
---|
Categories |
|
---|
For Snip |
loading snip actions ... |
---|---|
For Page |
loading url actions ... |
The protocol accesses LDAP directories, which follow the 1993 edition of the X.500 model:
Be aware that a DN may change over the lifetime of the entry, for instance, when entries are moved within a tree. To reliably and unambiguously identify entries, a UUID might be provided in the set of the entry's operational attributes.
An entry can look like this when represented in LDIF format (LDAP itself is a binary protocol):
dn: cn=John Doe,dc=example,dc=com cn: John Doe givenName: John sn: Doe telephoneNumber: +1 888 555 6789 telephoneNumber: +1 888 555 1234 mail: john@example.com manager: cn=Barbara Doe,dc=example,dc=com objectClass: inetOrgPerson objectClass: organizationalPerson objectClass: person objectClass: top
dn is the name of the entry; it's not an attribute nor part of the entry. "cn=John Doe" is the entry's RDN, and "dc=example,dc=com" is the DN of the parent entry. The other lines show the attributes in the entry. Attribute names are typically mnemonic strings, like "cn" for common name, "dc" for domain component, "mail" for e-mail address and "sn" for surname.
A server holds a subtree starting from a specific entry, e.g. "dc=example,dc=com" and its children. Servers may also hold references to other servers, so an attempt to access "ou=department,dc=example,dc=com" could return a referral or continuation reference to a server which holds that part of the directory tree. The client can then contact the other server. Some servers also support chaining, which means the server contacts the other server and returns the results to the client.
HTML |
<h2><span class="mw-headline">Directory structure</span></h2> <p>The protocol accesses LDAP directories, which follow the 1993 edition of the <a href="/wiki/X.500" title="X.500">X.500</a> model:</p> <ul> <li>A directory is a <a href="/wiki/Directory_Information_Tree" title="Directory Information Tree">tree of directory entries</a>.</li> <li>An entry consists of a set of attributes.</li> <li>An attribute has a name (an <i>attribute type</i> or <i>attribute description</i>) and one or more values. The attributes are defined in a <i>schema</i> (see below).</li> <li>Each entry has a unique identifier: its <i>Distinguished Name</i> (DN). This consists of its <i>Relative Distinguished Name</i> (RDN) constructed from some attribute(s) in the entry, followed by the parent entry's DN. Think of the DN as a full filename and the RDN as a relative filename in a folder.</li> </ul> <p>Be aware that a DN may change over the lifetime of the entry, for instance, when entries are moved within a tree. To reliably and unambiguously identify entries, a <a href="/wiki/UUID" title="UUID">UUID</a> might be provided in the set of the entry's <i>operational attributes</i>.</p> <p>An entry can look like this when represented in <a href="/wiki/LDIF" title="LDIF">LDIF</a> format (LDAP itself is a <a href="/w/index.php?title=Binary_protocol&action=edit" class="new" title="Binary protocol">binary protocol</a>):</p> <pre> dn: cn=John Doe,dc=example,dc=com cn: John Doe givenName: John sn: Doe telephoneNumber: +1 888 555 6789 telephoneNumber: +1 888 555 1234 mail: john@example.com manager: cn=Barbara Doe,dc=example,dc=com objectClass: inetOrgPerson objectClass: organizationalPerson objectClass: person objectClass: top </pre> <p>dn is the name of the entry; it's not an attribute nor part of the entry. "cn=John Doe" is the entry's RDN, and "dc=example,dc=com" is the DN of the parent entry. The other lines show the attributes in the entry. Attribute names are typically mnemonic strings, like "cn" for common name, "dc" for domain component, "mail" for e-mail address and "sn" for surname.</p> <p>A server holds a subtree starting from a specific entry, e.g. "dc=example,dc=com" and its children. Servers may also hold references to other servers, so an attempt to access "ou=department,dc=example,dc=com" could return a <i>referral</i> or <i>continuation reference</i> to a server which holds that part of the directory tree. The client can then contact the other server. Some servers also support <i>chaining</i>, which means the server contacts the other server and returns the results to the client.</p> |
---|