Red Hat DIRECTORY SERVER 8.1 - DEPLOYMENT, Directory Server 8.1 Deployment Manual

Red Hat Directory

Server 8.1

Deployment Guide

Ella Deon Lackey

Publication date: April 28, 2009, updated on September 9, 2009

Deployment Guide

Deployment Guide

Author Ella Deon Lackey
Copyright © 2009 Red Hat, Inc.

Copyright © 2009 Red Hat, Inc.. This material may only be distributed subject to the terms and
conditions set forth in the Open Publication License, V1.0 or later (the latest version of the OPL is
presently available at http://www.opencontent.org/openpub/).

Red Hat and the Red Hat "Shadow Man" logo are registered trademarks of Red Hat, Inc. in the United
States and other countries.

All other trademarks referenced herein are the property of their respective owners.

1801 Varsity Drive
Raleigh, NC 27606-2072 USA
Phone: [phone]
Phone: [phone]
Fax: [phone]
PO Box 13588 Research Triangle Park, NC 27709 USA

This manual covers the basic considerations that should be addressed before deploying Red Hat
Directory Server. The decisions made during this phase can have a significant and lasting affect
on the effectiveness, efficiency, and scalability of your Directory Server. You should have a good
understanding of your Directory Server requirements before moving on to the installation phase.

iii

Preface v

1. Directory Server Overview ............................................................................................... v

2. Examples and Formatting ................................................................................................ v

3. Additional Reading ......................................................................................................... vii

4. Giving Feedback ........................................................................................................... viii

5. Documentation History .................................................................................................. viii

1. Introduction to Directory Services 1

1.1. About Directory Services .............................................................................................. 1

1.2. Introduction to Directory Server ..................................................................................... 2

1.3. Directory Server Data Storage ...................................................................................... 5

1.4. Directory Design Overview ............................................................................................ 6

1.5. Other General Directory Resources ............................................................................... 8

2. Planning the Directory Data 9

2.1. Introduction to Directory Data ....................................................................................... 9

2.2. Defining Directory Needs ............................................................................................ 10

2.3. Performing a Site Survey ............................................................................................ 10

2.4. Documenting the Site Survey ...................................................................................... 17

2.5. Repeating the Site Survey .......................................................................................... 18

3. Designing the Directory Schema 19

3.1. Schema Design Process Overview .............................................................................. 19

3.2. Standard Schema ....................................................................................................... 19

3.3. Mapping the Data to the Default Schema .................................................................... 22

3.4. Customizing the Schema ............................................................................................ 24

3.5. Maintaining Consistent Schema .................................................................................. 30

3.6. Other Schema Resources ........................................................................................... 31

4. Designing the Directory Tree 33

4.1. Introduction to the Directory Tree ................................................................................ 33

4.2. Designing the Directory Tree ....................................................................................... 33

4.3. Grouping Directory Entries .......................................................................................... 44

4.4. Virtual Directory Information Tree Views ...................................................................... 47

4.5. Directory Tree Design Examples ................................................................................. 53

4.6. Other Directory Tree Resources .................................................................................. 55

5. Designing the Directory Topology 57

5.1. Topology Overview ..................................................................................................... 57

5.2. Distributing the Directory Data ..................................................................................... 57

5.3. About Knowledge References ..................................................................................... 61

5.4. Using Indexes to Improve Database Performance ........................................................ 71

6. Designing the Replication Process 75

6.1. Introduction to Replication ........................................................................................... 75

6.2. Common Replication Scenarios ................................................................................... 78

6.3. Defining a Replication Strategy ................................................................................... 86

6.4. Using Replication with Other Directory Server Features ................................................ 95

7. Designing Synchronization 99

7.1. Windows Synchronization Overview ............................................................................ 99

7.2. Planning Windows Synchronization ........................................................................... 100

7.3. Schema Elements Synchronized Between Active Directory and Directory Server ........... 105

8. Designing a Secure Directory 111

Deployment Guide

iv

8.1. About Security Threats ............................................................................................. 111

8.2. Analyzing Security Needs ......................................................................................... 112

8.3. Overview of Security Methods ................................................................................... 114

8.4. Selecting Appropriate Authentication Methods ............................................................ 115

8.5. Preventing Authentication by Account Deactivation ..................................................... 118

8.6. Designing a Password Policy .................................................................................... 118

8.7. Designing Access Control ......................................................................................... 125

8.8. Database Encryption ................................................................................................. 133

8.9. Securing Server to Server Connections ..................................................................... 134

8.10. Other Security Resources ....................................................................................... 134

9. Directory Design Examples 137

9.1. Design Example: A Local Enterprise .......................................................................... 137

9.2. Design Example: A Multinational Enterprise and Its Extranet ....................................... 143

v

Preface

The Red Hat Directory Server Deployment Guide provides a solid foundation on the on concepts
and configuration options for planning an effective directory service. The information provided here is
intended for both designers and administrators.

1. Directory Server Overview

Red Hat Directory Server provides the following key features:

• Multi-master replication — Provides a highly available directory service for both read and write
operations. Multi-master replication can be combined with simple and cascading replication
scenarios to provide a highly flexible and scalable replication environment.

• Chaining and referrals — Increases the power of the directory by storing a complete logical view
of the directory on a single server while maintaining data on a large number of Directory Servers
transparently for clients.

• Roles and classes of service — Provides a flexible mechanism for grouping and sharing attributes
between entries dynamically.

• Efficient access control mechanisms — Provides support for macros that dramatically reduce the
number of access control statements used in the directory and increase the scalability of access
control evaluation.

• Resource-limits by bind DN — Grants the power to control the amount of server resources allocated
to search operations based on the bind DN of the client.

• Multiple databases — Provides a simple way of breaking down the directory data to simplify the
implementation of replication and chaining in the directory service.

• Password policy and account lockout — Defines a set of rules that govern how passwords and user
accounts are managed in the Directory Server.

• TLS and SSL — Provides secure authentication and communication over the network, using the
Mozilla Network Security Services (NSS) libraries for cryptography.

The major components of Directory Server include the following:

• An LDAP server — The LDAP v3-compliant network daemon.

• Directory Server Console — A graphical management console that dramatically reduces the effort of
setting up and maintaining the directory service.

• SNMP agent — Can monitor the Directory Server using the Simple Network Management Protocol
(SNMP).

2. Examples and Formatting

Each of the examples used in this guide, such as file locations and commands, have certain defined
conventions.

Preface

vi

2.1. Command and File Examples

All of the examples for Red Hat Directory Server commands, file locations, and other usage are given
for Red Hat Enterprise Linux 5 (32-bit) systems. Be certain to use the appropriate commands and files
for your platform.

To start the Red Hat Directory Server:

service dirsv start

Example 1. Example Command

2.2. Tool Locations

The tools for Red Hat Directory Server are located in the /usr/bin and the /usr/sbin directories.
These tools can be run from any location without specifying the tool location.

2.3. LDAP Locations

There is another important consideration with the Red Hat Directory Server tools. The LDAP tools
referenced in this guide are Mozilla LDAP, installed with Red Hat Directory Server in the /usr/lib/
mozldap directory on Red Hat Enterprise Linux 5 (32-bit) (or /usr/lib64/mozldap for 64-bit
systems).

However, Red Hat Enterprise Linux systems also include LDAP tools from OpenLDAP in the /usr/
bin directory. It is possible to use the OpenLDAP commands as shown in the examples, but you must
use the -x argument to disable SASL, which OpenLDAP tools use by default.

2.4. Text Formatting and Styles

Certain words are represented in different fonts, styles, and weights. Different character formatting is
used to indicate the function or purpose of the phrase being highlighted.

Formatting Style Purpose

Monospace font Monospace is used for commands, package

names, files and directory paths, and any text
displayed in a prompt.

Monospace
with a
background

This type of formatting is used for anything
entered or returned in a command prompt.

Italicized text Any text which is italicized is a variable, such

as instance_name or hostname. Occasionally,
this is also used to emphasize a new term or
other phrase.

Bolded text Most phrases which are in bold are application

names, such as Cygwin, or are fields or
options in a user interface, such as a User
Name Here: field or Save button.

Other formatting styles draw attention to important text.

Additional Reading

vii

NOTE

A note provides additional information that can help illustrate the behavior of the system or
provide more detail for a specific issue.

IMPORTANT

Important information is necessary, but possibly unexpected, such as a configuration
change that will not persist after a reboot.

WARNING

A warning indicates potential data loss, as may happen when tuning hardware for
maximum performance.

3. Additional Reading

The Directory Server Administrator's Guide describes how to set up, configure, and administer Red
Hat Directory Server and its contents. this manual does not describe many of the basic directory and
architectural concepts that you need to deploy, install, and administer a directory service successfully.
Those concepts are contained in the Red Hat Directory Server Deployment Guide. You should read
that book before continuing with this manual.

When you are familiar with Directory Server concepts and have done some preliminary planning for
your directory service, install the Directory Server. The instructions for installing the various Directory
Server components are contained in the Red Hat Directory Server Installation Guide. Many of the
scripts and commands used to install and administer the Directory Server are explained in detail in the
Red Hat Directory Server Configuration, Command, and File Reference.

Also, Managing Servers with Red Hat Console contains general background information on how to
use the Red Hat Console. You should read and understand the concepts in that book before you
attempt to administer Directory Server.

The document set for Directory Server contains the following guides:

• Red Hat Directory Server Release Notes contain important information on new features, fixed bugs,
known issues and workarounds, and other important deployment information for this specific version
of Directory Server.

• Red Hat Directory Server Deployment Guide provides an overview for planning a deployment of the
Directory Server.

• Red Hat Directory Server Administrator's Guide contains procedures for the day-to-day maintenance
of the directory service. Includes information on configuring server-side plug-ins.

• Red Hat Directory Server Configuration, Command, and File Reference provides reference
information on the command-line scripts, configuration attributes, and log files shipped with
Directory Server.

• Red Hat Directory Server Installation Guide contains procedures for installing your Directory Server
as well as procedures for migrating from a previous installation of Directory Server.

Preface

viii

• Red Hat Directory Server Schema Reference provides reference information about the Directory
Server schema.

• Red Hat Directory Server Plug-in Programmer's Guide describes how to write server plug-ins in
order to customize and extend the capabilities of Directory Server.

• Using Red Hat Console gives an overview of the primary user interface and how it interacts with
the Directory Server and Administration Server, as well as how to perform basic management tasks
through the main Console window.

• Using the Admin Server describes the different tasks and tools associated with the Administration
Server and how to use the Administration Server with the Configuration and User Directory Server
instances.

For the latest information about Directory Server, including current release notes, complete product
documentation, technical notes, and deployment information, see the Red Hat Directory Server
documentation site at http://www.redhat.com/docs/manuals/dir-server/.

4. Giving Feedback

If there is any error in this Deployment Guide or there is any way to improve the documentation,
please let us know. Bugs can be filed against the documentation for Red Hat Directory Server through
Bugzilla, http://bugzilla.redhat.com/bugzilla. Make the bug report as specific as possible, so we can be
more effective in correcting any issues:

• Select the Red Hat Directory Server product.

• Set the component to Doc - deployment-guide.

• Set the version number to 8.1.

• For errors, give the page number (for the PDF) or URL (for the HTML), and give a succinct
description of the problem, such as incorrect procedure or typo.

For enhancements, put in what information needs to be added and why.

• Give a clear title for the bug. For example, "Incorrect command example for setup
script options" is better than "Bad example".

We appreciate receiving any feedback — requests for new sections, corrections, improvements,
enhancements, even new ways of delivering the documentation or new styles of docs. You are
welcome to contact Red Hat Content Services directly at [e-mail]1.

5. Documentation History

Revision 8.1.2 September 9, 2009 Ella Deon Lackey

Removing any references to the Directory Server Gateway or Org Chart.

Revision 8.1.1 April 28, 2009 Ella Deon Lackey [e-mail]

1

mailto:[e-mail]

Documentation History

ix

Spellchecking and correcting typo, per Bugzilla #516693.

Revision 8.1.0 April 28, 2009 Ella Deon Lackey [e-mail]

Initial draft for version 8.1.

x

Chapter 1.

1

Introduction to Directory Services

Red Hat Directory Server provides a centralized directory service for an intranet, network, and extranet
information. Directory Server integrates with existing systems and acts as a centralized repository for
the consolidation of employee, customer, supplier, and partner information. Directory Server can even
be extended to manage user profiles, preferences, and authentication.

This chapter describes the basic ideas and concepts for understanding what a directory service does
to help begin designing the directory service.

1.1. About Directory Services

The term directory service refers to the collection of software, hardware, and processes that store
information about an enterprise, subscribers, or both, and make that information available to users. A
directory service consists of at least one instance of Directory Server and at least one directory client
program. Client programs can access names, phone numbers, addresses, and other data stored in the
directory service.

An example of a directory service is a domain name system (DNS) server. A DNS server maps
computer hostnames to IP addresses. Thus, all of the computing resources (hosts) become clients of
the DNS server. Mapping hostnames allows users of computing resources to easily locate computers
on a network by remembering hostnames rather than IP addresses. A limitation of a DNS server is
that it stores only two types of information: names and IP addresses. A true directory service stores
virtually unlimited types of information.

Directory Server stores all user and network information in a single, network-accessible repository.
Many kinds of different information can be stored in the Directory Server:

• Physical device information, such as data about the printers in an organization, such as location,
color or black and white, manufacturer, date of purchase, and serial number.

• Public employee information, such as name, email address, and department.

• Private employee information, such as salary, government identification numbers, home addresses,
phone numbers, and pay grade.

• Contract or account information, such as the name of a client, final delivery date, bidding
information, contract numbers, and project dates.

Directory Server serves the needs of a wide variety of applications. It also provides a standard
protocol and application programming interfaces (APIs) to access the information it contains.

1.1.1. About Global Directory Services

Directory Server provides global directory services, which means that it provides information to a wide
variety of applications. Rather than attempting to unify proprietary databases bundled with different
applications, which is an administrative burden, Directory Server is a single solution to manage the
same information.

For example, a company is running three different proprietary email systems, each with its own
proprietary directory service. If users change their passwords in one directory, the changes are not
automatically replicated in the others. Managing multiple instances of the same information results in

Chapter 1. Introduction to Directory Services

2

increased hardware and personnel costs; the increased maintenance overhead is referred to as the n
+1 directory problem.

A global directory service solves the n+1 directory problem by providing a single, centralized
repository of directory information that any application can access. However, giving a wide variety
of applications access to the directory service requires a network-based means of communicating
between the applications and the directory service. Directory Server uses LDAP for applications to
access to its global directory service.

1.1.2. About LDAP

LDAP provides a common language that client applications and servers use to communicate with one
another. LDAP is a "lightweight" version of the Directory Access Protocol (DAP) described by the ISO
X.500 standard. DAP gives any application access to the directory through an extensible and robust
information framework but at a high administrative cost. DAP uses a communications layer that is not
the Internet standard protocol and has complex directory-naming conventions.

LDAP preserves the best features of DAP while reducing administrative costs. LDAP uses an open
directory access protocol running over TCP/IP and simplified encoding methods. It retains the
data model and can support millions of entries for a modest investment in hardware and network
infrastructure.

1.2. Introduction to Directory Server

Red Hat Directory Server includes the directory itself, the server-side software that implements the
LDAP protocol, and a client-side graphical user interface that allows end-users to search and change
entries in the directory. Other LDAP clients, both third-party programs and custom programs written
using the LDAP client SDK, both the Mozilla LDAP SDK and the OpenLDAP SDK.

Without adding other LDAP client programs, Directory Server can provide the foundation for an
intranet or extranet. Every Directory Server and compatible server applications use the directory as
a central repository for shared server information, such as employee, customer, supplier, and partner
data.

Directory Server can manage user authentication, create access control, set up user preferences, and
centralize user management. In hosted environments, partners, customers, and suppliers can manage
their own portions of the directory, reducing administrative costs.

When Directory Server is installed and set up, the following components are installed:

• The core Directory Server LDAP server, the LDAP v3-compliant network daemon (ns-slapd) and
all of the associated plug-ins, command-line tools for managing the server and its databases, and
its configuration and schema files. For more information about the command-line tools, see the
Directory Server Configuration, Command, and File Reference.

• Administration Server, a web server which controls the different portals that access the LDAP
server. For more information about the Administration Server, see Using the Admin Server.

• Directory Server Console, a graphical management console that dramatically reduces the effort of
setting up and maintaining the directory service. For more information about the Directory Server
Console, see Using Red Hat Console.

Overview of the Server Frontend

3

• SNMP agent to monitor the Directory Server using the Simple Network Management Protocol
(SNMP). For more information about SNMP monitoring, see the Directory Server Administrator's
Guide.

1.2.1. Overview of the Server Frontend

Directory Server is a multi-threaded application. This means that multiple clients can bind to the server
at the same time over the same network. As directory services grow to include larger numbers of
entries or geographically-dispersed clients, they also include multiple Directory Servers placed in
strategic places around the network.

The server frontend of Directory Server manages communications with directory client programs.
Multiple client programs can communicate with the server using both LDAP over TCP/IP (Internet
traffic protocols) and LDAP over Unix sockets (LDAPI). The Directory Server can establish a secure
(encrypted) connection with SSL/TLS, depending on whether the client negotiates the use of Transport
Layer Security (TLS) for the connection.

When communication takes place with TLS, the communication is usually encrypted. If clients have
been issued certificates, TLS/SSL can be used by Directory Server to confirm that the client has the
right to access the server. TLS/SSL is used to perform other security activities, such as message
integrity checks, digital signatures, and mutual authentication between servers.

NOTE

Directory Server runs as a daemon; the process is ns-slapd.

1.2.2. Server Plug-ins Overview

Directory Server relies on plug-ins to add functionality to the core server. For example, a database
layer is a plug-in. Directory Server has plug-ins for replication, chaining databases, and other different
directory functions.

Generally, a plug-in can be disabled, particularly plug-ins the extend the server functionality. When
disabled, the plug-in's configuration information remains in the directory, but its function is not used
by the server. Depending on what the directory is supposed to do, any of the plug-ins provided with
Directory Server can be enabled to extend the Directory Server functionality. (Plug-ins related to the
core directory service operations, like backend database plug-in, naturally cannot be disabled.)

For more information on the default plug-ins with Directory Server and the functions available for
writing custom plug-ins, see the Directory Server Plug-in Programmer's Guide.

1.2.3. Overview of the Basic Directory Tree

The directory tree, also known as a directory information tree (DIT), mirrors the tree model used
by most file systems, with the tree's root, or first entry, appearing at the top of the hierarchy. During
installation, Directory Server creates a default directory tree.

Chapter 1. Introduction to Directory Services

4

Figure 1.1. Layout of Default Directory Server Directory Tree

The root of the tree is called the root suffix. For information about naming the root suffix, see

Section 4.2.1, “Choosing a Suffix”.

After a standard installation, the directory contains three subtrees under the root suffix:

• cn=config, the subtree containing information about the server's internal configuration.

• o=NetscapeRoot, the subtree containing the configuration information of the Directory Server and
Administration Server.

NOTE

When additional instances of Directory Server are installed, they can be configured not
to have an o=NetscapeRoot database; in that case, the instances use a configuration

directory (or the o=NetscapeRoot subtree) on another server. See the Directory
Server Installation Guide for more information about choosing the location of the

configuration directory.

• cn=monitor, the subtree containing Directory Server server and database monitoring statistics.

• cn=schema, the subtree containing the schema elements currently loaded in the server.

• user_suffix, the suffix for the default user database created when the Directory Server is setup. The
name of the suffix is defined by the user when the server is created; the name of the associated
database is userRoot. The database can be populated with entries by importing an LDIF file at
setup or entries can be added to it later.

The user_suffix suffix frequently has a dc naming convention, like dc=example,dc=com.
Another common naming attribute is the o attribute, which is used for an entire organization, like
o=example.com.

The default directory tree can be extended to add any data relevant to the directory installation. For
more information about directory trees, see Chapter 4, Designing the Directory Tree.

Directory Server Data Storage

5

Figure 1.2. Expanded Directory Tree for Example Corp.

1.3. Directory Server Data Storage

The database is the basic unit of storage, performance, replication, and indexing. All Directory Server
operations — importing, exporting, backing up, restoring, and indexing entries — are performed on the
database. Directory data are stored in an LDBM database. The LDBM database is implemented as a
plug-in that is automatically installed with the directory and is enabled by default.

By default, Directory Server uses one backend database instance for a root suffix, and, by default,
there are two databases, o=NetscapeRoot for configuration entries and userRoot for directory
entries. A single database is sufficient to contain the directory tree. This database can manage millions
of entries.

This database supports advanced methods of backing up and restoring data, in order to minimize risk
to data.

NOTE

For database files that are larger than 2 gigabytes, 32-bit HP-UX machines must be
configured to support large files. Use the vxfs file system and set the largefiles option
to on.

Multiple databases can be used to support the whole Directory Server deployment. Information is
distributed across the databases, allowing the server to hold more data than can be stored in a single
database.

1.3.1. About Directory Entries

LDAP Data Interchange Format (LDIF) is a standard text-based format for describing directory
entries. An entry consists of a number of lines in the LDIF file (also called a stanza), which contains
information about an object, such as a person in the organization or a printer on the network.

Information about the entry is represented in the LDIF file by a set of attributes and their values. Each
entry has an object class attribute that specifies the kind of object the entry describes and defines the
set of additional attributes it contains. Each attribute describes a particular trait of an entry.

Chapter 1. Introduction to Directory Services

6

For example, an entry might be of object class organizationalPerson, indicating that the
entry represents a person within an organization. This object class supports the givenname and
telephoneNumber attributes. The values assigned to these attributes give the name and phone
number of the person represented by the entry.

Directory Server also uses read-only attributes that are calculated by the server. These attributes are
called operational attributes. The administrator can manually set operational attributes that can be
used for access control and other server functions.

1.3.1.1. Performing Queries on Directory Entries

Entries are stored in a hierarchical structure in the directory tree. LDAP supports tools that query the
database for an entry and request all entries below it in the directory tree. The root of this subtree is
called the base distinguished name, or base DN. For example, if performing an LDAP search request
specifying a base DN of ou=people, dc=example,dc=com, then the search operation examines
only the ou=people subtree in the dc=example,dc=com directory tree.

Not all entries are automatically returned in response to an LDAP search, however, because
administrative entries (which have the ldapsubentry object class) are not returned by default with
LDAP searches. Administrative object, for example, can be entries used to define a role or a class of
service. To include these entries in the search response, clients need to search specifically for entries
with the ldapsubentry object class. See Section 4.3.1, “About Roles” for more information about
roles and Section 4.3.3, “About Class of Service” for more information about class of service.

1.3.2. Distributing Directory Data

When various parts of the directory tree are stored in separate databases, the directory can process
client requests in parallel, which improves performance. The databases can even be located on
different machines to further improve performance.

Distributed data are connected by a special entry in a subtree of the directory, called a database link,
which point to data stored remotely. When a client application requests data from a database link,
the database link retrieves the data from the remote database and returns it to the client. All LDAP
operations attempted below this entry are sent to the remote machine. This method is called chaining.

Chaining is implemented in the server as a plug-in, which is enabled by default.

1.4. Directory Design Overview

Planning the directory service before actual deployment is the most important task to ensure the
success of the directory. The design process involves gathering data about the directory requirements,
such as environment and data sources, users, and the applications that use the directory. This
information is integral to designing an effective directory service because it helps identify the
arrangement and functionality required.

The flexibility of Directory Server means the directory design can be reworked to meet unexpected or
changing requirements, even after the Directory Server is deployed.

1.4.1. Design Process Outline

1. Chapter 2, Planning the Directory Data

The directory contains data such as user names, telephone numbers, and group details. This
chapter analyzes the various sources of data in the organization and understand their relationship

Deploying the Directory

7

with one another. It describes the types of data that can be stored in the directory and other tasks
to perform to design the contents of the Directory Server.

2. Chapter 3, Designing the Directory Schema

The directory is designed to support one or more directory-enabled applications. These
applications have requirements of the data stored in the directory, such as the file format. The
directory schema determines the characteristics of the data stored in the directory. The standard
schema shipped with Directory Server is introduced in this chapter, as well as a description of how
to customize the schema and tips for maintaining a consistent schema.

3. Chapter 4, Designing the Directory Tree

Along with determining what information is contained in the Directory Server, it is important to
determine how that information is going to be organized and referenced. This chapter introduces
the directory tree and gives an overview of the design of the data hierarchy. Sample directory tree
designs are also provided.

4. Chapter 5, Designing the Directory Topology

Topology design means how the directory tree is divided among multiple physical Directory
Servers and how these servers communicate with one another. The general principles behind
design, using multiple databases, the mechanisms available for linking the distributed data
together, and how the directory itself keeps track of distributed data are all described in this
chapter.

5. Chapter 6, Designing the Replication Process

When replication is used, multiple Directory Servers maintain the same directory data to increase
performance and provide fault tolerance. This chapter describes how replication works, what kinds
of data can be replicated, common replication scenarios, and tips for building a high-availability
directory service.

6. Chapter 7, Designing Synchronization

The information stored in the Red Hat Directory Server can by synchronized with information
stored in Microsoft Active Directory databases for better integration with a mixed-platform
infrastructure. This chapter describes how synchronization works, what kinds of data can be
synched, and considerations for the type of information and locations in the directory tree which
are best for synchronization.

7. Chapter 8, Designing a Secure Directory

Finally, plan how to protect the data in the directory and design the other aspects of the service
to meet the security requirements of the users and applications. This chapter covers common
security threats, an overview of security methods, the steps involved in analyzing security needs,
and tips for designing access controls and protecting the integrity of the directory data.

1.4.2. Deploying the Directory

The first step to deploying the Directory Server is installing a test server instance to make sure the
service can handle the user load. If the service is not adequate in the initial configuration, adjust the
design and test it again. Adjust the design until it is a robust service that you can confidently introduce
to the enterprise.

Chapter 1. Introduction to Directory Services

8

For a comprehensive overview of creating and implementing a directory pilot, see Understanding and
Deploying LDAP Directory Services (T. Howes, M. Smith, G. Good, Macmillan Technical Publishing,

1999).

After creating and tuning a successful test Directory Server instance, develop a plan to move the
directory service to production which covers the following considerations:

• An estimate of the required resources

• A schedule of what needs to be accomplished and when

• A set of criteria for measuring the success of the deployment

See the Directory Server Installation Guide for information on installing the directory service and the
Directory Server Administrator's Guide for information on administering and maintaining the directory.

1.5. Other General Directory Resources

The following publications have very detailed and useful information about directories, LDAP, and
LDIF:

• RFC 2849: The LDAP Data Interchange Format (LDIF) Technical Specification, http://www.ietf.org/

rfc/rfc2849.txt

• RFC 2251: Lightweight Directory Access Protocol (v3), http://www.ietf.org/rfc/rfc2251.txt

• Understanding and Deploying LDAP Directory Services. T. Howes, M. Smith, G. Good, Macmillan
Technical Publishing, 1999.

All of the Red Hat Directory Server documentation, available at http://redhat.com/docs/manuals/dir-

server, also contain high-level concepts about using LDAP and managing directory services, as well

as Directory Server-specific information.

Chapter 2.

9

Planning the Directory Data

The data stored in the directory may include user names, email addresses, telephone numbers, and
information about groups users are in, or it may contain other types of information. The type of data in
the directory determines how the directory is structured, who is given access to the data, and how this
access is requested and granted.

This chapter describes the issues and strategies behind planning the directory's data.

2.1. Introduction to Directory Data

Some types of data are better suited to the directory than others. Ideal data for a directory has some of
the following characteristics:

• It is read more often than written.

• It is expressible in attribute-data format (for example, surname=jensen).

• It is of interest to more than one person or group. For example, an employee's name or the physical
location of a printer can be of interest to many people and applications.

• It will be accessed from more than one physical location.

For example, an employee's preference settings for a software application may not seem to be
appropriate for the directory because only a single instance of the application needs access to the
information. However, if the application is capable of reading preferences from the directory and users
might want to interact with the application according to their preferences from different sites, then it is
very useful to include the preference information in the directory.

2.1.1. Information to Include in the Directory

Any descriptive or useful information about a person or asset can be added to an entry as an attribute.
For example:

• Contact information, such as telephone numbers, physical addresses, and email addresses.

• Descriptive information, such as an employee number, job title, manager or administrator
identification, and job-related interests.

• Organization contact information, such as a telephone number, physical address, administrator
identification, and business description.

• Device information, such as a printer's physical location, type of printer, and the number of pages
per minute that the printer can produce.

• Contact and billing information for a corporation's trading partners, clients, and customers.

• Contract information, such as the customer's name, due dates, job description, and pricing
information.

• Individual software preferences or software configuration information.

• Resource sites, such as pointers to web servers or the file system of a certain file or application.

Chapter 2. Planning the Directory Data

10

Using the Directory Server for more than just server administration requires planning what other types
of information to store in the directory. For example:

• Contract or client account details

• Payroll data

• Physical device information

• Home contact information

• Office contact information for the various sites within the enterprise

2.1.2. Information to Exclude from the Directory

Red Hat Directory Server is excellent for managing large quantities of data that client applications
read and write, but it is not designed to handle large, unstructured objects, such as images or other
media. These objects should be maintained in a file system. However, the directory can store pointers
to these kinds of applications by using pointer URLs to FTP, HTTP, and other sites.

2.2. Defining Directory Needs

When designing the directory data, think not only of the data that is currently required but also how the
directory (and organization) is going to change over time. Considering the future needs of the directory
during the design process influences how the data in the directory are structured and distributed.

Look at these points:

• What should be put in the directory today?

• What immediate problem is solved by deploying a directory?

• What are the immediate needs of the directory-enabled application being used?

• What information is going to be added to the directory in the near future? For example, an enterprise
might use an accounting package that does not currently support LDAP but will be LDAP-enabled in
a few months. Identify the data used by LDAP-compatible applications, and plan for the migration of
the data into the directory as the technology becomes available.

• What information might be stored in the directory in the future? For example, a hosting company
may have future customers with different data requirements than their current customers, such as
needing to store images or media files. While this is the hardest answer to anticipate, doing so may
pay off in unexpected ways. At a minimum, this kind of planning helps identify data sources that
might not otherwise have been considered.

2.3. Performing a Site Survey

A site survey is a formal method for discovering and characterizing the contents of the directory.
Budget plenty of time for performing a site survey, as preparation is the key to the directory
architecture. The site survey consists of a number of tasks:

• Identify the applications that use the directory.

Determine the directory-enabled applications deployed across the enterprise and their data needs.

Identifying the Applications That Use the Directory

11

• Identify data sources.

Survey the enterprise and identify sources of data, such as Active Directory, other LDAP servers,
PBX systems, human resources databases, and email systems.

• Characterize the data the directory needs to contain.

Determine what objects should be present in the directory (for example, people or groups) and what
attributes of these objects to maintain in the directory (such as usernames and passwords).

• Determine the level of service to provide.

Decide how available the directory data needs to be to client applications, and design the
architecture accordingly. How available the directory needs to be affects how data are replicated and
how chaining policies are configured to connect data stored on remote servers.

See Chapter 6, Designing the Replication Process for more information about replication and

Section 5.1, “Topology Overview” for more information on chaining.

• Identify a data master.

A data master contains the primary source for directory data. This data might be mirrored to other
servers for load balancing and recovery purposes. For each piece of data, determine its data
master.

• Determine data ownership.

For each piece of data, determine the person responsible for ensuring that the data is up-to-date.

• Determine data access.

If data are imported from other sources, develop a strategy for both bulk imports and incremental
updates. As a part of this strategy, try to master data in a single place, and limit the number of
applications that can change the data. Also, limit the number of people who write to any given piece
of data. A smaller group ensures data integrity while reducing the administrative overhead.

• Document the site survey.

Because of the number of organizations that can be affected by the directory, it may be helpful to
create a directory deployment team that includes representatives from each affected organization to
perform the site survey.

Corporations generally have a human resources department, an accounting or accounts receivable
department, manufacturing organizations, sales organizations, and development organizations.
Including representatives from each of these organizations can help the survey process. Furthermore,
directly involving all the affected organizations can help build acceptance for the migration from local
data stores to a centralized directory.

2.3.1. Identifying the Applications That Use the Directory

Generally, the applications that access the directory and the data needs of these applications drive the
planning of the directory contents. Many common applications use the directory:

Chapter 2. Planning the Directory Data

12

•

Directory browser applications, such as online telephone books. Decide what information (such
as email addresses, telephone numbers, and employee name) users need, and include it in the
directory.

•

Email applications, especially email servers. All email servers require email addresses, user
names, and some routing information to be available in the directory. Others, however, require
more advanced information such as the place on disk where a user's mailbox is stored, vacation
notification information, and protocol information (IMAP versus POP, for example).

• Directory-enabled human resources applications. These require more personal information such as
government identification numbers, home addresses, home telephone numbers, birth dates, salary,
and job title.

• Microsoft Active Directory. Through Windows User Sync, Windows directory services can
be integrated to function in tandem with the Directory Server. Both directories can store user
information (user names and passwords, email addresses, telephone numbers) and group
information (members). Style the Directory Server deployment after the existing Windows server
deployment (or vice versa) so that the users, groups, and other directory data can be smoothly
synchronized.

When examining the applications that will use the directory, look at the types of information each
application uses. The following table gives an example of applications and the information used by
each:

Application Class of Data Data

Phonebook People Name, email address, phone

number, user ID, password,
department number, manager,
mail stop.

Web server People, groups User ID, password, group name,

groups members, group owner.

Calendar server People, meeting rooms Name, user ID, cube number,

conference room name.

Table 2.1. Example Application Data Needs

After identifying the applications and information used by each application, it is apparent that some
types of data are used by more than one application. Performing this kind of exercise during the data
planning stage can help to avoid data redundancy problems in the directory, and show more clearly
what data directory-dependent applications require.

The final decision about the types of data maintained in the directory and when the information is
migrated to the directory is affected by these factors:

• The data required by various legacy applications and users

• The ability of legacy applications to communicate with an LDAP directory

2.3.2. Identifying Data Sources

To identify all of the data to include in the directory, perform a survey of the existing data stores. The
survey should include the following:

• Identify organizations that provide information.

Characterizing the Directory Data

13

Locate all the organizations that manage information essential to the enterprise. Typically, this
includes the information services, human resources, payroll, and accounting departments.

• Identify the tools and processes that are information sources.

Some common sources for information are networking operating systems (Windows, Novell
Netware, UNIX NIS), email systems, security systems, PBX (telephone switching) systems, and
human resources applications.

• Determine how centralizing each piece of data affects the management of data.

Centralized data management can require new tools and new processes. Sometimes centralization
requires increasing staff in some organizations while decreasing staff in others.

During the survey, consider developing a matrix that identifies all of the information sources in the
enterprise, similar to Table 2.2, “ Example Information Sources”:

Data Source Class of Data Data

Human resources database People Name, address, phone number,

department number, manager.

Email system People, Groups Name, email address, user ID,

password, email preferences.

Facilities system Facilities Building names, floor names,

cube numbers, access codes.

Table 2.2. Example Information Sources

2.3.3. Characterizing the Directory Data

All of the data identified to include in the directory can be characterized according to the following
general points:

• Format

• Size

• Number of occurrences in various applications

• Data owner

• Relationship to other directory data

Study each kind of data to include in the directory to determine what characteristics it shares with the
other pieces of data. This helps save time during the schema design stage, described in more detail in

Chapter 3, Designing the Directory Schema.

A good idea is to use a table, similar to Table 2.3, “Directory Data Characteristics”, which characterizes
the directory data.

Data Format Size Owner Related to

Employee Name Text string 128 characters Human resources User's entry

Fax number Phone number 14 digits Facilities User's entry

Chapter 2. Planning the Directory Data

14

Data Format Size Owner Related to

Email address Text Many character IS department User's entry

Table 2.3. Directory Data Characteristics

2.3.4. Determining Level of Service

The level of service provided depends on the expectations of the people who rely on directory-enabled
applications. To determine the level of service each application expects, first determine how and when
the application is used.

As the directory evolves, it may need to support a wide variety of service levels, from production to
mission critical. It can be difficult raising the level of service after the directory is deployed, so make
sure the initial design can meet the future needs.

For example, if the risk of total failure must be eliminated, use a multi-master configuration, where
several suppliers exist for the same data.

2.3.5. Considering a Data Master

A data master is a server that is the master source of data. Any time the same information is stored
in multiple locations, the data integrity can be degraded. A data master makes sure all information
stored in multiple locations is consistent and accurate. There are several scenarios that require a data
master:

• Replication among Directory Servers

• Synchronization between Directory Server and Active Directory

• Independent client applications which access the Directory Server data

Consider the master source of the data if there are applications that communicate indirectly with the
directory. Keep the processes for changing data, and the places from which the data can be changed,
as simple as possible. After deciding on a single site to master a piece of data, use the same site to
master all of the other data contained there. A single site simplifies troubleshooting if the databases
lose synchronization across the enterprise.

There are different ways to implement data mastering:

• Master the data in both the directory and all applications that do not use the directory.

Maintaining multiple data masters does not require custom scripts for moving data in and out of the
directory and the other applications. However, if data changes in one place, someone has to change
it on all the other sites. Maintaining master data in the directory and 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, and 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).

Determining Data Ownership

15

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.

• Allow an organization's administrator to create and manage entries for that organization.

1

In replication, a consumer server or replica server is a server that receives updates from a supplier server or hub server.

Chapter 2. Planning the Directory Data

16

This approach allows an organization's administrators to function as the directory content managers.

• Create roles that give groups of people read or write access privileges.

For example, there can be roles created for human resources, finance, or accounting. Allow each
of these roles to have read access, write access, or both to the data needed by the group. This
could include salary information, government identification numbers, and home phone numbers and
address.

For more information about roles and grouping entries, see Section 4.3, “Grouping Directory

Entries”.

There may be multiple individuals who need to have write access to the same information. For
example, an information systems (IS) or directory management group probably requires write access
to employee passwords. It may also be desirable for employees themselves to have write access to
their own passwords. While, generally, multiple people will have write access to the same information,
try to keep this group small and easy to identify. Keeping the group small helps ensure data integrity.

For information on setting access control for the directory, see Chapter 8, Designing a Secure

Directory.

2.3.7. Determining Data Access

After determining data ownership, decide who can read each piece of data. For example, employees'
home phone numbers can be stored in the directory. This data may be useful for a number of
organizations, including the employee's manager and human resources. Employees should be able to
read this information for verification purposes. However, home contact information can be considered
sensitive, so it probably should not be widely available across the enterprise.

For each piece of information stored in the directory, decide the following:

•

Can the data be read anonymously?

The LDAP protocol supports anonymous access and allows easy lookups for common information
such as office sites, email addresses, and business telephone numbers. However, anonymous
access gives anyone with access to the directory access to the common information. Consequently,
use anonymous access sparingly.

• Can the data be read widely across the enterprise?

Access control can be set so that the client must log into (or bind to) the directory to read specific
information. Unlike anonymous access, this form of access control ensures that only members of
the organization can view directory information. It also captures login information in the directory's
access log so there is a record of who accessed the information.

For more information about access controls, see Section 8.7, “Designing Access Control”.

• Is there an identifiable group of people or applications that need to read the data?

Anyone who has write privileges to the data generally also needs read access (with the exception of
write access to passwords). There may also be data specific to a particular organization or project
group. Identifying these access needs helps determine what groups, roles, and access controls the
directory needs.

Documenting the Site Survey

17

For information about groups and roles, see Chapter 4, Designing the Directory Tree. For
information about access controls, see Section 8.7, “Designing Access Control”.

Making these decisions for each piece of directory data defines a security policy for the directory.
These decisions depend upon the nature of the site and the kinds of security already available
at the site. For example, having a firewall or no direct access to the Internet means it is safer to
support anonymous access than if the directory is placed directly on the Internet. Additionally, some
information may only need access controls and authentication measures to restrict access adequately;
other sensitive information may need to be encrypted within the database as it is stored.

In many countries, data protection laws govern how enterprises must maintain personal information
and restrict who has access to the personal information. For example, the laws may prohibit
anonymous access to addresses and phone numbers or may require that users have the ability to
view and correct information in entries that represent them. Be sure to check with the organization's
legal department to ensure that the directory deployment follows all necessary laws for the countries in
which the enterprise operates.

The creation of a security policy and the way it is implemented is described in detail in Chapter 8,

Designing a Secure Directory.

2.4. Documenting the Site Survey

Because of the complexity of data design, document the results of the site surveys. Each step of the
site survey can use simple tables to track data. Consider building a master table that outlines the
decisions and outstanding concerns. A good tip is to use a spreadsheet so that the table's contents
can easily be sorted and searched.

Table 2.4, “Example: Tabulating Data Ownership and Access” identifies data ownership and data

access for each piece of data identified by the site survey.

Data Name Owner Supplier

Server/
Application

Self Read/
Write

Global
Read

HR
Writable

IS Writable

Employee
name

HR PeopleSoft Read-only Yes

(anonymous)

Yes Yes

User
password

IS Directory

US-1

Read/Write No No Yes

Home
phone
number

HR PeopleSoft Read/Write No Yes No

Employee
location

IS Directory

US-1

Read-only Yes (must

log in)

No Yes

Office
phone
number

Facilities Phone

switch

Read-only Yes

(anonymous)

No No

Table 2.4. Example: Tabulating Data Ownership and Access

Each row in the table shows what kind of information is being assessed, what departments have
an interest in it, and how the information is used and accessed. For example, on the first row, the
employee names data have the following management considerations:

Chapter 2. Planning the Directory Data

18

• Owner. Human Resources owns this information and therefore is responsible for updating and
changing it.

• Supplier Server/Application. The PeopleSoft application manages employee name information.

• Self Read/Write. A person can read his own name but not write (or change) it.

• Global Read. Employee names can be read anonymously by everyone with access to the directory.

• HR Writable. Members of the human resources group can change, add, and delete employee
names in the directory.

• IS Writable. Members of the information services group can change, add, and delete employee
names in the directory.

2.5. Repeating the Site Survey

There may need to be more than one site survey, particularly if an enterprise has offices in multiple
cities or countries. The informational needs might be so complex that several different organizations
have to keep information at their local offices rather than at a single, centralized site.

In this case, each office that keeps a master copy of information should perform its own site survey.
After the site survey process has been completed, the results of each survey should be returned to
a central team (probably consisting of representatives from each office) for use in the design of the
enterprise-wide data schema model and directory tree.

Chapter 3.

19

Designing the Directory Schema

The site survey conducted in Chapter 2, Planning the Directory Data revealed information about
the data which will be stored in the directory. The directory schema describes the types of data in
the directory, so determining what schema to use reflects decisions on how to represent the data
stored in the directory. During the schema design process, each data element is mapped to an LDAP
attribute, and related elements are gathered into LDAP object classes. A well-designed schema helps
to maintain the integrity of the directory data.

This chapter describes the directory schema and how to design a schema for unique organizational
needs.

For information on replicating a schema, see Section 6.4.4, “Schema Replication”.

3.1. Schema Design Process Overview

During the schema design process, select and define the object classes and attributes used to
represent the entries stored by Red Hat Directory Server. Schema design involves the following steps:

1. Choosing predefined schema elements to meet as many of data needs as possible.

2. Extending the standard Directory Server schema to define new elements to meet other remaining
needs.

3. Planning for schema maintenance.

The simplest and most easily-maintained option is to use existing schema elements defined in
the standard schema provided with Directory Server. Choosing standard schema elements helps
ensure compatibility with directory-enabled applications. Because the schema is based on the LDAP
standard, it has been reviewed and agreed to by a wide number of directory users.

3.2. Standard Schema

The directory schema maintains the integrity of the data stored in the directory by imposing constraints
on the size, range, and format of data values. The schema reflects decisions about what types of
entries the directory contains (like people, devices, and organizations) and the attributes available to
each entry.

The predefined schema included with Directory Server contains both the standard LDAP schema
as well as additional application-specific schema to support the features of the server. While this
schema meets most directory needs, new object classes and attributes can be added to the schema
(extending the schema) to accommodate the unique needs of the directory. See Section 3.4,

“Customizing the Schema” for information on extending the schema.

3.2.1. Schema Format

Directory Server bases its schema format on version 3 of the LDAP protocol. This protocol requires
directory servers to publish their schema through LDAP itself, allowing directory client applications to
retrieve the schema programmatically and adapt their behavior accordingly. The global set of schema
for Directory Server can be found in the cn=schema entry.

Chapter 3. Designing the Directory Schema

20

The Directory Server schema differs slightly from the LDAPv3 schema, because it uses its own
proprietary object classes and attributes. In addition, it uses a private field in the schema entries,
called X-ORIGIN, which describes where the schema entry was defined originally.

For example, if a schema entry is defined in the standard LDAPv3 schema, the X-ORIGIN field refers
to RFC 2252. If the entry is defined by Red Hat for the Directory Server's use, the X-ORIGIN field
contains the value Netscape Directory Server.

For example, the standard person object class appears in the schema as follows:

objectclasses: ( 2.5.6.6 NAME 'person' DESC 'Standard Person Object Class'
SUP top
MUST (objectclass $ sn $ cn) MAY (description $ seeAlso $
telephoneNumber $ userPassword)
X-ORIGIN 'RFC 2252' )

This schema entry states the object identifier, or OID, for the class (2.5.6.6), the name of the
object class (person), a description of the class (Standard Person), and then lists the required
attributes (objectclass, sn, and cn) and the allowed attributes (description, seeAlso,
telephoneNumber, and userPassword).

For more information about the LDAPv3 schema format, see the LDAPv3 Attribute Syntax Definitions
document, RFC 2252, and other standard schema definitions in RFC 247, RFC 2927, and RFC 2307.
All of these schema elements are supported in Red Hat Directory Server.

3.2.2. Standard Attributes

Attributes contain specific data elements such as a name or a fax number. Directory Server represents
data as attribute-data pairs, a descriptive schema attribute associated with a specific piece of
information. These are also called attribute-value assertions or AVAs.

For example, the directory can store a piece of data such as a person's name in a pair with the
standard attribute, in this case commonName (cn). So, an entry for a person named Babs Jensen has
the attribute-data pair cn: Babs Jensen.

In fact, the entire entry is represented as a series of attribute-data pairs. The entire entry for Babs
Jensen is as follows:

dn: uid=bjensen, ou=people, dc=example, dc=com
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
cn: Babs Jensen
sn: Jensen
givenName: Babs
givenName: Barbara
mail: [e-mail]

The entry for Babs Jensen contains multiple values for some of the attributes. The givenName
attribute appears twice, each time with a unique value.