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: +1 919 754 3700
Phone: 888 733 4281
Fax: +1 919 754 3701
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 security@redhat.com 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
Loading...