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

Deployment Guide

Red Hat Directory Server

Version 7.1

May 2005

Red Hat, Inc.
1801 Varsity Drive
Raleigh NC 27606-2072 USA
Phone: [phone]
Phone: [phone]
Fax: [phone]
PO Box 13588

Research Triangle Park NC 27709 USA
© 2001 Sun Microsystems, Inc. Used by permission. © 2005 by Red Hat, Inc. All rights reserved. This material may be distributed only subject to the

terms and conditions set forth in the Open Publication License, V1.0 or later (the latest version is presently available at
http://www.opencontent.org/openpub/).

Distribution of substantively modified versions of this document is prohibited without the explicit permission of the copyright holder.
Distribution of the work or derivative of the work in any standard (paper) book form for commercial purposes is prohibited unless prior permission is

obtained from the copyright holder.
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.
The GPG fingerprint of the [e-mail] key is:
CA 20 86 86 2B D6 9D FC 65 F6 EC C4 21 91 80 CD DB 42 A6 0E

Contents

About This Guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

Purpose of This Guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

Directory Server Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

Conventions Used in This Guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

Related Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

Chapter 1 Introduction to Directory Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

What Is a Directory Service? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

About Global Directory Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

About LDAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

Introduction to Directory Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

Overview of Directory Server Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

Overview of the Server Front-End . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

Server Plug-ins Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

Overview of the Basic Directory Tree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

Directory Server Data Storage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

About Directory Entries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

Distributing Directory Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

Directory Design Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

Design Process Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

Deploying Your Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

Piloting Your Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

Putting Your Directory into Production . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

Other General Directory Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

Chapter 2 How to Plan Your Directory Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

Introduction to Directory Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

Contents 3

What Your Directory Might Include . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

What Your Directory Should Not Include . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

Defining Your Directory Needs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

Performing a Site Survey . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

Identifying the Applications That Use Your Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

Identifying Data Sources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

Characterizing Your Directory Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

Determining Level of Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

Considering a Data Master . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

Data Mastering for Replication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

Data Mastering for Synchronization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

Data Mastering Across Multiple Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

Determining Data Ownership . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

Determining Data Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

Documenting Your Site Survey . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

Repeating the Site Survey . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

Chapter 3 How to Design the Schema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

Schema Design Process Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

Standard Schema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

Schema Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

Standard Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

Standard Object Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

Mapping Your Data to the Default Schema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

Viewing the Default Directory Schema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

Matching Data to Schema Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

Customizing the Schema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

When to Extend Your Schema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

Getting and Assigning Object Identifiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

Naming Attributes and Object Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

Strategies for Defining New Object Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

Strategies for Defining New Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

Deleting Schema Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

Creating Custom Schema Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

Custom Schema Best Practices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

Maintaining Consistent Schema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

Schema Checking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

Selecting Consistent Data Formats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

Maintaining Consistency in Replicated Schema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

Other Schema Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

4 Red Hat Directory Server Deployment Guide • May 2005

Chapter 4 Designing the Directory Tree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

Introduction to the Directory Tree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

Designing Your Directory Tree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

Choosing a Suffix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

Suffix Naming Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

Naming Multiple Suffixes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

Creating Your Directory Tree Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

Branching Your Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

Identifying Branch Points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

Replication Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

Access Control Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

Naming Entries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

Naming Person Entries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

Naming Group Entries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

Naming Organization Entries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

Naming Other Kinds of Entries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

Grouping Directory Entries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

About Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

Deciding Between Roles and Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

About Class of Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

Directory Tree Design Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

Directory Tree for an International Enterprise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

Directory Tree for an ISP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

Virtual Directory Information Tree Views . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

Introduction to Virtual DIT Views . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

Advantages of Using Virtual DIT Views . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

Example of Virtual DIT Views . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

Views and Other Directory Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

Effects of Virtual Views on Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

Compatibility with Existing Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

Other Directory Tree Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

Chapter 5 Designing the Directory Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

Topology Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

Distributing Your Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

About Using Multiple Databases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

About Suffixes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

About Knowledge References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

Using Referrals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

The Structure of an LDAP Referral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

About Default Referrals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98

Smart Referrals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

Contents 5

Tips for Designing Smart Referrals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

Using Chaining . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102

Deciding Between Referrals and Chaining . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104

Usage Differences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104

Evaluating Access Controls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104

Using Indexes to Improve Database Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108

Overview of Directory Index Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108

Evaluating the Costs of Indexing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

Chapter 6 Designing the Replication Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

Introduction to Replication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

Replication Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112

Unit of Replication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113

Read-Write Replica/Read-Only Replica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113

Supplier/Consumer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113

Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114

Replication Agreement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114

Data Consistency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115

Common Replication Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116

Single-Master Replication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116

Multi-Master Replication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117

Cascading Replication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121

Mixed Environments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123

Defining a Replication Strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125

Replication Survey . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126

Replication Resource Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127

Fractional Replication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127

Replication across a Wide-Area Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128

Using Replication for High Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129

Using Replication for Local Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130

Using Replication for Load Balancing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130

Example of Network Load Balancing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131

Example of Load Balancing for Improved Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133

Example Replication Strategy for a Small Site . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134

Example Replication Strategy for a Large Site . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134

Using Replication with Other Directory Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135

Replication and Access Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135

Replication and Directory Server Plug-ins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135

Replication and Database Links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136

Schema Replication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137

Replication and Synchronization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138

6 Red Hat Directory Server Deployment Guide • May 2005

Chapter 7 Designing Synchronization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139

Windows Sync Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139

Designing Windows Sync . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144

Resource Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146

Services to Install . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146

Considering a Data Master . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147

Interaction with a Replicated Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147

Characterizing Your Directory Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148

Chapter 8 Designing a Secure Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153

About Security Threats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154

Unauthorized Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154

Unauthorized Tampering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155

Denial of Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155

Analyzing Your Security Needs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155

Determining Access Rights . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156

Ensuring Data Privacy and Integrity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157

Conducting Regular Audits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157

Example Security Needs Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157

Overview of Security Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158

Selecting Appropriate Authentication Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159

Anonymous Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159

Simple Password . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160

Certificate-Based Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161

Simple Password over TLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162

Proxy Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162

Preventing Authentication by Account Inactivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163

Designing a Password Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163

How Password Policy Works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164

Password Policy Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169

Password Change after Reset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170

User-Defined Passwords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170

Password Expiration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171

Expiration Warning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171

Grace Login Limit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171

Password Syntax Checking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172

Password Length . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172

Password Minimum Age . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172

Password History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172

Password Storage Scheme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173

Designing an Account Lockout Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173

Designing a Password Policy in a Replicated Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173

Designing Access Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174

Contents 7

About the ACI Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175

Targets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176

Permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176

Bind Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177

Setting Permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178

The Precedence Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178

Allowing or Denying Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178

When to Deny Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179

Where to Place Access Control Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180

Using Filtered Access Control Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180

Viewing ACIs: Get Effective Rights . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181

Using ACIs: Some Hints and Tricks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182

Database Encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184

Securing Connections with SSL and Start TLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185

Securing Connections with SASL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185

Other Security Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186

Chapter 9 Directory Design Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187

An Enterprise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187

Data Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188

Schema Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188

Directory Tree Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189

Topology Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190

Database Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191

Server Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191

Replication Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193

Supplier Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193

Supplier Consumer Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194

Security Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195

Tuning and Optimizations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196

Operations Decisions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196

A Multinational Enterprise and Its Extranet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196

Data Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197

Schema Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198

Directory Tree Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198

Topology Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200

Database Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200

Server Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202

Replication Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204

Supplier Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205

Security Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207

8 Red Hat Directory Server Deployment Guide • May 2005

Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209

Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225

Contents 9

10 Red Hat Directory Server Deployment Guide • May 2005

About This Guide

Welcome to the Red Hat Directory Server (Directory Server). This preface includes
the following sections:

• Purpose of This Guide (page 11)

• Directory Server Overview (page 11)

• Conventions Used in This Guide (page 13)

• Related Information (page 13)

Purpose of This Guide

This guide provides you with a foundation for planning your directory. The
information provided here is intended for directory decision makers, designers,
and administrators.

The first chapter of this guide introduces basic directory concepts. Most of the
remainder of the guide covers aspects of directory design, including schema
design, the directory tree, topology, replication, and security. The last chapter
provides sample deployment scenarios to help you plan simple deployments as
well as complex deployments designed to support millions of users distributed
worldwide.

Directory Server Overview

Directory Server provides the following key features:

11

Directory Server Overview

• 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 your directory by storing a
complete logical view of your directory on a single server, while maintaining
data on a large number of Directory Servers transparently for clients.

• Roles and Class of Service — Provides a flexible mechanism for grouping and
sharing attributes between entries in a dynamic fashion.

• Improved access control mechanism — 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 — Gives you 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 your
directory data to simplify the implementation of replication and chaining in
your directory service.

• Password Policy and Account Lockout — Allows you to define a set of rules
that govern how passwords and user accounts are managed in the Directory
Server.

• SSL — Provides secure communications over the network, including ciphers
with up to 168-bit encryption.

The major components of Directory Server include:

• An LDAP server — The core of the directory service, provided by the

ns-slapd

daemon and compliant with the LDAP v3 Internet standards.

• Directory Server Console — An improved management console that
dramatically reduces the effort of setting up and maintaining your directory
service. The directory console is part of Red Hat Console, the common
management framework for LDAP directory services.

• SNMP Agent — Permits you to monitor your Directory Server in real time
using the Simple Network Management Protocol (SNMP).

• Online backup and restore — Allows you to create backups and restore from

backups while the server is running.

12 Red Hat Directory Server Deployment Guide • May 2005

Conventions Used in This Guide

This guide uses the following conventions:

•

Monospaced font

computer screen or text that you should type. It is also used for filenames,
functions, and examples.

•

— This typeface is used for any text that appears on the

Conventions Used in This Guide

NOTE
CAUTION
TIP

• Throughout this book you will see path references of the form:

serverRoot/slapd-serverID/...

serverRoot

/opt/redhat-ds/servers

location, you should adapt the path accordingly.

serverID

when you installed it. For example, if you gave the server an identifier of

phonebook
/opt/redhat-ds/servers/slapd-phonebook/. . .

• In examples/sample code, paths assume that the Directory Server is installed
in the default location
Directory Server in a different location, adapt the paths accordingly. Also, all
examples use

Notes, Cautions and Tips mark important information. Make sure
you read this information before continuing.

is the installation directory. The default installation directory is

. If you have installed Directory Server in a different

is the ID or identifier you assigned to an instance of Directory Server

, then the actual path would look like this:

/opt/redhat-ds/servers

phonebook

for the server identifier where appropriate.

. If you have installed your

Related Information

The document set for Directory Server also contains the following guides:

• Red Hat Directory Server Installation Guide. Contains procedures for installing
your Directory Server as well as procedures for migrating your Directory
Server.

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

13

Related Information

• Red Hat Directory Server Configuration, Command, and File Reference. Provides

• Red Hat Directory Server Schema Reference. Provides reference information

• Red Hat Directory Server Plug-in Programmer’s Guide. Describes how to write

• Red Hat Directory Server Gateway Customization Guide. Introduces Directory

• Red Hat Directory Server Org Chart. Introduces the Red Hat Directory Server

information about using the command-line scripts shipped with Directory
Server.

about the Red Hat Directory Server schema.

server plug-ins in order to customize and extend the capabilities of Directory
Server.

Server Gateway and explains how to implement a gateway instance with
basic directory look-up functionality. Also contains information useful for
implementing a more powerful gateway instance with directory
authentication and administration capability.

Org Chart application and explains how to integrate it with an instance of
Directory Server.

• Red Hat Directory Server DSML Gateway Guide. Introduces the Red Hat
Directory Server DSML Gateway function and explains how to customize it
for use as an independent gateway.

For a list of documentation installed with Directory Server, open this file:

serverRoot/manual/en/slapd/index.htm

For the latest information about Directory Server, including current release notes,
complete product documentation, technical notes, and deployment information,
check this site:

http://www.redhat.com/docs/manuals/dir-server/

14 Red Hat Directory Server Deployment Guide • May 2005

Chapter 1

Introduction to Directory Server

Red Hat Directory Server (Directory Server) provides a centralized directory
service for your 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. You can
extend Directory Server to manage user profiles and preferences, as well as
extranet user authentication.

This chapter describes the basic ideas you need to understand before designing
your directory. It includes the following sections:

• What Is a Directory Service? (page 15)

• Introduction to Directory Server (page 17)

• Directory Design Overview (page 23)

• Other General Directory Resources (page 26)

What Is a Directory Service?

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

One common directory service is a Domain Name System (DNS) server. A DNS
server maps a computer hostname to an IP address. Thus, all of the computing
resources (hosts) become clients of the DNS server. The mapping of hostnames
allows users of your computing resources to easily locate computers on your
network by remembering hostnames rather than numerical IP addresses.

15

What Is a Directory Service?

However, the DNS server stores only two types of information: names and IP
addresses. A true directory service stores virtually unlimited types of
information.

Directory Server stores all of your information in a single, network-accessible
repository. The following are a few examples of the kinds of information you
might store in a directory:

• Physical device information, such as data about the printers in your
organization (where they reside, whether they are color or black and white,
their 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.

The following sections describe global directory services and the Lightweight
Data Access Protocol (LDAP).

About Global Directory Services

Directory Server provides global directory services, meaning it provides
information to a wide variety of applications. Until recently, many applications
came bundled with their own proprietary databases. While a proprietary
database can be convenient if you use only one application, multiple databases
become an administrative burden if the databases manage the same information.

For example, suppose your network supports three different proprietary email
systems, each system 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
increased hardware and personnel costs, a problem referred to as the n + 1
directory problem.

16 Red Hat Directory Server Deployment Guide • May 2005

Introduction to Directory Server

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 requires a
network-based means of communicating between the applications and the
directory. Directory Server uses LDAP (Lightweight Directory Access Protocol) to
give applications access to its global directory service.

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) used by the ISO X.500 standard. DAP gives any application
access to the directory via an extensible and robust information framework but at
an expensive administrative cost. DAP uses a communications layer that is not the
Internet standard TCP/IP protocol and has complicated 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 uses
simplified encoding methods. It retains the X.500 standard data model and can
support millions of entries for a modest investment in hardware and network
infrastructure.

Introduction to Directory Server

Directory Server includes the directory itself, the server-side software that
implements the LDAP protocol, and a graphical user interface that allows
end-users to search and change entries in the directory. You can purchase other
LDAP client programs or write your own using the LDAP client SDK included
with the Directory Server product.

Without adding other LDAP client programs, Directory Server can provide the
foundation for your 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.

You can use Directory Server to manage extranet 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.

Chapter 1 Introduction to Directory Server 17

Introduction to Directory Server

When you install Directory Server, the following components are installed on
your machine:

• An LDAP server (Directory Server) with a plug-in interface.

• The name of this process is

ns-slapd

.

• Red Hat Administration Server.

For more information about the Administration Server, see Managing Servers
with Red Hat Console.

• Red Hat Console to manage the servers.

For more information about the Red Hat Console, see Managing Servers with
Red Hat Console.

• Command-line tools for starting and stopping the server, importing and
exporting data in the database, database reindexing, account inactivation and
deactivation, LDIF merges, and kernel tuning.

For more information about the command-line tools, refer to Red Hat
Directory Server Configuration, Command, and File Reference.

• An SNMP monitor.

For more information about SNMP monitoring, refer to the Red Hat Directory
Server Administrator’s Guide.

This guide talks about the core Directory Server and the plug-ins it uses for doing
its work. The next sections describe Directory Server in more detail. The topics
discussed are:

• Overview of Directory Server Architecture

• Directory Server Data Storage

Overview of Directory Server Architecture

At installation, Directory Server contains the following:

• A server front-end responsible for network communications.

• Plug-ins for server functions, such as access control and replication.

• A basic directory tree containing server-related data.

The following sections describe each component of the directory in more detail.

18 Red Hat Directory Server Deployment Guide • May 2005

Introduction to Directory Server

Overview of the Server Front-End

The server front-end of Directory Server manages communications with directory
client programs. Directory Server functions as a daemon. Multiple client programs
can speak to the server in LDAP. They can communicate using LDAP over TCP/IP.
The connection can also be protected 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. In the future, when DNS security is present, TLS used in conjunction
with secured DNS will provide confirmation to client applications that they are
binding to the correct server. If clients have been issued certificates, TLS can be
used by Directory Server to confirm that the client has the right to access the server.
TLS and its predecessor SSL are used to perform other security activities such as
message integrity checks, digital signatures, and mutual authentication between
servers.

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

Server Plug-ins Overview

Directory Server relies on plug-ins. A plug-in is a way to add functionality to the
core server. For example, a database is a plug-in.

A plug-in can be disabled. When disabled, the plug-in’s configuration information
remains in the directory, but its function will not be used by the server. Depending
upon what you want your directory to do, you can choose to enable any of the
plug-ins provided with Directory Server.

Red Hat Professional Services can write custom plug-ins for your Directory Server
deployment. Contact Red Hat Professional Services for more information.

Overview of the Basic Directory Tree

The directory tree, also known as a directory information tree or DIT, mirrors the
tree model used by most filesystems, with the tree’s root, or first entry, appearing
at the top of the hierarchy. At installation, Directory Server creates a default
directory tree.

The default directory tree appears as follows:

Chapter 1 Introduction to Directory Server 19

Introduction to Directory Server

The root of the tree is called the root suffix. For information about naming the root
suffix, refer to “Choosing a Suffix,” on page 62.

At installation, the directory contains up to four subtrees under your root suffix:

•

cn=config

This subtree contains information about the server’s internal configuration.

•

o=NetscapeRoot

This subtree contains the configuration information of other servers, such as
Administration Server. The Administration Server takes care of
authentication and all actions that cannot be performed through LDAP (such
as starting or stopping).

•

o=userRoot

During installation, a user database is created by default. Its default name is

o=userRoot

. You can choose to populate it at installation time, or populate

later.

NOTE When you install another instance of Directory Server, you can

specify that it does not contain the
that it uses the configuration directory (or the

o=NetscapeRoot

o=NetscapeRoot

information,

subtree) present on another server. See the Red Hat Directory Server
Installation Guide for more information about deciding upon the
location of your configuration directory.

You can build on the default directory tree to add any data relevant to your
directory installation. An example of a directory tree for

example.com

Corporation follows:

20 Red Hat Directory Server Deployment Guide • May 2005

Introduction to Directory Server

For more information about directory trees, refer to chapter 4, “Choosing a Suffix,”
on page 62.

Directory Server Data Storage

Your directory data is 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.

The database is the basic unit of storage, performance, replication, and indexing.
You can do operations like importing, exporting, backing up, restoring, and
indexing on the database.

By default, Directory Server uses a single database to contain the directory tree.
This database can manage millions of entries. The default database supports
advanced methods of backing up and restoring your data, so that your data is not
at risk.

NOTE For database files that are larger than 2Gbytes, the machine must be

configured to support large files.

You can do this by choosing
filesystem with

largefiles

files without having to configure the filesystem.

largefile

on Solaris and

vxfs

option on HP UX. Linux handles large

Chapter 1 Introduction to Directory Server 21

Introduction to Directory Server

You can choose to use multiple databases to support your Directory Server. You
can distribute your data across the databases, allowing the server to hold more
data than can be stored in a single database.

The following sections describe how a directory database stores data.

About Directory Entries

LDIF is a standard text-based format for describing directory entries. An entry is a
group of lines in the LDIF file that contains information about an object, such as a
person in your organization or a printer on your 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.

For example, an entry might be of an object class

organizationalPerson

,
indicating that the entry represents a person within a particular organization.
This object class allows 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. There are also some operational
attributes that can be set by the administrator, for access control and other server
functions.

Entries are stored in a hierarchical structure in the directory tree. In LDAP, you
can query an entry and request all entries below it in the directory tree. This
subtree is called the base distinguished name, or base DN. For example, if you
make an LDAP search request specifying a base DN of

dc=example,dc=com

subtree in the

dc=example,dc=com

, then the search operation examines only the

directory tree.

ou=people,

ou=people

However, all entries are not automatically returned in response to an LDAP
search. This is because Directory Server supports a new kind of entry, entries of
the object class

ldapsubentry

. An

ldapsubentry

entry represents an
administrative object; for example, entries used to define a role or a class of
service are of the

ldapsubentry

type. Entries of type

ldapsubentry

are not
returned in response to normal search requests. To receive these entries, clients
need to search specifically for entries of the

ldapsubentry

object class.

For more information about roles, see “About Roles,” on page 75. For more
information about class of service, see “About Class of Service,” on page 77.

22 Red Hat Directory Server Deployment Guide • May 2005

Distributing Directory Data

When you store various parts of your tree in separate databases, your directory can
process client requests in parallel, improving performance. You can also store your
databases on different machines, to further improve performance.

To connect your distributed data, you can create a special entry in a subtree of your
directory. All LDAP operations attempted below this entry are sent to a remote
machine where the entry is actually stored. This method is called chaining.

Chaining is implemented in the server as a plug-in. The plug-in is enabled by
default. Using this plug-in, you create database links, special entries that 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.

Directory Design Overview

Directory Design Overview

The previous sections described directory services in general and the Directory
Server in particular. Now, it is time to consider the design of your own directory
service.

Planning your directory service before actual deployment is the most important
task to ensure the success of your directory. During your directory design, you will
gather data about your directory requirements, such as environment and data
sources, your users, and the applications that will use your directory. With this
data, you can design a directory service that meets your needs.

However, keep in mind that the flexibility of Directory Server allows you to rework
your design to meet unexpected or changing requirements, even after you deploy
Directory Server.

Design Process Outline

The remainder of this guide divides the design process into six steps:

• How to Plan Your Directory Data.

Chapter 1 Introduction to Directory Server 23

Directory Design Overview

Your directory will contain data, such as user names, telephone numbers, and
group details. In chapter 2, “How to Plan Your Directory Data,” on page 27,
you analyze the various sources of data in your organization and understand
their relationship with one another. It describes the types of data you might
store in your directory and other tasks you need to perform to design the
contents of your Directory Server.

• How to Design the Schema.

Your directory is designed to support one or more directory-enabled
applications. These applications have requirements of the data you store in
your directory, such as format. Your directory schema determines the
characteristics of the data stored in your directory. The standard schema
shipped with Directory Server is introduced in chapter 3, “How to Design the
Schema,” on page 43, along with describing how to customize the schema
and providing tips for maintaining consistent schema.

• Designing the Directory Tree.

Once you decide what data your directory contains, you need to organize and
reference that data. This is the purpose of the directory tree. In chapter 4,
“Designing the Directory Tree,” on page 61, the directory tree is introduced,
and you are guided through the design of your data hierarchy. Sample
directory tree designs are also provided.

• Designing the Directory Topology.

Topology design involves determining how you divide your directory tree
among multiple physical Directory Servers and how these servers
communicate with one another. The general principles behind topology
design, using multiple databases, the mechanisms available for linking your
distributed data together, and how the directory itself keeps track of
distributed data are all described in chapter 5, “Designing the Directory
Topology,” on page 91.

• Designing the Replication Process.

With replication, multiple Directory Servers maintain the same directory data
to increase performance and provide fault tolerance, as described in chapter
6, “Designing the Replication Process,” on page 111. This chapter describes
how replication works, what kinds of data you can replicate, common
replication scenarios, and tips for building a highly available directory
service.

24 Red Hat Directory Server Deployment Guide • May 2005

Directory Design Overview

• Designing Synchronization.

Windows synchronization allows the Directory Server to maintain the same
directory data on the Directory Server, Windows NT4 Server, and Active
DIrectory servers, as described in chapter 7, “Designing Synchronization,” on
page 139. This chapter describes how synchronization works, synchronization
scenarios, and tips for planning a synchronized, unified directory service.

• Designing a Secure Directory.

Finally, you need to plan how to protect the data in the directory and design
the other aspects of your service to meet the security requirements of your
users and applications, chapter 8, “Designing a Secure Directory,” on page 153.
This chapter covers common security threats, an overview of security methods,
steps in analyzing your security needs, and tips for designing access controls
and protecting the integrity of your directory data.

Deploying Your Directory

After you have designed your directory service, you start the deployment phase.
The deployment phase consists of the following steps:

• Piloting Your Directory

• Putting Your Directory into Production

Piloting Your Directory

The first step of the deployment phase is installing a server instance as a pilot and
testing whether your service can handle your user load. If the service is not
adequate as it is, adjust your design and pilot it again. Adjust your pilot design
until you have a robust service you can confidently introduce to your enterprise.

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

Putting Your Directory into Production

Once you have piloted and tuned the service, you need to develop and execute a
plan for taking the directory service from a pilot to production. Create a production
plan that includes the following:

• An estimate of the resources you need.

• A list of the tasks you must perform before installing servers.

Chapter 1 Introduction to Directory Server 25

Other General Directory Resources

• A schedule of what needs to be accomplished and when.

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

For information on installing your directory service, refer to Red Hat Directory
Server Installation Guide. For information on administering and maintaining your
directory, refer to Red Hat Directory Server Administrator’s Guide.

Other General Directory Resources

For more information about directories, LDAP, and LDIF, take a look at the
following:

• 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.

26 Red Hat Directory Server Deployment Guide • May 2005

Chapter 2

How to Plan Your Directory Data

The data stored in your 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 your directory determines how you
structure the directory, to whom you allow access to the data, and how this access
is requested and granted.

This chapter describes the issues and strategies behind planning your directory’s
data. It includes the following sections:

• Introduction to Directory Data (page 27)

• Defining Your Directory Needs (page 29)

• Performing a Site Survey (page 30)

Introduction to Directory Data

Some types of data are better suited to your 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,

• It is of interest to more than one audience.

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.

surname=jensen

).

27

Introduction to Directory Data

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.

What Your Directory Might Include

Examples of data you can put in your directory are:

• 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 your 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 filesystem of a certain

file or application.

If you are going to use Directory Server for more than just server administration,
then you have to decide what other types of information you want to store in
your directory. For example, you might include some of the following types of
information:

• Contract or client account details

• Payroll data

• Physical device information

• Home contact information

28 Red Hat Directory Server Deployment Guide • May 2005

• Office contact information for the various sites within your enterprise

What Your Directory Should Not Include

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
filesystem. However, your directory can store pointers to these kinds of
applications through the use of FTP, HTTP, or other types of URL.

Defining Your Directory Needs

When you design your directory data, think not only of the data you currently
require but also what you may include in your directory in the future. Considering
the future needs of your directory during the design process influences how you
you structure and distribute the data in your directory.

Defining Your Directory Needs

As you plan, consider these points:

• What do you want to put in your directory today? What immediate problem
do you hope to solve by deploying a directory? What are the immediate needs
of the directory-enabled application you use?

• What do you want to put in your directory in the near future? For example,
your enterprise might use an accounting package that does not currently
support LDAP but that you know will be LDAP-enabled in the near future.
You should identify the data used by applications such as this and plan for the
migration of the data into the directory when the technology becomes
available.

• What do you think you might want to store in your directory in the future? For
example, if you are a hosting environment, perhaps future customers will have
different data requirements from your current customers. Maybe future
customers will want to use your directory to store JPEG images. While this is
the hardest case of all to consider, doing so may pay off in unexpected ways. At
a minimum, this kind of planning helps you identify data sources you might
otherwise not have considered.

Chapter 2 How to Plan Your Directory Data 29

Performing a Site Survey

Performing a Site Survey

A site survey is a formal method for discovering and characterizing the contents
of your directory. Budget plenty of time for performing a site survey, as data is
the key to your directory architecture. The site survey consists of the following
tasks, which are described briefly here and in more detail next:

• Identify the applications that use your directory.

Determine the directory-enabled applications you deploy and their data
needs.

• Identify data sources.

Survey your enterprise and identify sources of data (such as Windows NT or
Active Directory, PBX systems, human resources databases, email systems,
and so forth). See chapter 7, “Designing Synchronization,” on page 139, for
more information on integrating your Directory Server and Windows
directory.

• Characterize the data your directory needs to contain.

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

• Determine the level of service you need to provide.

Decide how available your directory data needs to be to client applications,
and design your architecture accordingly. How available your directory
needs to be affects how you replicate data and configure chaining policies to
connect data stored on remote servers.

For more information about replication, refer to chapter 6, “Designing the
Replication Process,” on page 111. For more information on chaining, refer to
“Topology Overview,” on page 91.

• 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.

30 Red Hat Directory Server Deployment Guide • May 2005

Performing a Site Survey

If you import data 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 your administrative
overhead.

• Document your 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. This team performs the site
survey.

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

Identifying the Applications That Use Your Directory

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

• Directory browser applications, such as online telephone books. Decide what
information (such as email addresses, telephone numbers, and employee
name) your users need, and make sure you 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.

Chapter 2 How to Plan Your Directory Data 31

Performing a Site Survey

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

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

Table 2-1 Application Data Needs

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.

Once you identify the applications and information used by each application, you
can see that some types of data are used by more than one application. Doing this
kind of exercise during the data planning stage can help you avoid data
redundancy problems in your directory and see more clearly what data your
directory-dependent applications require.

The final decision you make about the types of data you maintain in your
directory and when you start maintaining it is affected by these factors:

• The data required by your various legacy applications and your user
population.

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

32 Red Hat Directory Server Deployment Guide • May 2005

Performing a Site Survey

Identifying Data Sources

To identify all of the data that you want to include in your directory, you should
perform a survey of your existing data stores. Your survey should include the
following:

• Identify organizations that provide information.

Locate all the organizations that manage information essential to your
enterprise. Typically, this includes your 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.

You may find that centralized data management requires new tools and new

processes. Sometimes centralization requires increasing staff in some
organizations while decreasing staff in others.

During your survey, you may come up with a matrix that resembles the following
table, identifying all of the information sources in your enterprise:

Table 2-2 Information Sources

Data Source Class of Data Data

Human resources database People Name, address, phone

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

Facilities system Facilities Building names, floor names,

Characterizing Your Directory Data

All of the data you identify for inclusion in your directory can be characterized

according to the following general points:

• Format

number, department number,
manager.

password, email preferences.

cube numbers, access codes.

Chapter 2 How to Plan Your Directory Data 33

Performing a Site Survey

• Size

• Number of occurrences in various applications

• Data owner

• Relationship to other directory data

You should study each piece of data you plan to include in your 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,
“How to Design the Schema,” on page 43.

For example, you can create a table that characterizes your directory data as
follows:

Table 2-3 Directory Data Characteristics

Data Format Size Owner Related to

Employee Name Text string 128 characters Human

resources
Fax number Phone number 14 digits Facilities User’s entry

Email address Text Many

character

IS department User’s entry

User’s entry

Determining Level of Service

The level of service you provide depends upon 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 your 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 your directory is deployed, so make sure your initial design can meet your
future needs.

For example, if you determine that you need to eliminate the risk of total failure,
you might consider using a multi-master configuration, in which several
suppliers exist for the same data. The next section discusses determining data
masters in more detail.

34 Red Hat Directory Server Deployment Guide • May 2005

Performing a Site Survey

Considering a Data Master

The data master is the server that is the master source of data. Consider which
server will be the data master when your data resides in more than one physical
site. For example, when you use replication or use applications that cannot
communicate over LDAP, data may be spread over more than one site. If a piece of
data is present in more than one location, you need to decide which server has the
master copy and which server receives updates from this master copy.

Data Mastering for Replication

Directory Server allows you to contain master sources of information on more than
one server. If you use replication, decide which server is the master source of a
piece of data. Directory Server supports multi-master configurations, in which
more than one server is the master source for the same piece of data. For more
information about replication and multi-master replication, see chapter 6,
“Designing the Replication Process,” on page 111.

In the simplest case, put a master source of all of your data on two Directory
Servers, and then replicate that data to one or more consumer servers. Having two
supplier servers provides safe failover in the event that a server goes off-line. In
more complex cases, you may want to store the data in multiple databases, so that
the entries are mastered by a server close to the applications which will update or
search that data.

Data Mastering for Synchronization

You can synchronize your Directory Server users, groups, attributes, and
passwords with Microsoft Active Directory or Windows NT4 Server users, groups,
attributes, and passwords. If you have two directory services, you must decide if
you want these to be synchronized (if 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. For more information, see chapter 7, “Designing
Synchronization,” on page 139.

Data Mastering Across Multiple Applications

You also need to consider the master source of your data if you have applications
that communicate indirectly with the directory. Keep the processes for changing
data, and the places from which you can change data, as simple as possible. Once
you decide 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 your
databases get out of sync across your enterprise.

Chapter 2 How to Plan Your Directory Data 35

Performing a Site Survey

Here are some ways you can 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 your enterprise
(which is what your 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 you can
identify one or two applications that you already use to master your data, and
you want to use your directory only for lookups (for example, for online
corporate telephone books).

How you maintain master copies of your data depends on your specific needs.
However, regardless of how you maintain data masters, keep it simple and
consistent. For example, you should 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 your administrative
overhead.

For example, suppose you want 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 you can write
an automatic application that transfers data from the LDAP directory to the
human resources database, and vice versa. However, if you attempt to master
changes to that employee’s telephone number in both the LDAP directory and the
human resources data, then the last place where the telephone number was
changed overwrites the information in the other database. This is acceptable as
long as the last application to write the data had the correct information. But if
that information was old or out of date (perhaps because, for example, the human
resources data was reloaded from a backup), then the correct telephone number
in the LDAP directory will be deleted.

36 Red Hat Directory Server Deployment Guide • May 2005

Performing a Site Survey

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, decide who can write data to the
directory. Some common strategies for deciding data ownership follow:

• 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.

This approach makes your organization’s administrators your directory
content managers.

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

For example, you might create roles 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, such as salary information, government
identification number (in the US, Social Security Number), and home phone
numbers and address.

For more information about roles and grouping entries, refer to “Grouping
Directory Entries,” on page 75.

As you determine who can write to the data, you may find that multiple
individuals need to have write access to the same information. For example, you
will want an information systems (IS) or directory management group to have
write access to employee passwords. You may also want the employees themselves
to have write access to their own passwords. While you generally must give
multiple people write access to the same information, try to keep this group small
and easy to identify. Keeping the group small helps ensure your data’s integrity.

For information on setting access control for your directory, see chapter 8,
“Designing a Secure Directory,” on page 153.

Chapter 2 How to Plan Your Directory Data 37

Performing a Site Survey

Determining Data Access

After determining data ownership, decide who can read each piece of data. For
example, you may decide to store an employee’s home phone number in your
directory. This data may be useful for a number of organizations, including the
employee’s manager and human resources. You may want the employee to be
able to read this information for verification purposes. However, home contact
information can be considered sensitive. Therefore, you must determine if you
want this kind of data to be widely available across your enterprise.

For each piece of information that you store in your directory, you must 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, you should
use anonymous access sparingly.

• Can the data be read widely across your enterprise?

You can set up access control so that the client must log in to (or bind to) the
directory to read specific information. Unlike anonymous access, this form of
access control ensures that only members of your organization can view
directory information. It also allows you to capture login information in the
directory’s access log so you have a record of who accessed the information.

For more information about access controls, refer to “Designing Access
Control,” on page 174.

• Can you identify a 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). You may also have data
specific to a particular organization or project group. Identifying these access
needs helps you determine what groups, roles, and access controls your
directory needs.

For information about groups and roles, see chapter 4, “Designing the
Directory Tree,” on page 61. For information about access controls, see
chapter 8, “Designing a Secure Directory,” on page 153.

38 Red Hat Directory Server Deployment Guide • May 2005

Performing a Site Survey

As you make these decisions for each piece of directory data, you define a security
policy for your directory. Your decisions depend upon the nature of your site and
the kinds of security already available at your site. For example, if your site has a
firewall or no direct access to the Internet, you may feel freer to support
anonymous access than if you are placing your directory 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 which represent them. Be sure to check with your organization’s legal
department to ensure that your directory deployment follows all necessary laws
for the countries in which your enterprise operates.

The creation of a security policy and the way you implement it is described in
detail in chapter 8, “Designing a Secure Directory,” on page 153.

Documenting Your Site Survey

Because of the complexity of data design, document the results of your site

surveys. During each step of the site survey, we have suggested simple tables for
keeping track of your data. Consider building a master table that outlines your
decisions and outstanding concerns. You can build this table with the
word-processing package of your choice or use a spreadsheet so that the table’s
contents can easily be sorted and searched.

A simple example of a table follows. The table identifies data ownership and data
access for each piece of data identified by the site survey.

Data Name Owner Supplier Server or

Application

Employee
name

User
password

Home phone
number

HR PeopleSoft Read-only Yes

IS Directory US-1 Read/Write No No Yes

HR PeopleSoft Read/Write No Yes No

Self
Read/Write

Global Read HR

Writable

Yes Yes

(anonymous)

IS
Writable

Chapter 2 How to Plan Your Directory Data 39

Performing a Site Survey

Data Name Owner Supplier Server or

Application

Employee
location

Office phone
number

IS Directory US-1 Read-only Yes (must log

Facilities Phone switch Read-only Yes

Looking at the row representing the employee name data, we see the following:

• 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.

Self
Read/Write

Global Read HR

Writable

No Yes

in)

No No

(anonymous)

IS
Writable

• 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.

Repeating the Site Survey

Finally, you may need to run more than one site survey, particularly if your
enterprise has offices in multiple cities or countries. You may find your
informational needs to be so complex that you have to allow several different
organizations to keep information at their local offices rather than at a single,

40 Red Hat Directory Server Deployment Guide • May 2005

Performing a Site Survey

centralized site. In this case, each office that keeps a master copy of information
should run 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 2 How to Plan Your Directory Data 41

Performing a Site Survey

42 Red Hat Directory Server Deployment Guide • May 2005

Chapter 3

How to Design the Schema

The site survey you conducted in chapter 2,“How to Plan Your Directory Data,”
generated information about the data you plan to store in your directory. Next, you
must decide how to represent the data you store. Your directory schema describes
the types of data you can store in your directory. During schema design, you map
each data element to an LDAP attribute and gather related elements into LDAP
object classes. Well-designed schema help maintain the integrity of the data you
store in your directory.

This chapter describes the directory schema and how to design schema for your
unique needs. This chapter contains the following sections:

• Schema Design Process Overview (page 43)

• Standard Schema (page 44)

• Mapping Your Data to the Default Schema (page 48)

• Customizing the Schema (page 50)

• Maintaining Consistent Schema (page 57)

• Other Schema Resources (page 60)

For information on replicating schema, refer to “Schema Replication,” on page 137.

Schema Design Process Overview

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

• Choosing predefined schema elements to meet as many of your needs as
possible.

43

Standard Schema

• Extending the standard Directory Server schema to define new elements to
meet your remaining needs.

• Planning for schema maintenance.

It is best 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. In addition, as the
schema is based on the LDAP standard, you are assured it has been reviewed and
agreed to by a wide number of directory users.

Standard Schema

Your directory schema maintain the integrity of the data stored in your directory
by imposing constraints on the size, range, and format of data values. You decide
what types of entries your directory contains (people, devices, organizations, and
so forth) 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,
you may need to extend it with new object classes and attributes to accommodate
the unique needs of your directory. Refer to “Customizing the Schema,” on
page 50, for information on extending the schema.

The following sections describe the format, standard attributes, and object classes
included in the standard schema.

Schema Format

Directory Server bases its schema format on version 3 of the LDAP protocol
(LDAPv3). 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 based on it. The global set of schema
for Directory Server can be found in the entry named

cn=schema

.

44 Red Hat Directory Server Deployment Guide • May 2005

Standard Schema

The Directory Server schema differs slightly from the LDAPv3 schema, as 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
Red Hat for the Directory Server’s use, the

Hat Directory Server

X-ORIGIN

.

field refers to RFC 2252. If the entry is defined by

X-ORIGIN

field contains the value

Red

For example, the standard

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

This schema entry states the object identifier, or OID, for the class (
name of the object class (
then lists the required attributes (
attributes (

description, seealso, telephoneNumber

person

person

object class appears in the schema as follows:

2.5.6.6

), a description of the class (

objectclass, sn

, and cn) and the allowed

, and

standard person

userPassword

).

), the

),

For more information about the LDAPv3 schema format, refer to the LDAPv3
Attribute Syntax Definitions document (RFC2252).

The differences between current Directory Server schema and Directory Server 4.x
are described in the following table:

Directory Server 4.x Syntax Equivalent Current Directory Server Syntax

bin Binary

ces IA5String
cis DirectoryString

dn DN

int INTEGER
tel TelephoneNumber

In addition, current releases of Directory Server support the following syntaxes:

Syntax Description

OctetString Same behavior as Binary.

URI Same behavior as IA5String.

Chapter 3 How to Design the Schema 45

Standard Schema

Syntax Description

Boolean Boolean values have a value of either "TRUE" or

GeneralizedTime Values in this syntax are encoded as printable strings.

CountryString A value in this syntax is encoded the same as a value

PostalAddress Values in this syntax are encoded according to the

"FALSE."

It is strongly recommended that GMT time be used.
The time zone must be specified.

of DirectoryString syntax. This syntax is limited to
values of exactly two printable string characters.

following:

postal-address = dstring *("$" dstring)

In the above, each dstring component of a postal
address value is encoded as a value of type
DirectoryString syntax. Backslashes and dollar
characters, if they occur in the component, are quoted.
Many servers limit the postal address to six lines of up
to thirty characters. For example:

1234 Main St.$Anytown,TX 12345$USA

Standard Attributes

Attributes hold specific data elements such as a name or a fax number. Directory
Server represents data as attribute-data pairs, a descriptive attribute associated
with a specific piece of information. 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

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 might appear as follows:

dn: uid=bjensen, ou=people, dc=example,dc=com
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
cn: Babs Jensen

). So, an entry for a person named Babs Jensen has the following

46 Red Hat Directory Server Deployment Guide • May 2005

Standard Schema

sn: Jensen
givenName: Babs
givenName: Barbara
mail: [e-mail]

The entry for Babs contains multiple values for some of the attributes. The attribute

givenName

appears twice, each time with a unique value. The object classes that

appear in this example are explained in the next section, “Standard Object Classes.”

In the schema, each attribute definition contains the following information:

• A unique name.

• An object identifier (OID) for the attribute.

• A text description of the attribute.

• The OID of the attribute syntax.

• Indications of whether the attribute is single-valued or multi-valued, whether

the attribute is for the directory’s own use, the origin of the attribute, and any
additional matching rules associated with the attribute.

For example, the cn attribute definition appears in the schema as follows:

attributetypes: ( 2.5.4.3 NAME 'cn' DESC 'commonName Standard

Attribute' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

Standard Object Classes

Object classes are used to group related information. Typically, an object class
represents a real object, such as a person or a fax machine. Before you can use an
object class and its attributes in your directory, it must be identified in the schema.
Your directory recognizes a standard list of object classes by default. See the Red
Hat Directory Server Schema Reference for more information.

Each directory entry belongs to one or more object classes. Once you place an object
class identified in your schema on an entry, you are telling the Directory Server
that the entry can have a certain set of attribute values and must have another,
usually smaller, set of attribute values.

Object class definitions contain the following information:

• A unique name.

• An object identifier (OID) that names the object.

• A set of mandatory attributes.

Chapter 3 How to Design the Schema 47

Mapping Your Data to the Default Schema

• A set of allowed attributes.

For an example of a standard object class as it appears in the schema, refer to
“Schema Format,” on page 44.

As is the case for all of the Directory Server’s schema, object classes are defined
and stored directly in Directory Server. This means that you can both query and
change your directory’s schema with standard LDAP operations.

Mapping Your Data to the Default Schema

The data you identified during your site survey, as described in “Performing a
Site Survey,” on page 30, must be mapped to the existing directory default
schema. This section describes how to view the existing default schema and
provides a method for mapping your data to the appropriate existing schema
elements.

If you find elements in your schema that do not match the existing default
schema, you may need to create custom object classes and attributes. Refer to
“Customizing the Schema,” on page 50, for more information.

Viewing the Default Directory Schema

The default directory schema is stored here:

serverRoot/slapd-serverID/config/schema

This directory contains all of the common schema for the Directory Server. The
LDAPv3 standard user and organization schema can be found in the

00core.ldif

directory can be found in the

NOTE You should not modify the default directory schema.

For more information about each object class and attribute found in directory,
refer to the Red Hat Directory Server Schema Reference. For more information about
the schema files and directory configuration attributes, refer to Red Hat Directory
Server Configuration, Command, and File Reference.

file. The configuration schema used by earlier version of the

50ns-directory.ldif

file.

48 Red Hat Directory Server Deployment Guide • May 2005

Mapping Your Data to the Default Schema

Matching Data to Schema Elements

The data you identified in your site survey now needs to be mapped to the existing

directory schema. This process involves the following steps:

• Identify the type of object the data describes.

Select an object that best matches the data described in your site survey.
Sometimes, a piece of data can describe multiple objects. You need to
determine if the difference needs to be noted in your directory schema. For
example, a telephone number can describe an employee’s telephone number
and a conference room’s telephone number. It is up to you to determine if these
different sorts of data need to be considered different objects in your directory
schema.

• Select a similar object class from the default schema.

It is best to use the common object classes, such as groups, people, and
organizations.

• Select a similar attribute from the matching object class.

Select an attribute from within the matching object class that best matches the
piece of data you identified in your site survey.

• Identify the unmatched data from your site survey.

If there are some pieces of data that do not match the object classes and
attributes defined by the default directory schema, you will need to customize
the schema. See “Customizing the Schema,” on page 50, for more information.

For example, the following table maps directory schema elements to the data
identified during the site survey in chapter 2:

Table 3-1 Data Mapped to Default Directory Schema

Data Owner Object Class Attribute

Employee name HR person cn (commonName)
User password IS person userPassword

Home phone number HR inetOrgPerson homePhone

Employee location IS inetOrgPerson localityName
Office phone

number

Facilities person telephoneNumber

Chapter 3 How to Design the Schema 49

Customizing the Schema

In the table, the employee name describes a person. In the default directory
schema, we found the
class. This object class allows several attributes, one of which is the cn or

commonName

makes the best match for containing the employee name data.

person

object class, which inherits from the

top

object

attribute, which describes the full name of the person. This attribute

The user password also describes an aspect of the
allowed attributes for the person object, we find

The home phone number describes an aspect of a person; however, we do not find
an appropriate attribute in the list associated with the
Analyzing the home phone number more specifically, we can say it describes an
aspect of a person in an organization’s enterprise network. This object
corresponds to the

inetOrgPerson

inetOrgPerson

object class inherits from the
which in turn inherits from the
object’s allowed attributes, we locate the
appropriate for containing the employee’s home telephone number.

Customizing the Schema

You can extend the standard schema if it proves to be too limited for your
directory needs. To help you extend your schema, the Directory Server includes a
schema management tool. For more information, see Red Hat Directory Server
Administrator’s Guide.

Keep the following rules in mind when customizing your schema:

person

userPassword

object. In the list of

.

person

object class.

object class in the directory schema. The

person

organizationPerson

object class. Among the

homePhone

attribute, which is

object class,

inetOrgPerson

• Reuse existing schema elements whenever possible.

• Minimize the number of mandatory attributes you define for each object class.

• Do not define more than one object class or attribute for the same purpose.

• Keep the schema as simple as possible.

• Do not modify any existing definitions of attributes or object classes.

NOTE When customizing the schema, you should never delete or replace

Your custom object classes and attributes are defined in the following file:

50 Red Hat Directory Server Deployment Guide • May 2005

the standard schema. Doing so can lead to compatibility problems
with other directories or other LDAP client applications.

Customizing the Schema

serverRoot/slapd-serverID/config/schema/99user.ldif

The following sections describe customizing the directory schema in more detail:

• When to Extend Your Schema

• Getting and Assigning Object Identifiers

• Naming Attributes and Object Classes

• Strategies for Defining New Object Classes

• Strategies for Defining New Attributes

• Deleting Schema Elements

• Creating Custom Schema Files

• Custom Schema Best Practices

When to Extend Your Schema

While the object classes and attributes supplied with the Directory Server should
meet most of your needs, you may find that a given object class does not allow you
to store specialized information about your organization. Also, you may need to
extend your schema to support the object classes and attributes required by an
LDAP-enabled application’s unique data needs.

Getting and Assigning Object Identifiers

Each LDAP object class or attribute must be assigned a unique name and object
identifier (OID). When you define a schema, you need an OID unique to your
organization. One OID is enough to meet all of your schema needs. You simply
add another level of hierarchy to create new branches for your attributes and object
classes. Getting and assigning OIDs in your schema involves the following steps:

• Obtain an OID for your organization from the Internet Assigned Numbers
Authority (IANA) or a national organization.

In some countries, corporations already have OIDs assigned to them. If your
organization does not already have an OID, one can be obtained from IANA.
For more information, go to the IANA website at

http://www.iana.org/cgi-bin/enterprise.pl

.

Chapter 3 How to Design the Schema 51

Customizing the Schema

• Create an OID registry so you can track OID assignments.

An OID registry is a list you maintain that gives the OIDs and descriptions of
the OIDs used in your directory schema. This ensures that no OID is ever
used for more than one purpose. You should then publish your OID registry
with your schema.

• Create branches in the OID tree to accommodate schema elements.

Create at least two branches under the OID branch or your directory schema,
using
your own matching rules or controls, you can add new branches as needed
(

OID.3

Naming Attributes and Object Classes

When creating names for new attributes and object classes, make the names as
meaningful as possible. This makes your schema easier to use for Directory Server
administrators.

OID.1

for attributes and

, for example).

OID.2

for object classes. If you want to define

Avoid naming collisions between your schema elements and existing schema
elements by including a unique prefix on all of your elements. For example,

example.com

Corporation might add the prefix

example

before each of their

custom schema elements. They might add a special object class called

examplePerson

to identify

example.com

employees in their directory.

Strategies for Defining New Object Classes

There are two ways you can create new object classes:

• You can create many new object classes, one for each object class structure to
which you want to add an attribute.

• You can create a single object class that supports all of the attributes that you
create for your directory. You create this kind of an object class by defining it
to be an AUXILIARY kind of object class.

You may find it easiest to mix the two methods.

For example, suppose your site wants to create the attributes

exampleDateOfBirth, examplePreferredOS, exampleBuildingFloor
exampleVicePresident

. You can create several object classes that allow some
subset of these attributes. You might create an object class called
and have it allow

exampleDateOfBirth

and

examplePreferredOS

, and

examplePerson

. The parent of

52 Red Hat Directory Server Deployment Guide • May 2005

Customizing the Schema

examplePerson

called

exampleVicePresident
organization

exampleOrganization

would be

. The parent of

object class.

inetOrgPerson

and have it allow

exampleOrganization

. You might then create an object class

exampleBuildingFloor

and

would be the

Your new object classes would appear in LDAPv3 schema format as follows:

objectclasses: ( 2.16.840.1.17370.999.1.2.3 NAME 'examplePerson'

DESC 'Example Person Object Class' SUP inetorgPerson MAY

(exampleDateOfBirth $ examplePreferredOS) )

objectclasses: ( 2.16.840.1.17370.999.1.2.4 NAME

'exampleOrganization' DESC 'Organization Object Class' SUP
organization MAY (exampleBuildingFloor $ exampleVicePresident) )

Alternatively, you can create a single object class that allows all of these attributes
and use it with any entry on which you want to use these attributes. The single
object class would appear as follows:

objectclasses: (2.16.840.1.17370.999.1.2.5 NAME 'exampleEntry'
DESC 'Standard Entry Object Class' SUP top AUXILIARY MAY

(exampleDateOfBirth $ examplePreferredOS $ exampleBuildingFloor

$ exampleVicePresident) )

The new

exampleEntry

object class is marked AUXILIARY, meaning that it can be

used with any entry regardless of its structural object class.

NOTE The OID of the new object classes in the example is based on the

Red Hat OID prefix. To create your own new object classes, you
must get your own OID. For more information, refer to “Getting
and Assigning Object Identifiers,” on page 51.

Choose the strategy for defining new object classes that works for you. Consider

the following when deciding how to implement new object classes:

• Multiple object classes result in more schema elements to create and maintain.

Generally, the number of elements remains small and needs little maintenance.
However, you may find it easier to use a single object class if you plan to add
more than two or three object classes to your schema.

• Multiple object classes require a more careful and rigid data design.

Rigid data design forces you to consider the object class structure under which
every piece of data will be placed. Depending on your personal preferences,
you will find this to be either helpful or cumbersome.

Chapter 3 How to Design the Schema 53

Customizing the Schema

• Single object classes simplify data design when you have data that you want

to put on more than one type of object class structure.

For example, suppose you want
entry. You may want to create only a single object class to allow this attribute.

• Avoid required attributes for new object classes.

Requiring attributes can make your schema inflexible. When creating a new
object class, allow rather than require attributes.

After defining a new object class, you need to decide what attributes it allows and
requires and from what object class(es) it inherits.

preferredOS

on both a person and a group

Strategies for Defining New Attributes

Add new attributes and new object classes when the existing object classes do not
support all of the information you need to store in a directory entry.

Try to use standard attributes whenever possible. Search the attributes that
already exist in the default directory schema and use them in association with a
new object class. Create a new attribute if you cannot find a match in the default
directory schema.

For example, you may find that you want to store more information on a person
entry than the
support. If you want to store the birth dates in your directory, no attribute exists
within the standard Directory Server schema. You can choose to create a new
attribute called
representing people by defining a new auxiliary class,
allows this attribute.

person, organizationalPerson

dateOfBirth

and allow this attribute to be used on entries

, or

inetOrgPerson

examplePerson

object classes

, which

Deleting Schema Elements

Do not delete the schema elements shipped with Directory Server. Unused
schema elements represent no operational or administrative overhead. By
deleting parts of the standard LDAP schema, you may run into compatibility
problems with future installations of Directory Server and other
directory-enabled applications.

54 Red Hat Directory Server Deployment Guide • May 2005

Customizing the Schema

However, if you extend the schema and find you do not use the new elements, feel
free to delete the elements you don’t use. Before removing the object class
definitions from the schema, you need to modify each entry using the object class.
Otherwise, if you remove the definition first, you might not be able to modify the
entries that use the object class afterwards. Schema checks on modified entries will
also fail unless you remove the unknown object class values from the entry.

Creating Custom Schema Files

You can create custom schema files other than the

99user.ldif

file provided with
Directory Server. However, your custom schema files should not be numerically or
alphabetically higher than

The

99user.ldif

defined'

. If you create a schema file called

file contains attributes with the an

99user.ldif

or the server could experience problems.

X-ORIGIN

99zzz.ldif

, the next time you update

of

'user

the schema using LDAP or the Directory Server Console, all of the attributes with
an

X-ORIGIN

directory writes them to

value of

'user defined'

99zzz.ldif

because the directory uses the highest

will be written to

99zzz.ldif

. The

sequenced file (numerically, then alphabetically) for its internal schema
management. The result is two LDIF files that contain duplicate information, and
some information in the

99zzz.ldif

file might be erased.

When naming custom schema files, name them as follows:

[00-99]

yourname

.ldif

The directory loads these schema files in numerical order, followed by alphabetical
order. For this reason, you should use a number scheme that is higher than any
directory standard schema defined. For example,
creates a new schema file named

60examplecorp.ldif

example.com

Corporation

. If you name your schema
file something lower than the standard schema files, the server may encounter
errors when loading the schema. In addition, all standard attributes and object
classes will be loaded only after your custom schema elements have been loaded.

You should not use
files as

'user defined'

over LDAP. Use something more descriptive, such as

defined'

After you have created custom schema files, you can either:

• Manually copy these custom schema files to all of your servers, which requires

a restart of each server.

'user defined'

in the

X-ORIGIN

field of your custom schema

is used internally by the directory when schema is added

'example.com Corporation

.

Chapter 3 How to Design the Schema 55

Customizing the Schema

• Allow the replication process to replicate this information to each of the
consumers for you.

If you do not copy these custom schema files to all of your servers, the schema
information will only be replicated to the consumer when changes are made to the
schema on the supplier using LDAP or the Directory Server Console.

When the schema definitions are then replicated to a consumer server where they
do not already exist, they will be stored in the
does not track where schema definitions are stored. Storing schema elements in
the

99user.ldif

maintain your schema on the supplier server only.

If you copy your custom schema files to each server, changes to the schema files
must be copied again to each server. If you do not copy them again, it is possible
the changes will be replicated and stored in the
consumer. Having the changes in the
management difficult, as some attributes will appear in two separate schema files
on a consumer, once in the original custom schema file you copied from the
supplier and again in the

99user.ldif

file. The directory

file of consumers does not create a problem as long as you

99user.ldif

99user.ldif

99user.ldif

file may make schema

file after replication.

file on the

For more information about replicating schema, see “Schema Replication,” on
page 137.

Custom Schema Best Practices

Consider the following points when creating custom schema elements:

• If you manage your schema using LDAP or the Directory Server Console, add
all of your schema definitions to the
duplication of schema elements in multiple files. Schema elements added and
updated via LDAP are automatically written to the

If you define custom schema files, for example,
then update these schema elements using LDAP, the new definitions will be
written to the

99user.ldif

file and not to your custom schema file, thus

overriding your original custom schema definition. For example, changes to

60examplecorp.ldif
99user.ldif

.

will be overwritten by the definitions stored in

• If adding schema elements to the

X-ORIGIN
defined'

will add the

of value

'user defined'

, when the server loads the schema from the

'user defined'

value to the

in addition to what you have already specified for the

99user.ldif

99user.ldif

file to avoid possible

99user.ldif

60examplecorp.ldif

manually, always use an

. If you use something other than

99user.ldif

X-ORIGIN

portion of the definition

X-ORIGIN

file.

, and

'user

file, it

. The result is

56 Red Hat Directory Server Deployment Guide • May 2005

Maintaining Consistent Schema

that attributes that are not

'user defined'

will appear in the read-only
section of the Directory Server Console, and you will not be able to use the
Console to edit object classes that contain an

defined'

Using an
in the

.

X-ORIGIN

99user.ldif

of value

'user defined'

file are not removed from the file by the directory. The

directory does not remove them because it relies on an

defined'

to tell it what elements should reside in the

For example, you create a schema entry manually in

attributetypes: ( exampleContact-oid NAME 'exampleContact'

DESC 'Example Corporate contact' SYNTAX

1.3.6.1.4.1.1466.115.121.1.15 X-ORIGIN 'Example defined')

X-ORIGIN

other than

'user

ensures that schema definitions

X-ORIGIN

99user.ldif

99user.ldif

of

'user

file.

as follows:

After the directory loads the schema entry, it appears as follows:

attributetypes: ( exampleContact-oid NAME 'exampleContact'
DESC 'Example Corporate contact' SYNTAX

1.3.6.1.4.1.1466.115.121.1.15 X-ORIGIN ('Example defined'
'user defined') )

• When adding new schema elements, all attributes need to be defined before
they can be used in an object class. You can define attributes and object classes
in the same schema file.

• Each custom attribute or object class you create should be defined in only one
schema file. This prevents the server from overriding any previous definitions
when it loads the most recently created schema (as the server loads the schema
in numerical order first, then alphabetical order).

Maintaining Consistent Schema

A consistent schema within Directory Server aids LDAP client applications in
locating directory entries. If you use an inconsistent schema, then it becomes very
difficult to locate information in your directory tree efficiently.

Inconsistent schema use different attributes or formats to store the same
information. You can maintain schema consistency in the following ways:

• Use schema checking to ensure attributes and object classes conform to the
schema rules.

• Select and apply a consistent data format.

Chapter 3 How to Design the Schema 57

Maintaining Consistent Schema

The following sections describe in detail how to maintain consistency within your
schema.

Schema Checking

Schema checking ensures that all new or modified directory entries conform to
the schema rules. When the rules are violated, the directory rejects the requested
change.

NOTE Schema checking checks only that the proper attributes are

By default, the directory enables schema checking. We do not recommend turning
it off. For information on turning schema checking on and off, see the Red Hat
Directory Server Administrator’s Guide.

present. It does not verify whether attribute values are in the
correct syntax for the attribute.

With schema checking on, you must be attentive to required and allowed
attributes as defined by the object classes. Object class definitions usually contain
at least one required attribute and one or more optional attributes. Optional
attributes are attributes that you are allowed, but not required, to add to the
directory entry. If you attempt to add an attribute to an entry that is neither
required nor allowed according to the entry’s object class definition, then
Directory Server returns an object class violation message.

For example, if you define an entry to use the
class, then the

commonName (cn)

and

surname (sn)

organizationalPerson

attributes are required for

object

the entry (you must specify values for these attributes when you create the entry).
In addition, there is a fairly long list of attributes that you can optionally use on
the entry. This list includes such descriptive attributes as

streetAddress

, and

userPassword

.

telephoneNumber, uid

Selecting Consistent Data Formats

LDAP schema allow you to place any data that you want on any attribute value.
However, it is important to store data consistently in your directory tree by
selecting a format appropriate for your LDAP client applications and directory
users.

,

58 Red Hat Directory Server Deployment Guide • May 2005

Maintaining Consistent Schema

With the LDAP protocol and Directory Server, you must represent data in the data
formats specified in RFC 2252.

In addition, the correct LDAP format for telephone numbers is defined in the
following ITU-T Recommendations documents:

• ITU-T Recommendation E.123.

Notation for national and international telephone numbers.

• ITU-T Recommendation E.163.

Numbering plan for the international telephone services.

For example, a US phone number would be formatted as follows:

[phone]

The

postalAddress

attribute expects an attribute value in the form of a multi-line
string that uses dollar signs ($) as line delimiters. A properly formatted directory
entry appears as follows:

postalAddress: 1206 Directory Drive$Pleasant View, MN$34200

Maintaining Consistency in Replicated Schema

When you make changes to your directory schema, the changes are recorded in the
changelog. During replication, the changelog is scanned for changes, and any
changes made are replicated. Maintaining consistency in replicated schema allows
replication to continue smoothly. Consider the following points for maintaining
consistent schema in a replicated environment:

• Do not modify the schema on a read-only replica.

Modifying the schema on a read-only replica introduces an inconsistency in
your schema and causes replication to fail.

• You cannot create two attributes with the same name that use different

syntaxes.

If you create an attribute in a read-write replica that has the same name as an
attribute on the supplier replica but has a different syntax from the attribute on
the supplier, replication will fail.

Chapter 3 How to Design the Schema 59

Other Schema Resources

Other Schema Resources

Refer to the following links for more information about standard LDAPv3
schema:

• Internet Engineering Task Force (IETF)

http://www.ietf.org/

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

• RFC 2252: LDAPv3 Attribute Syntax Definitions

http://www.ietf.org/rfc/rfc2252.txt

• RFC 2256: Summary of the X.500 User Schema for Use with LDAPv3

http://www.ietf.org/rfc/rfc2256.txt

• RFC 2251: Lightweight Directory Access Protocol (v3)

http://www.ietf.org/rfc/rfc2251.txt

60 Red Hat Directory Server Deployment Guide • May 2005

Chapter 4

Designing the Directory Tree

Your directory tree provides a way to refer to the data stored by your directory.
The types of information you store in your directory, the physical nature of your
enterprise, the applications you use with your directory, and the types of
replication you use shape the design of your directory tree.

This chapter outlines the steps for designing your own directory tree. It includes
the following sections:

• Introduction to the Directory Tree (page 61)

• Designing Your Directory Tree (page 62)

• Grouping Directory Entries (page 75)

• Directory Tree Design Examples (page 78)

• Virtual Directory Information Tree Views (page 80)

• Other Directory Tree Resources (page 89)

Introduction to the Directory Tree

Your directory tree provides a means for your directory data to be named and
referred to by client applications. Your directory tree interacts closely with other
design decisions, including the choices available to you when you decide on how
to distribute, replicate, or control access to your directory data. Taking the time to
design your directory tree well before deployment saves headaches later if you
find it inadequate after you have launched your directory.

A well-designed directory tree provides the following:

• Simplified directory data maintenance.

• Flexibility in creating replication policies and access controls.

61

Designing Your Directory Tree

• Support for the applications using your directory.

• Simplified directory navigation for directory users.

The structure of your directory tree follows the hierarchical LDAP model. Your
directory tree provides a way to organize your data, for example, by group, by
people, or by place. It also determines how you partition data across multiple
servers. For example, each database needs data to be partitioned at the suffix
level. Without the proper directory tree structure, you may not be able to spread
your data across multiple servers as you would like.

In addition, replication is constrained by what sort of directory tree structure you
use. You must carefully define partitions for replication to work. If you want to
replicate only portions of your directory tree, you need to take that into account
during the design process. If you plan to use access controls on branch points,
that is also a consideration in your directory tree design.

NOTE Directory Server supports hierarchical navigation and organization

of directory information through virtual directory information tree
views. Read “Virtual Directory Information Tree Views,” on page 80,
before you design your directory tree.

Designing Your Directory Tree

This section guides you through the major decisions you make during the
directory tree design process. The directory tree design process involves the
following steps:

• Choosing a suffix to contain your data.

• Determining the hierarchical relationship among data entries.

• Naming the entries in your directory tree hierarchy.

The following sections describe the directory tree design process in more detail.

Choosing a Suffix

The suffix is the name of the entry at the root of your tree, below which you store
your directory data. Your directory can contain more than one suffix. You may
choose to use multiple suffixes if you have two or more directory trees of
information that do not have a natural common root.

62 Red Hat Directory Server Deployment Guide • May 2005

Designing Your Directory Tree

By default, the standard Directory Server deployment contains multiple suffixes,
one for storing data and the others for data needed by internal directory operations
(such as configuration information and your directory schema). For more
information on these standard directory suffixes, see the Red Hat Directory Server
Administrator’s Guide.

Suffix Naming Conventions

All entries in your directory should be located below a common base entry, the
root suffix. In naming the root directory suffix, consider the following
recommendations for what the name should be:

• Globally unique.

• Static, so it rarely changes, if ever.

• Short, so that entries beneath it are easier to read on screen.

• Easy for a person to type and remember.

In a single enterprise environment, choose a directory suffix that aligns with a DNS
name or Internet domain name of your enterprise. For example, if your enterprise
owns the domain name of

dc=example,dc=com

example.com

.

, then you should use a directory suffix of

The

dc (domainComponent)

attribute represents your suffix by breaking your

domain name into its component parts.

Normally, you can use any attribute that you like to name your root suffix.
However, for a hosting organization, we recommend that the root suffix contain
only the following attributes:

•

c (countryName)

— Contains the two-digit code representing the country

name, as defined by ISO.

•

l (localityName)

— Identifies the county, city, or other geographical area

where the entry is located or which is associated with the entry.

•

st

— Identifies the state or province where the entry resides.

•

o (organizationName)

— Identifies the name of the organization to which

the entry belongs.

The presence of these attributes allows for interoperability with subscriber
applications. For example, a hosting organization might use these attributes to
create the following root suffix for one of its clients,

o=example_a,st=Washington,c=US

example_a

:

Chapter 4 Designing the Directory Tree 63

Designing Your Directory Tree

Using an organization name followed by a country designation is typical of
the X.500 naming convention for suffixes.

Naming Multiple Suffixes

Each suffix that you use with your directory is a unique directory tree. There are
several ways that you can include multiple trees in your directory. The first is to
create multiple directory trees stored in separate databases served by Directory
Server. For example, you could create separate suffixes for

example_b

example_a

and store them in separate databases as shown below:

and

The databases could be stored on a single server or multiple servers depending
upon resource constraints.

Creating Your Directory Tree Structure

You need to decide whether you use a flat or hierarchical tree structure. As a
general rule, strive to make your directory tree as flat as possible. However, a
certain amount of hierarchy can be important later when you partition data across
multiple databases, prepare replication, and set access controls.

The structure of your tree involves the following steps and considerations:

• Branching Your Directory

• Identifying Branch Points

• Replication Considerations

• Access Control Considerations

64 Red Hat Directory Server Deployment Guide • May 2005

Designing Your Directory Tree

Branching Your Directory

Design your hierarchy to avoid problematic name changes. The flatter a namespace
is, the less likely the names are to change. The likelihood of a name changing is
roughly proportional to the number of components in the name that can
potentially change. The more hierarchical the directory tree, the more components
in the names, and the more likely the names are to change.

Following are some guidelines for designing your directory tree hierarchy:

• Branch your tree to represent only the largest organizational subdivisions in
your enterprise.

Any such branch points should be limited to divisions (Corporate Information
Services, Customer Support, Sales and Professional Services, and so forth).
Make sure that divisions you use to branch your directory tree are stable; do
not perform this kind of branching if your enterprise reorganizes frequently.

• Use functional or generic names rather than actual organizational names for
your branch points.

Names change, and you do not want to have to change your directory tree
every time your enterprise renames its divisions. Instead, use generic names
that represent the function of the organization (for example, use
instead of

Widget Research and Development

).

Engineering

• If you have multiple organizations that perform similar functions, try creating
a single branch point for that function instead of branching based along
divisional lines.

For example, even if you have multiple marketing organizations, each of which
is responsible for a specific product line, create a single Marketing subtree. All
marketing entries then belong to that tree.

Following are specific guidelines for the enterprise and hosting environment.

Branching in an Enterprise Environment

Name changes can be avoided if you base your directory tree structure on
information that is not likely to change. For example, base the structure on types of
objects in the tree rather than organizations. Some of the objects you might use to
define your structure are:

•

ou=people

•

ou=groups

•

ou=contractors

•

ou=employees

Chapter 4 Designing the Directory Tree 65

Designing Your Directory Tree

•

ou=services

A directory tree organized using these objects might appear as shown below.

Branching in a Hosting Environment

For a hosting environment, create a tree that contains two entries of the object
class

organization (o)

class beneath the root suffix. For example, the ISP
directory as shown below.

and one entry of the

organizationalUnit (ou)

example

branches their

object

Identifying Branch Points

As you decide how to branch your directory tree, you will need to decide what
attributes you will use to identify the branch points. Remember that a DN is a
unique string composed of attribute-data pairs. For example, the DN of an entry
for Barbara Jensen, an employee of

uid=Barbara Jensen,ou=people,dc=example,dc=com

Each attribute-data pair represents a branch point in your directory tree. For
example, the directory tree for the enterprise
as follows:

66 Red Hat Directory Server Deployment Guide • May 2005

example.com

example.com

Corporation, appears as follows:

Corporation appears

Designing Your Directory Tree

The directory tree for

Beneath the root suffix entry
The ISP branch contains customer data and internal information for

example

, an Internet host, appears as follows:

o=example,c=US

, the tree is split into three branches.

example

. The
Internet branch is the domain tree. The groups branch contains information about
the administrative groups.

There are some points to consider when choosing attributes for your branch points:

• Be consistent.

Some LDAP client applications may be confused if the distinguished name
(DN) format is inconsistent across your directory tree. That is, if l is
subordinate to o in one part of your directory tree, then make sure l is
subordinate to o in all other parts of your directory.

• Try to use only the traditional attributes (shown in Table 4-1).

Using traditional attributes increases the likelihood of retaining compatibility
with third-party LDAP client applications. Using the traditional attributes also
means that they will be known to the default directory schema, which makes it
easier to build entries for the branch DN.

Chapter 4 Designing the Directory Tree 67

Designing Your Directory Tree

Table 4-1Traditional DN Branch Point Attributes

Attribute Name Definition

c A country name.

o An organization name. This attribute is typically used to

ou An organizational unit. This attribute is typically used to

st A state or province name.

l A locality, such as a city, country, office, or facility name.

dc A domain component as discussed in “Suffix Naming

represent a large divisional branching such as a corporate
division, academic discipline (the humanities, the sciences),
subsidiary, or other major branching within the enterprise. You
should also use this attribute to represent a domain name as
discussed in “Suffix Naming Conventions,” on page 63.

represent a smaller divisional branching of your enterprise than
an organization. Organizational units are generally subordinate
to the preceding organization.

Conventions,” on page 63.

NOTE A common mistake is to assume that you search your directory

based on the attributes used in the distinguished name. However,
the distinguished name is only a unique identifier for the directory
entry and cannot be searched against.

Instead, search for entries based on the attribute-data pairs stored
on the entry itself. Thus, if the distinguished name of an entry is

uid=Babs Jensen,ou=People,dc=example,dc=com

for

dc=example

put

dc:example

Replication Considerations

During directory tree design, consider which entries you are replicating. A
natural way to describe a set of entries to be replicated is to specify the
distinguished name (DN) at the top of a subtree and replicate all entries below it.
This subtree also corresponds to a database, a directory partition containing a
portion of the directory data.

68 Red Hat Directory Server Deployment Guide • May 2005

, then a search

will not match that entry unless you have explicitly

as an attribute in that entry.

Designing Your Directory Tree

For example, in an enterprise environment, you can organize your directory tree so
that it corresponds to the network names in your enterprise. Network names tend
not to change, so the directory tree structure will be stable. Further, using network
names to create the top level branches of your directory tree is useful when you use
replication to tie together different Directory Servers.

For instance,

flightdeck.example.com, tickets.example.com

example.com

Corporation has three primary networks known as

, and

hanger.example.com

They initially branch their directory tree as follows:

After creating the initial structure of the tree, they create additional branches as
follows:

.

As another example, the ISP

example.com

branches their directory as follows:

Chapter 4 Designing the Directory Tree 69

Designing Your Directory Tree

After creating the initial structure of their directory tree, they create additional
branches as follows:

Both the enterprise and the hosting organization design their data hierarchies
based on information that is not likely to change often.

Access Control Considerations

Introducing hierarchy into your directory tree can be used to enable certain types
of access control. As with replication, it is easier to group together similar entries
and then administer them from a single branch.

You can also enable the distribution of administration through a hierarchical
directory tree. For example, if you want to give an administrator from the
marketing department access to the marketing entries and an administrator from
the sales department access to the sales entries, you can do so through your
directory tree design.

70 Red Hat Directory Server Deployment Guide • May 2005

Designing Your Directory Tree

You can set access controls based on the directory content rather than the directory
tree. The ACI filtered target mechanism lets you define a single access control rule
stating that a directory entry has access to all entries containing a particular
attribute value. For example, you could set an ACI filter that gives the sales
administrator access to all the entries containing the attribute

ou=Sales

.

However, ACI filters can be difficult to manage. You must decide which method of
access control is best suited to your directory: organizational branching in your
directory tree hierarchy, ACI filters, or a combination of the two.

Naming Entries

After designing the hierarchy of your directory tree, you need to decide which
attributes to use when naming the entries within the structure. Generally, names
are created by choosing one or more of the attribute values to form a relative
distinguished name (RDN). The RDN is the left-most DN attribute value. The
attributes you use depend on the type of entry you are naming.

Your entry names should adhere to the following rules:

• The attribute you select for naming should be unlikely to change.

• The name must be unique across your directory.

A unique name ensures that a DN can refer to at most one entry in your directory.

When creating entries, define the RDN within the entry. By defining at least the
RDN within the entry, you can locate the entry more easily. This is because
searches are not performed against the actual DN but rather the attribute values
stored in the entry itself.

Attribute names have a meaning, so try to use the attribute name that matches the
type of entry it represents. For example, do not use
organization, or

c (country)

to represent an organizational unit.

l (locality)

to represent an

The following sections provide tips on naming entries:

• Naming Person Entries

• Naming Group Entries

• Naming Organization Entries

• Naming Other Kinds of Entries

Chapter 4 Designing the Directory Tree 71

Designing Your Directory Tree

Naming Person Entries

The person entry’s name, the DN, must be unique. Traditionally, distinguished
names use the
an entry for a person named Babs Jensen might have the distinguished name of:

cn=Babs Jensen,dc=example,dc=com

While allowing you to recognize instantly the person associated with the entry, it
might not be unique enough to exclude people with identical names. This quickly
leads to a problem known as DN name collisions, multiple entries with the same
distinguished name.

You can avoid common name collisions by adding a unique identifier to the
common name. For example:

cn=Babs Jensen+employeeNumber=23,dc=example,dc=com

However, this can lead to awkward common names for large directories and can
be difficult to maintain.

A better method is to identify your person entries with some attribute other than

cn

. Consider using one of the following attributes:

commonName

, or cn, attribute to name their person entries. That is,

•

uid

Use the

uid (userID)

attribute to specify some unique value of the person.
Possibilities include a user login ID or an employee number. A subscriber in a
hosting environment should be identified by the

•

mail

Use the

mail

attribute to contain the value for the person’s email address.

uid

attribute.

This option can lead to awkward DNs that include duplicate attribute values
(for example:

mail=[e-mail], dc=example,dc=com

), so you
should use this option only if you cannot find some unique value that you can
use with the
instead of the

uid

attribute. For example, you would use the

uid

attribute if your enterprise does not assign employee

mail

attribute

numbers or user IDs for temporary or contract employees.

•

employeeNumber

For employees of the
employer assigned attribute value such as

inetOrgPerson

object class, consider using an

employeeNumber

.

72 Red Hat Directory Server Deployment Guide • May 2005

Designing Your Directory Tree

Whatever you decide to use for an attribute-data pair for person entry RDNs, you
should make sure that they are unique, permanent values. Person entry RDNs
should also be readable. For example,
preferable to

uid=b12r56A, dc=example,dc=com

uid=bjensen, dc=example,dc=com

because recognizable DNs

is

simplify some directory tasks, such as changing directory entries based on their
distinguished names. Also, some directory client applications assume that the

uid

and cn attributes use human-readable names.

Considerations for Person Entries in a Hosted Environment

If a person is a subscriber to a service, the entry should be of object class
and the entry should contain the

uid

attribute. The attribute must be unique within

a customer subtree.

inetUser,

If a person is part of the hosting organization, represent them as an
with the

nsManagedPerson

object class.

inetOrgPerson

Placing Person Entries in the DIT

Here are some guidelines for placing people entries in your directory tree:

• People in an enterprise should be located in the directory tree below the
organization’s entry.

• Subscribers to a hosting organization need to be below the

ou=people

branch

for the hosted organization.

Naming Group Entries

There are four main ways to represent a group:

• A static group — The entry for this type of group uses the

groupOfUniqueNames

object class, which contains values naming the members
of the group. Static groups are suitable for groups with few members, such as
the group of directory administrators. Static groups are not suitable for groups
with thousands of members.

Static group entries must contain a

uniqueMember

is a mandatory attribute of the

uniqueMember

groupOfUniqueNames

attribute value because

This object class requires the cn attribute, which can be used to form the DN of
the group entry.

groupOfNames

object.

or

• A member-based group — This type of group uses a
entry of each group member.

• A dynamic group — This type of group uses an entry representing the group
with a search filter and subtree. Entries matching the filter are members of the
group.

memberOf

Chapter 4 Designing the Directory Tree 73

attribute in the

Designing Your Directory Tree

• A Directory Server role—Roles unify the static and dynamic group concept.
Refer to “About Roles,” on page 75, for more information.

In a deployment containing hosted organizations, we recommend using the

groupOfUniqueNames

groups used in directory administration. In a hosted organization, we also
recommend that group entries used for directory administration be located under
the

ou=Groups

Naming Organization Entries

The organization entry name, like other entry names, must be unique. Using the
legal name of the organization along with other attribute values helps ensure the
name is unique. For example, you might name an organization entry as follows:

o=example_a+st=Washington,o=ISP,c=US

You can also use trademarks; however, they are not guaranteed to be unique.

In a hosting environment, you need to include the following attributes in the
organization’s entry:

object class to contain the values naming the members of

branch.

•

o (organizationName)

•

objectClass

with values of

top, organization

, and

nsManagedDomain

Naming Other Kinds of Entries

Your directory will contain entries that represent many things, such as localities,

states, countries, devices, servers, network information, and other kinds of data.

For these types of entries, use the

possible. Then, if you are naming a group entry, name it as follows:

cn=administrators,dc=example,dc=com

However, sometimes you need to name an entry whose object class does not

support the

commonName

attribute. Instead, use an attribute that is supported by

the entry’s object class.

There does not have to be any correspondence between the attributes used for the

entry’s DN and the attributes actually used in the entry. However, a
correspondence between the DN attributes and attributes used by the entry
simplifies administration of your directory tree.

commonName (cn)

attribute in the RDN if

74 Red Hat Directory Server Deployment Guide • May 2005

Grouping Directory Entries

Once you have created entries, you can group them for ease of administration. The
Directory Server supports several methods for grouping entries and sharing
attributes between entries:

• Using roles

• Using class of service

The following sections describe each of these mechanisms in more detail.

About Roles

Roles are an entry grouping mechanism. Your directory tree organizes information
hierarchically. This hierarchy is a grouping mechanism, though it is not suited for
short-lived, changing organizations. Roles provide another grouping mechanism
for more temporary organizational structures.

Grouping Directory Entries

Roles unify static and dynamic groups. You use static groups to create a group
entry that contains a list of members. Dynamic groups allow you to filter entries
that contain a particular attribute and include them in a single group.

Each entry assigned to a role contains the
that specifies all of the roles an entry belongs to. A client application can check role
membership by searching the
and therefore always up-to-date.

Roles are designed to be more efficient and easier to use for applications. For
example, applications can locate the roles of an entry rather than select a group and
browse the members list.

You can use roles to do the following:

• Enumerate the members of the role.

Having an enumerated list of role members can be useful for resolving queries
for group members quickly.

• Determine whether a given entry possesses a particular role.

Knowing the roles possessed by an entry can help you determine whether the
entry possesses the target role.

nsRole

nsRole

attribute, which is computed by the directory

attribute, a computed attribute

• Enumerate all the roles possessed by a given entry.

• Assign a particular role to a given entry.

Chapter 4 Designing the Directory Tree 75

Grouping Directory Entries

• Remove a particular role from a given entry.

Each role has members, entries that possess the role. You can specify members
either explicitly (meaning each entry contains an attribute associating it with a
role) or dynamically (by creating a filter that assigns entries to roles depending
upon an attribute contained by the entry). How you specify role membership
depends upon the type of role you are using. There are three types of roles:

• Managed roles — A managed role allows you to create an explicit,
enumerated list of members. Managed roles are added to entries using the

nsRoleDN

• Filtered roles — A filtered role allows you to assign entries to the role
depending upon the attribute contained by each entry. You do this by
specifying an LDAP filter. Entries that match the filter are said to possess the
role.

• Nested roles — A nested role allows you to create roles that contain other
roles. You specify the roles nested within it using the

attribute.

nsRoleDN

attribute.

Deciding Between Roles and Groups

Both methods of grouping entries have advantages and disadvantages. Roles
reduce client-side complexity at the cost of increased server complexity. With
roles, the client application can check role membership by searching the
attribute. From the client application point of view, the method for checking
membership is uniform and is performed on the server side.

Dynamic groups, from an application point of view, offer no support from the
server to provide a list of group members. Instead, the application retrieves the
group definitions and then runs the filter. For static groups, the application must
make sure the user is part of a particular

UniqueMember

attribute value. The

method for determining group membership is not uniform.

You can use managed roles to do everything you would normally do with static
groups. You can filter group members using filtered roles as you used to do with
dynamic groups.

While roles are easier to use, more flexible, and reduce client complexity, they do
so at the cost of increased server complexity. Determining role membership is
more resource intensive because the server does the work for the client
application.

nsRole

76 Red Hat Directory Server Deployment Guide • May 2005

Grouping Directory Entries

About Class of Service

A class of service (CoS) allows you to share attributes between entries in a way that
is invisible to applications. With CoS, some attribute values may not be stored with
the entry itself. Instead, they are generated by class of service logic as the entry is
sent to the client application.

For example, your directory contains thousands of entries that all share the
common attribute
number, you would need to update each entry individually, a large job for
administrators that runs the risk of not updating all entries. With CoS, you can
generate the attribute dynamically. The
stored in one place, and each entry points to that place to give a value to their fax
number attribute. For the application, these attributes appear just like all other
attributes despite not actually being stored on the entries themselves.

Each CoS is comprised of the following entries in your directory:

• CoS Definition Entry — The CoS definition entry identifies the type of CoS you
are using. It is stored as an LDAP subentry below the branch it affects.

facsimileTelephoneNumber

facsimileTelephoneNumber

. Traditionally, to change the fax

attribute is

• Template Entry — The template entry contains a list of the shared attribute
values. Changes to the template entry attribute values are automatically
applied to all the entries sharing the attribute.

The CoS definition entry and the template entry interact to provide attribute values
to their target entries, the entries within their scope. The value they provide
depends upon the following:

• The entry’s DN (different portions of the directory tree might contain different
CoS).

• A service class attribute value stored with the entry.

The absence of a service class attribute can imply a specific default CoS.

• The attribute value stored in the CoS template entry.

Each CoS template entry supplies the attribute value for a particular CoS.

• The object class of the entry.

CoS attribute values are generated only when an entry contains an object class
allowing the attribute when schema checking is turned on; otherwise, all
attribute values are generated.

• The attribute stored in some particular entry in the directory tree.

Chapter 4 Designing the Directory Tree 77

Directory Tree Design Examples

You can use different types of CoS depending upon how you want the value of
your dynamic attributes to be generated. There are three types of CoS:

• Pointer CoS — A pointer CoS identifies the template entry using the template
DN only. There may be only one template DN for each pointer CoS. A pointer
CoS applies to all entries within the scope of the template entry.

• Indirect CoS — An indirect CoS identifies the template entry using the value
of one of the target entry’s attributes. The target entry’s attribute must contain
the DN of an existing entry.

• Classic CoS — A classic CoS identifies the template entry by both its DN and
the value of one of the target entry’s attributes. Classic CoS can have multiple
template entries, including a default CoS template to be applied to those
entries that do not belong to any other CoS template.

Roles and the classic CoS can be used together to provide role-based attributes.
These attributes appear on an entry because it possesses a particular role with an
associated class of service template. For example, you could use a role-based
attribute to set the server look through limit on a role-by-role basis.

Directory Tree Design Examples

The following sections provide examples of directory trees designed to support a
flat hierarchy as well as several examples of more complicated hierarchies.

Directory Tree for an International Enterprise

To support an international enterprise, root your directory tree in your Internet
domain name, and then branch your tree for each country where your enterprise
has operations immediately below that root point. In “Suffix Naming
Conventions,” on page 63, you are advised to avoid rooting your directory tree in
a country designator. This is especially true if your enterprise is international in
scope.

Because LDAP places no restrictions on the order of the attributes in your DNs,
you can use the
follows:

c (countryName)

attribute to represent each country branch as

78 Red Hat Directory Server Deployment Guide • May 2005

Directory Tree Design Examples

However, some administrators feel that this is stylistically awkward, so instead
you could use the

l (locality)

attribute to represent different countries:

Directory Tree for an ISP

Internet service providers (ISPs) may support multiple enterprises with their
directories. If you are an ISP, consider each of your customers as a unique
enterprise and design their directory trees accordingly. For security reasons, each
account should be provided a unique directory tree with a unique suffix and an
independent security policy.

You can assign each customer a separate database and store these databases on
separate servers. Placing each directory tree in its own database allows you to back
up and restore data for each directory tree without affecting your other customers.

In addition, partitioning helps reduce performance problems caused by disk
contention and reduces the number of accounts potentially affected by a disk
outage.

For example, the directory tree for

example

, an ISP, appears as follows:

Chapter 4 Designing the Directory Tree 79

Virtual Directory Information Tree Views

Virtual Directory Information Tree Views

Directory Server supports a concept for hierarchical navigation and organization

of directory information called virtual directory information tree views or virtual DIT
views.

• Overview

• Introduction to Virtual DIT Views

• Advantages of Using Virtual DIT Views

• Example of Virtual DIT Views

• Views and Other Directory Features

• Effects of Virtual Views on Performance

• Compatibility with Existing Applications

NOTE Virtual views are not entirely compatible with multiple backends in

that the entries to be returned by the views must reside in the same
backend; the search is limited to one backend.

80 Red Hat Directory Server Deployment Guide • May 2005

Virtual Directory Information Tree Views

Overview

When considering directory namespace, you have the choice of creating either of

the following:

• A hierarchical directory information tree.

• A flat directory information tree.

The hierarchical DIT is useful for navigating the directory but is cumbersome and

time-consuming to change. The flat DIT, while requiring little to no change, does

not provide a convenient way to navigate or manage the entries in the directory. A

flat DIT also presents many management challenges as administration becomes

more complex without any natural hierarchical groupings. On the other hand, a

major organizational change to a hierarchical DIT can be an expensive and

time-consuming operation as it usually involves considerable service disruption,

which can only be minimized by operating during late hours and periods of low

traffic. Also, moving millions of entries from one place in a hierarchy to another is a

lot of work.

Figure 4-1 shows examples of a flat and an organizationally-based DIT.

Figure 4-1 Examples of a Flat and an Organizationally-Based DIT

Having decided upon a hierarchical DIT, a deployment must then decide upon the

subject domain of the hierarchy. Only one choice can be made, and that tends to

mean that only one natural choice is available: the organizational hierarchy.

Chapter 4 Designing the Directory Tree 81

Virtual Directory Information Tree Views

This view of the organization serves well in many cases, but having just this one
view can be very limiting for directory navigation and management. For example,
an organization hierarchy is fine if you are looking for entries belonging to people
in the Accounts department. However, this view is much less useful for finding
entries that belong to people in a geographical location, such as Mountain View,
California. The second query is equally valid as the first one, yet it requires
knowledge of the attributes contained in the entries and additional search tools.
For such a case, navigation via the DIT is not an option.

In a similar vein, management of the directory is made very much easier by
having a DIT that matches the requirements of the management function. The
organization of your DIT may be affected by other factors, too, such as replication
and migration considerations, that cause the DIT to have functional utility for
those applications but very little practical utility in other cases.

From the above discussion, it is clear that hierarchies are a useful mechanism for
navigation and management. Yet, to avoid the burden of making changes to an
existing DIT, a deployment may elect to forgo a hierarchy altogether in favor of a
flat DIT.

It would be advantageous for deployments if the directory provided a way to
create an arbitrary number of hierarchies that get mapped to entries without
having to move the target entries in question. The virtual DIT views feature of
Directory Server resolves the quandary of deciding the DIT type you should elect
for your directory deployment.

Introduction to Virtual DIT Views

Virtual DIT views are a way to navigate hierarchically entries that do not require
the physical existence of those entries in any particular place. The virtual DIT
view uses information about the entries to place them in the view hierarchy. To
client applications, virtual DIT views look just like ordinary container hierarchies.
In a sense, virtual DIT views superimpose a DIT hierarchy over a set of entries,
irrespective of whether those entries are in a flat namespace or in another
hierarchy of their own.

Creating a virtual DIT view hierarchy is just like creating a normal DIT hierarchy.
You create the same entries (for example, organizational unit entries) but with an
additional object class (
describes the view. Once you add the additional attribute, the entries that match
the view filter will instantly populate the view. The target entries only appear to
exist in the view; their true location never changes. Virtual DIT views act just like
normal DITs in that a subtree or a one-level search can be performed with the
expected results being returned.

nsview

) and a filter attribute (

nsviewfilter

) that

82 Red Hat Directory Server Deployment Guide • May 2005

Virtual Directory Information Tree Views

For information about adding and modifying entries, refer to chapter 2 , “Creating

Directory Entries,” in the Red Hat Directory Server Administrator’s Guide

Figure 4-2 A Combined DIT With Added Features Using Views

The DIT shown in Figure 4-2 illustrates what happens when the two DITs shown in

Figure 4-1 are combined using views. Because views inherently allow entries to

appear in more than one place in a view hierarchy, this feature has been used to

expand the

ou=Sales

entry to enable viewing the Sales entries either by location or

by product.

Given a set of virtual DIT view hierarchies, a directory user can navigate using the

view that makes the most sense to get to the required entries. For example, if your

target entries were those which dwell in

Mountain View

, a view which starts out
navigating down using location-based information is most appropriate. If it were
an organizational question, the organization view would work better. Both of these
views exist in the Directory Server at the same time and operate on the same
entries—they just have different concerns or objectives when displaying their
version of the directory structure.

The entries in the views-enabled directory depicted in Figure 4-2 are contained in a
flat namespace just below the parent of the top most view in the hierarchy. This is
not required. The entries can exist in a hierarchy of their own. The only concern
that a view has about the placement of an entry is that it must be a descendent of
the parent of the view hierarchy.

Chapter 4 Designing the Directory Tree 83

Virtual Directory Information Tree Views

Figure 4-3 A DIT With a Virtual DIT View Hierarchy

The DIT illustrated in Figure 4-3 shows a view hierarchy.

• The sub-tree

• The subtree

• The leaf nodes
attribute

ou=People

ou=Location Views

ou=Sunnyvale

nsviewfilter

contains the real

, which describes the view.

Entry A

is a view hierarchy.

and

ou=Mountain View

and

Entry B

each contain an

entries.

These are leaf nodes because they do not contain the real entries. However, when
a client application searches these views, it will find

ou=Sunnyvale

is described by the

and

Entry B

nsviewfilter

under

ou=Mountain View

attributes of all ancestor views. A search made

Entry A

under

. This virtual search space

from a view will return both entries from the virtual search space and those from
the actual search space. This enables the view hierarchies to function as a
conventional DIT or turn a conventional DIT into a view hierarchy.

84 Red Hat Directory Server Deployment Guide • May 2005

Virtual Directory Information Tree Views

Advantages of Using Virtual DIT Views

Your deployment decisions become easier with virtual DIT views:

• Views facilitate use of flat namespace for entries because virtual DIT views
provide navigational and managerial support similar to the ones provided by
traditional hierarchies.

In addition, whenever there is a change to the DIT, the entries will never need

to be moved; only the virtual DIT view hierarchies will change. Because these
hierarchies contain no real entries, they are simple and quick to modify.

• Oversights during deployment planning are less catastrophic with virtual DIT
views. If the hierarchy is not quite right, it can be changed easily and quickly
without disrupting the service.

• View hierarchies may be completely revised in minutes and the results
instantly realized, significantly reducing the cost of directory maintenance.

Changes to a virtual DIT hierarchy are instantly realized. When an
organizational change occurs, a new virtual DIT view can be created quickly.
The new virtual DIT view can exist at the same time as the old virtual DIT
view, thereby facilitating a more gradual changeover for the entries themselves
and for the applications that operate on them. Because an organizational
change in the directory isn’t an all-or-nothing operation, it may be performed
over a period of time and without service disruption.

• Using multiple virtual DIT views for navigation and management allows for
more flexible use of the directory.

With the functionality provided by virtual DIT views, an organization can use
both the old and new ways to organize directory data without any requirement
to place entries at certain points in the DIT.

• Virtual DIT view hierarchies can be created as a kind of ready-made query to
facilitate retrieval of commonly-required information.

• Views promote flexibility in working practices and reduce the requirement that
directory users create complex search filters filled with attribute names and
values that they would otherwise have no need to know.

The flexibility of having more than one way to view and query directory

information allows end users and applications to find what they need
intuitively through hierarchical navigation.

Chapter 4 Designing the Directory Tree 85

Virtual Directory Information Tree Views

Example of Virtual DIT Views

The LDIF entries below show a virtual DIT view hierarchy that is based on
location. Any entry which resides below
description will appear in this view, organized by location.

dn: ou=Location Views,dc=example,dc=com
objectclass: top
objectclass: organizationalUnit
objectclass: nsView
ou: Location Views
description: views categorized by location

dn: ou=Sunnyvale, ou=Location Views,dc=example,dc=com
objectclass: top
objectclass: organizationalUnit
objectclass: nsView
ou: Sunnyvale
nsViewFilter: (l=Sunnyvale)
description: views categorized by location

dc=example,dc=com

and fits the view

dn: ou=Santa Clara, ou=Location Views,dc=example,dc=com
objectclass: top
objectclass: organizationalUnit
objectclass: nsView
ou: Santa Clara
nsViewFilter: (l=Santa Clara)
description: views categorized by location

dn: ou=Cupertino, ou=Location Views,dc=example,dc=com
objectclass: top
objectclass: organizationalUnit
objectclass: nsView
ou: Cupertino
nsViewFilter: (l=Cupertino)
description: views categorized by location

A subtree search based at
return all entries below

(l=Sunnyvale), (l=Santa Clara)

ou=Location Views, dc=example,dc=com

dc=example,dc=com

, or

which match the filters

(l=Cupertino)

, whereas a one-level

would

search would return no entries other than the child view entries because all
qualifying entries reside in the three descendent views.

86 Red Hat Directory Server Deployment Guide • May 2005

Virtual Directory Information Tree Views

The

ou=Location Views, dc=example,dc=com

view entry itself does not contain
a filter. This feature facilitates hierarchical organization without the requirement to
restrict the entries contained in the view further. Any view may omit the filter.
Although the example filters are very simple, the filter used may be as complex as
necessary.

It may be desirable to limit the type of entry that the view is to contain. For

example, to limit this hierarchy to contain only people entries, simply add an

nsfilter

value

attribute to

(objectclass=organizationalperson)

ou=Location Views, dc=example,dc=com

with the filter

.

Each view with a filter restricts the content of all descendent views while
descendent views with filters also restrict their ancestor’s contents. For example,
creating the top view

ou=Location Views

first along with the new filter would
create a view with all entries with the organizational object class. When you add
the descendent views that further restrict entries, the entries that now appear in the
descendent views are removed from the ancestor views. This demonstrates how
virtual DIT views mimic the behavior of traditional DITs.

Although virtual DIT views mimic the behavior of traditional DITs, views can do
something that traditional DITs cannot: entries may appear in more than one place.
For example, if it were required that

View

and

Sunnyvale

simply adding the

(see Figure 4-3, on page 84), you can accomplish that by

Sunnyvale

value to the location attribute, and the entry would

Entry B

be associated with both

Mountain

appear in both views.

Views and Other Directory Features

Both class of service and roles features of the Directory Server support views; see
“Grouping Directory Entries,” on page 75. When adding a class of service or a role
under a view hierarchy, the entries that are both logically and actually contained in
the view are considered within scope; for information on using these features, refer
to chapter 5, “Advanced Entry Management,” in the Red Hat Directory Server
Administrator’s Guide. This means that roles and class of service can be applied
using a virtual DIT view, but the effects of that application can be seen even when
querying the flat namespace.

Access control with views must be performed slightly differently than is usual.

Because there is currently no explicit support for ACLs in views, it is recommended

that you create role-based ACIs at the view parent and add the roles to the

appropriate parts of the view hierarchy. In this way, you can take advantage of the

organizational property of the hierarchy.

Chapter 4 Designing the Directory Tree 87

Virtual Directory Information Tree Views

To clarify any doubts that you have about the effects of views on searching,
understand that if the base of the search is a view and the scope of the search is
not a base, then it is a views-based search. Otherwise, it is a conventional search.
For example, if you perform a search with a base of
entries from the virtual search space will be returned — in fact, no
virtual-search-space search is performed. Views processing occurs only if the
search base is
search does not result in entries from both places (you would would get entries
back from both places if it were a conventional DIT).

ou=Location Views

Effects of Virtual Views on Performance

The performance of views-based hierarchies is dependent on the make up of the
hierarchy itself and the number of entries in the DIT. In general, you may see a
marginal change in performance (within a few percentage points of equivalent
searches on a conventional DIT) if virtual DIT views are enabled in your
directory. If a search does not invoke a view, then there is no performance impact.
As always, we recommend that before deployment, you must test your virtual
DIT views against expected search patterns and loads.

dc=example,dc=com

(or below). This way, views ensure that your

, then no

We also recommend that the attributes used in view filters be indexed if the views
are to be used as general-purpose navigation tools in the organization. Further,
when a sub-filter used by views matches a configured virtual list view index, that
index will be used in views evaluation.

There is no need to tune any other part of the directory specifically for views.

Compatibility with Existing Applications

Virtual DIT views are designed to mimic conventional DITs to a high degree.
Most applications should continue to work without any knowledge that they are
working with views. Except for a few specialized cases, there is no need for
directory users to know that views are being used in a Directory Server
instance—views look and act like conventional DITs.

Certain types of applications may have problems working with a views-enabled
directory. For example:

• Applications that use the DN of a target entry to navigate up the DIT. That

type of application would find that it is navigating up the hiearchy in which
the entry physically exists instead of the view hiearchy in which the entry
was found. The reason for this is that views make no attempt to disguise the

88 Red Hat Directory Server Deployment Guide • May 2005

Other Directory Tree Resources

true location of an entry by changing the DN of the entry to conform to the
views hierarchy. This is by design — many applications would not function if
the true location of an entry were disguised, such as those applications that
rely on the DN to identify a unique entry. This upward navigation by
deconstructing a DN is an unusual technique for a client application, but,
nonetheless, those clients that do this may not function as intended.

• Applications that use the

numSubordinates

operational attribute to determine
how many entries exist beneath a node. For views nodes, this is currently a
count of only those entries that exist in the real search space, ignoring the
virtual search space. Applications may not evaluate the view with a search as a
result of this.

Other Directory Tree Resources

Take a look at the following links for more information about designing your
directory tree:

• RFC 2247: Using Domains in LDAP/X.500 Distinguished Names

http://www.ietf.org/rfc/rfc2247.txt

• RFC 2253: LDAPv3, UTF-8 String Representation of Distinguished Names

http://www.ietf.org/rfc/rfc2253.txt

Chapter 4 Designing the Directory Tree 89

Other Directory Tree Resources

90 Red Hat Directory Server Deployment Guide • May 2005

Chapter 5

Designing the Directory Topology

In chapter 4, “Designing the Directory Tree,” you designed how your directory
stores entries. Because Red Hat Directory Server (Directory Server) can store a
large quantity of entries, you may need to distribute your entries across more than
one server. Your directory’s topology describes how you divide your directory tree
among multiple physical Directory Servers and how these servers link with one
another.

This chapter describes planning the topology of your directory. It contains the
following sections:

• Topology Overview (page 91)

• Distributing Your Data (page 92)

• About Knowledge References (page 96)

• Using Indexes to Improve Database Performance (page 108)

Topology Overview

You can design your deployment of Directory Server to support a distributed
directory where the directory tree you designed in chapter 4, “Designing the
Directory Tree,” is spread across multiple physical Directory Servers. The way you
choose to divide your directory across servers helps you accomplish the following:

• Achieve the best possible performance for your directory-enabled applications.

• Increase the availability of your directory.

• Improve the management of your directory.

91

Distributing Your Data

The database is the basic unit you use for jobs such as replication, performing
backups, and restoring data. You can carve a single directory into manageable
chunks and assign them to separate databases. These databases can then be
distributed among a number of servers, reducing the workload for each server.
You can store more than one database on a single server. For example, one server
might contain three different databases.

When you divide your directory tree across several databases, each database
contains a portion of your directory tree, called a suffix. For example, you can use
a database to store the entries in the
branch, of your directory tree.

When you divide your directory among several servers, each server is responsible
for only a part of the directory tree. The distributed directory works similarly to
the Domain Name Service (DNS), which assigns each portion of the DNS
namespace to a particular DNS server. Likewise, you can distribute your
directory namespace across servers while maintaining a directory that, from a
client’s point of view, appears to be a single directory tree.

The Directory Server also provides knowledge references, mechanisms for linking
directory data stored in different databases. Directory Server includes two types
of knowledge references, referrals and chaining.

ou=people,dc=example,dc=com

suffix, or

The remainder of this chapter describes databases and knowledge references,
explains the differences between the two types of knowledge references, and
describes how you can design indexes to improve the performance of your
databases.

Distributing Your Data

Distributing your data allows you to scale your directory across multiple servers
without physically containing those directory entries on each server in your
enterprise. A distributed directory can thus hold a much larger number of entries
than would be possible with a single server.

In addition, you can configure your directory to hide the distributing details from
the user. As far as users and applications are concerned, there is simply a single
directory that answers their directory queries.

The following sections describe the mechanics of data distribution in more detail:

• About Using Multiple Databases

• About Suffixes

92 Red Hat Directory Server Deployment Guide • May 2005

Distributing Your Data

About Using Multiple Databases

Directory Server stores data in LDBM databases.The LDBM database is a
high-performance, disk-based database. Each database consists of a set of large
files that contains all of the data assigned to it.

You can store different portions of your directory tree in different databases. In that
instance, your directory tree appears as follows:

You can also store the data of the three suffixes in three separate databases, as
shown below:

When you divide your directory tree among a number of databases, these
databases can then be distributed across multiple servers. For example, the three
databases you created to contain the three suffixes of your directory tree can be
stored on two servers, as follows:

Server A contains databases one and two, and server B contains database three.

Chapter 5 Designing the Directory Topology 93

Distributing Your Data

Distributing databases across multiple servers reduces the amount of work each
server needs to do. Thus, the directory can be made to scale to a much larger
number of entries than would be possible with a single server.

In addition, Directory Server supports adding databases dynamically, meaning
you can add new databases when your directory needs them without taking your
entire directory off-line.

About Suffixes

Each database contains the data within a suffix of your Directory Server. You can
create both root and sub suffixes to organize the contents of your directory tree. A
root suffix is the entry at the top of a tree. It can be the root of your directory tree
or part of a larger tree you have designed for your Directory Server.

A sub suffix is a branch underneath a root suffix. The data for root and sub
suffixes are contained by databases.

Assume, for example, you want to create suffixes to represent the distribution of
your directory data. The directory tree for
the following:

example.com

Corporation appears as

If

example.com

different databases, the new tree would appear as this:

94 Red Hat Directory Server Deployment Guide • May 2005

Corporation decided to split their directory tree across five

The suffixes that result contain the following entries:

Distributing Your Data

The

o=NetscapeRoot

other

ou=testing,dc=example,dc=com
ou=development,dc=example,dc=com
ou=partners,ou=development,dc=example,dc=com

the

dc=example,dc=com

the data in the

ou=marketing

and

dc=example,dc=com

suffix, the

suffix, and the

root suffix. The root suffix

branch of the original directory tree.

suffixes are both root suffixes. The

suffix are all sub suffixes of

dc=example,dc=com

contains

Your directory might contain more than one root suffix. For example, an ISP called

Example
example_b.com
o=example_a.com
o=example_b.com

might host several websites, one for

. The ISP would create two root suffixes, one corresponding to the

naming context and one corresponding to the

naming context. The directory tree appears as follows:

example_a.com

and one for

Chapter 5 Designing the Directory Topology 95

About Knowledge References

The

dc=example,dc=com

ISP is also a root suffix (

ou=groups

entry represents a root suffix. The entry for each hosted

o=example_a

and

o=example_b

). The

branches are sub suffixes under each root suffix.

ou=people

and the

About Knowledge References

Once you have distributed your data over several databases, you need to define
the relationship between the distributed data. You do this using knowledge
references, pointers to directory information held in different databases. The
Directory Server provides the following types of knowledge references to help
you link your distributed data into a single directory tree:

• Referrals — The server returns a piece of information to the client application
indicating that the client application needs to contact another server to fulfill
the request.

• Chaining — The server contacts other servers on behalf of the client
application and returns the combined results to the client application after
finishing the operation.

The following sections describe and compare these two types of knowledge
references in more detail.

96 Red Hat Directory Server Deployment Guide • May 2005

About Knowledge References

Using Referrals

A referral is a piece of information returned by a server that tells a client

application which server to contact to proceed with an operation request. This
redirection mechanism occurs when a client application requests a directory entry
that does not exist on the local server.

Directory Server supports two types of referrals:

• A default referral — The directory returns a default referral when a client
application presents a DN for which the server does not have a matching
suffix. Default referrals are stored in the configuration file of the server. You
can set a default referral for the Directory Server and a separate default referral
for each database.

The default referral you set for each database is done through the suffix
configuration information. When the suffix of the database is disabled, you can
configure the directory to return a default referral to client requests made to
that suffix. For more information about suffixes, refer to “About Suffixes,” on
page 94. For information on configuring suffixes, refer to Red Hat Directory
Server Administrator’s Guide.

• Smart referrals — Smart referrals are stored on entries within the directory
itself. Smart referrals point to Directory Servers that have knowledge of the
subtree whose DN matches the DN of the entry containing the smart referral.

All referrals are returned in the format of an LDAP uniform resource locator (URL).
The following sections describe the structure of an LDAP referral, and then
describe the two referral types supported by Directory Server.

The Structure of an LDAP Referral

An LDAP referral contains information in the format of an LDAP URL. An LDAP
URL contains the following information:

• The hostname of the server to contact.

• The port number of the server.

• The base DN (for search operations) or target DN (for add, delete, and modify
operations).

For example, a client application searches
surname

Jensen

. A referral returns the following LDAP URL to the client

application:

ldap://europe.example.com:389/ou=people,l=europe,dc=example,dc=c
om

dc=example,dc=com

for entries with a

Chapter 5 Designing the Directory Topology 97

About Knowledge References

The referral tells the client application to contact the host
on port

ou=people,l=europe,dc=example,dc=com

389

and submit a search rooted at

.

europe.example.com

The LDAP client application you use determines how a referral is handled. Some
client applications automatically retry the operation on the server to which they
have been referred. Other client applications simply return the referral
information to the user. Most LDAP client applications provided by Red Hat
Directory Server (such as the command-line utilities or the Directory Server
Gateway) automatically follow the referral. The same bind credentials you supply
on the initial directory request are used to access the server.

Most client applications follow a limited number of referrals, or hops. The limit on
the number of referrals followed reduces the time a client application spends
trying to complete a directory lookup request and helps eliminate hung processes
caused by circular referral patterns.

About Default Referrals

Default referrals are returned to clients when the server or database contacted
does not contain the data requested.

Directory Server determines whether a default referral should be returned by
comparing the DN of the requested directory object against the directory suffixes
supported by the local server. If the DN does not match the supported suffixes,
the Directory Server returns a default referral.

For example, a directory client requests the following directory entry:

uid=bjensen,ou=people,dc=example,dc=com

However, the server manages only entries stored under the

dc=europe,dc=example,dc=com

client that indicates which server to contact for entries stored in the

dc=example,dc=com

suffix. The client then contacts the appropriate server and

resubmits the original request.

You configure the default referral to point to a Directory Server that has more
knowledge about the distribution of your directory. Default referrals for the
server are set by the

nsslapd-referral

database in your directory installation are set by the
in the database entry in the configuration. These attribute values are stored in the

dse.ldif

file.

For information on configuring default referrals, see the Red Hat Directory Server
Administrator’s Guide.

98 Red Hat Directory Server Deployment Guide • May 2005

suffix. The directory returns a referral to the

attribute. Default referrals for each

nsslapd-referral

attribute

About Knowledge References

Smart Referrals

Directory Server also allows you to configure your directory to use smart referrals.
Smart referrals allow you to associate a directory entry or directory tree to a specific
LDAP URL. Associating directory entries to specific LDAP URLs allows you to
refer requests to any of the following:

• Same namespace contained on a different server.

• Different namespaces on a local server.

• Different namespaces on the same server.

Unlike default referrals, the smart referrals are stored within the directory itself.
For information on configuring and managing smart referrals, refer to the Red Hat
Directory Server Administrator’s Guide.

For example, the directory for the American office of
contains the

You redirect all requests on this branch to the
office of

ou=people,dc=example,dc=com

example.com

Corporation by specifying a smart referral on the

directory branch point.

ou=people

example.com

Corporation

branch of the European

ou=people

entry itself. This smart referral appears as follows:

ldap://europe.example.com:389/ou=people,dc=example,dc=com

Any requests made to people branch of the American directory are redirected to
the European directory. An illustration of this smart referral follows:

Chapter 5 Designing the Directory Topology 99

About Knowledge References

You can use the same mechanism to redirect queries to a different server that uses
a different namespace. For example, an employee working in the Italian office of

example.com

phone number of an
the directory follows:

ldap://europe.example.com:389/ou=US employees,dc=example,dc=com

The following diagram illustrates how the referral works:

Corporation makes a request to the European directory for the

example.com

employee in America. The referral returned by

Finally, if you serve multiple suffixes on the same server, you can redirect queries
from one namespace to another namespace served on the same machine. If you
want to redirect all queries on the local machine for

dc=example,dc=com
o=example,c=us

ldap:///dc=example,dc=com

, then you would put the following smart referral on the

entry:

The third slash in this LDAP URL indicates that the URL points to the same
Directory Server.

100 Red Hat Directory Server Deployment Guide • May 2005

o=example,c=us

to