Novell LINUX ENTERPRISE DESKTOP 11, Руководство пользователя

Страница: 52 / 450

Figure 4.1 Structure of an LDAP Directory
ou=devel
cn=Tux Linux cn=Geeko Linux
dc=example,dc=com
ou=doc ou=it
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 39) 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.
38 Security Guide