Let us use an example to illustrate the concepts. Note that this section does not include any commands to do any task, just the concepts.
First, we need to decide what is the “realm” that the LDAP directory will serve. Let us assume that the realm (which is often the domain name) is test.org. Unlike Kerberos, LDAP has not convention to use uppercase letters for the realm.
The root entry of the LDAP tree represents the organization. We can use the following bare minimum:
First of all, the distinguished name ( dn:) separates components of the domain name into two attributes. Each dc attribute is a “domain component’.
This entry has to play by the rules of three object classes. The o attribute and dc attribute are required by one or more of the object classes.
Note that many additional attributes can be added to this entry, but they are not needed for our purpose.
The next mandatory entry is an entry for the LDAP administrator:
Note that the first line (distinguished name) has some common components as the previous entry. This is because this entry is read as “admin of test.org”. This entry is described by two object classes, and it has a mandatory attribute of cn (common name).
There two entries are mandatory in any LDAP tree intended for networked authentication. One entry is needed to contain all the users:
This entry uses ou as a part of its distinguished name. “ou” is an organizational unit, which means it is meant to be a container for other entries.
Similarly, we need another container entry for all the groups:
Then we need additional entries to represent items in /etc/passwd and /etc/group. Let’s say we have an end user with the username of newbie and a UID/GID of 10000/10000, This will be represented by two entries, one to represent the group, and one to represent the user. The group entry looks like the following
The most important part is the object class posixGroup, it requires the gidNumber and cn attributes. These are required in the file /etc/group, too.
We also need to create another entry to represent the user (information in /etc/passwd):
Again, we are leaving out some optional attributes, such as description and shadowExpire.
At this point, this LDAP tree can be used to provide log in data for one single user!
Remember that all this configuration is for LDAP only. You need to add a principle to Kerberos of the same realm to have all the pieces needed for remote authentication.