Novell LINUX ENTERPRISE DESKTOP 11 - SECURITY GUIDE 17-03-2009 Manual page 44

Figure 4.1 Structure of an LDAP Directory
dc=example,dc=com
ou=devel ou=doc ou=it
cn=Tux Linux cn=Geeko Linux
The complete diagram is a fictional directory information tree. The entries on three
levels are depicted. Each entry corresponds to one box in the picture. The complete,
valid distinguished name for the fictional employee Geeko Linux, in this case, is
cn=Geeko Linux,ou=doc,dc=example,dc=com. It is composed by adding
the RDN cn=Geeko Linux to the DN of the preceding entry
ou=doc,dc=example,dc=com.
The types of objects that can be stored in the DIT are globally determined following a
Schema. The type of an object is determined by the object class. The object class deter-
mines what attributes the concerned object must or can be assigned. The Schema,
therefore, must contain definitions of all object classes and attributes used in the desired
application scenario. There are a few common Schemas (see RFC 2252 and 2256). The
LDAP RFC defines a few commonly used Schemas (see e.g., RFC4519). Additionally
there are Schemas available for many other use cases (e.g., Samba, NIS replacement,
etc.). It is, however, possible to create custom Schemas or to use multiple Schemas
complementing each other if this is required by the environment in which the LDAP
server should operate.
Table 4.1, "Commonly Used Object Classes and Attributes" (page 33) offers a small
overview of the object classes from core.schema and inetorgperson.schema
used in the example, including required attributes and valid attribute values.
32 Security Guide