HP-UX Directory Server 8.1 deployment guide

all applications not using the directory can result in data being unsynchronized across the
enterprise (which is what the directory is supposed to prevent).
Master the data in some application other than the directory, then write scripts, programs,
or gateways to import that data into the directory.
Mastering data in non-directory applications makes the most sense if there are one or two
applications that are already used to master data, and the directory will be used only for
lookups (for example, for online corporate telephone books).
How master copies of the data are maintained depends on the specific directory needs. However,
regardless of how data masters are maintained, keep it simple and consistent. For example, do
not attempt to master data in multiple sites, then automatically exchange data between competing
applications. Doing so leads to a "last change wins" scenario and increases the administrative
overhead.
For example, the directory is going to manage an employee's home telephone number. Both the
LDAP directory and a human resources database store this information. The human resources
application is LDAP-enabled, so an application can be written that automatically transfers data
from the LDAP directory to the human resources database, and vice versa.
Attempting to master changes to that employee's telephone number in both the LDAP directory
and the human resources data, however, means that the last place where the telephone number
was changed overwrites the information in the other database. This is only acceptable as long
as the last application to write the data had the correct information.
If that information was out of date, perhaps because the human resources data were reloaded
from a backup, then the correct telephone number in the LDAP directory will be deleted.
With multi-mater replication, Directory Server can contain master sources of information on
more than one server. Multiple masters keep changelogs and can resolve conflicts more safely.
A limited number of Directory Server are considered masters which can accept changes; they
then replicate the data to replica servers, or consumer servers.
1
Having more than on data master
server provides safe failover in the event that a server goes off-line. For more information about
replication and multi-master replication, see Chapter 6 “Designing the replication process”.
Synchronization allows Directory Server users, groups, attributes, and passwords to be integrated
with Microsoft Active Directory users, groups, attributes, and passwords. With two directory
services, decide whether they will handle the same information, what amount of that information
will be shared, and which service will be the data master for that information. The best course
is to choose a single application to master the data and allow the synchronization process to add,
update, or delete the entries on the other service.
2.3.6 Determining data ownership
Data ownership refers to the person or organization responsible for making sure the data is
up-to-date. During the data design phase, decide who can write data to the directory. The
following are some common strategies for deciding data ownership:
Allow read-only access to the directory for everyone except a small group of directory content
managers.
Allow individual users to manage some strategic subset of information for themselves.
This subset of information might include their passwords, descriptive information about
themselves and their role within the organization, their automobile license plate number,
and contact information such as telephone numbers or office numbers.
Allow a person's manager to write to some strategic subset of that person's information,
such as contact information or job title.
1. In replication, a consumer server or replica server is a server that receives updates from a supplier server or hub
server.
22 Planning the directory data