113
Chapter 9:
Exploring Directory Services
All the objects in a directory tree have attributes (sometimes called properties), which
vary depending on the type of object to which the attribute is attached. For example,
a printer leaf object might contain attributes that describe the printer, who can administer
the printer, what the printer's name is on the network, and so forth. A user account
leaf object might contain attributes that include the full name of the user account, its
password, and resources that the user can access. The details of what attributes attach
to what leaf or container objects vary among all the directory services, although they
generally use similar attributes.
Department of Redundancy Department
Keeping directory services running is essential for any network that relies on them.
Because they contain all details about accounts, resources, and security, the absence of
directory services means the network won't work--at all! Since the directory services
become so important to a network, you must protect them with some degree of
redundancy. As mentioned earlier, keeping duplicate copies of the directory on multiple
servers provides the necessary redundancy. This is done using one of two approaches:
In
the
primary/backup model, a single primary database contains the primary
(or "real") directory on one server, while other servers hold one or more backup
copies. If the primary copy stops working for some reason, the backups can
continue to provide directory services to the network without the user even
knowing that the primary copy isn't available. Windows NT domains use a
primary/backup approach.
In
the
multimaster model, multiple directory servers exist, but they are all peers
to one another. If one goes down, the other peers continue to operate normally.
The advantage of the multimaster model is that each directory server can fully
participate in doing the work of the directory service. Active Directory (in
Windows 2000 Server and later) uses the multimaster approach.
Directory servers--whether they use the primary/backup or multimaster
approach--must keep in sync with changes on the network. The separate databases
are kept synchronized through a process called replication, in which changes to any of
the individual directory databases are transparently updated to all the other directory
service databases.
A potential problem exists with any replication process, though: If two changes are
made to the same leaf object on two different directory servers and the changes
are different, what does the system do when the changes "collide" during replication?
The various directory services handle this problem in slightly different ways. In the
case of Novell eDirectory, the timestamps of the changes drive which of two conflicting
changes will win. (Because of this, servers running eDirectory must carefully keep
their time synchronized; this synchronization is also handled during replication.)
Microsoft's Active Directory doesn't use timestamps, but instead uses sequence
numbers in a clever scheme that avoids the potential problems of a timestamp approach.
(Even though eDirectory servers synchronize their time, their time can still become out
of sync between synchronizations.)