 | Summary
In this tutorial you learned about LDAP concepts, architecture, and
design. LDAP grew out of a need to connect to X.500 directories over
IP in a simplified way. A directory presents data to you in a
hierarchical manner, much like a tree. Within this tree are records
that are identified by a distinguished name and have many
attribute-value pairs, including one or more object classes that
determine what data can be stored in the record.
LDAP itself refers to the protocol used to search and modify the tree.
Practically though, the term LDAP is used for all components, such as
LDAP server, LDAP data, or just "It's in LDAP".
Data in LDAP is often imported and exported with LDIF, which is a
textual representation of the data. An LDIF file specifies a
changetype, such as
add, delete,
modrdn, moddn,
and modify. These operations let you add
entries, delete entries, move data around in the tree, and change
attributes of the data.
Designing the tree correctly is crucial to long-term viability of the
LDAP server. A correct design means fewer change operations are
needed, which leads to consistent data that can easily be found by
other applications. By choosing common attributes, you ensure that
other consumers of the LDAP data understand the meaning of the
attributes and that fewer translations are required.
The LDAP schema dictates which attributes can be used in your server.
Within the schema are definitions of the attributes, including OIDs to
uniquely identify them, instructions on how to store and sort the
data, and textual descriptions of what the attributes do. Object
classes group attributes together and can be defined as structural,
auxiliary, or abstract.
Structural object classes define the record, so a record may only have
one structural object class. Auxiliary object classes add more
attributes for specific purposes and can be added to any record. An
abstract object class must be inherited and cannot be used
directly.
| |
