LDAPintro
Some start of an LDAP tutorial
Structure of an ldap tree
The structure of such an object tree is best explained by starting with a similar but simpler analogy. Consider a dictionary consisting of usual words. It is frequent to store such a dictionary in form of a tree, with one letter at each node, and nodes of last letters explictly marked. Words are represented in this form as paths from the root of the tree to one of the designated nodes.
Pic with apple, appetite, applaus(e?), appreciate
(The storage in this way is BTW quite efficient, as many words in a dictionary have a common root, which this way is appears only once in the storage. This of course actually only in cases where the a node does not only hold a single byte, or two, of data.)
An Ldap tree is similar, with some differences and extensions. First, the paths to the nodes are finally noted in reverse order when addressing/referencing them. For example, the above path would rather be written as
dc=e,dc=l,dc=p,dc=p,dc=p,dc=a
in LDAP. In this way it reminds of the way of notation of domains. Note that, as in the dictionary case, the above is a different node than the node
dc=l,dc=l,dc=p,dc=p,dc=p,dc=a
(i.e. they can be distingiushed) but both fork from the common parent "dc=l,dc=p,dc=p,dc=p,dc=a". (Therefore such a reference will be later also called "distinguished name".)
Now why do we always write this "dc=", i.e. why do we mention an attribute name? That is exactly the second difference to the dictionary: in LDAP we can fork not only "in one dimension" (imagine the tree printed on paper), but in arbitrary many dimensions, by explicitly giving an alternative attribute name.
Therefore, for example,
dc=e,cn=l,dc=p,dc=p,dc=p,dc=a
references yet another node than our original "apple". (If one would want to express it in a noble way, one would say: while references to nodes in the dictionary are solely based on a position-induced decoding of the attribute values, in LDAP the attribute name-to-value relations (_and_ their order) determine a node uniquely.)
The attribute naming allows us now to add a further twist to the usage of such a tree. As different attributes are constituing different kinds of objects, we could "first" set up a node with the meaning of an employee, and "then" refine this node by virtue of adding child nodes (with special attributes) to represent special employees, like faculty, administration, board member etc. In some sense we can thus implement some kind of object orientation/ inheritance with this tree. To make this aspect really going it is possible in LDAP to add further attributes to nodes without having them determine the reference of the node.
During all this single nodes will always be connected into a hierarchy of nodes, which will come in handy for manipulations on the tree.
Searches
Searches on the tree are always targetted to return a set of in some sense matching nodes, and of them to return only some again specifically specified attributes. Naturally therefore, a search will start "from" a root node, i.e. the search will have a scope only within the subtree "below" this node ("search dn").
Further, the nodes that are to be so filtered are specified via a pattern that is called "filter". Finally, the attributes that are to be retained from these result nodes are given in "attributes".
Thus a common ldap search might look like
ldapsearch -D "cn=admin,dc=example,dc=de" -W -x -b "o=MyOrganization,dc=example,dc=de" "cn=*"
or
get_ldap_values("cn=groups", "(cn=faculty)", array("memberUid"));
(Here '-D "cn=admin,dc=example,dc=de" -W -x' is authentication related, '-b binddn' denotes the search dn, and '"cn=*"' is the filter. All attributes are returned in this case. And in the second example, the declaration of the function is meant as 'get_ldap_values($searchdn, $filter, $justtheseattributes);'.)