Page 1 Red Hat Directory Server 8.1 Deployment Guide Ella Deon Lackey Publication date: April 28, 2009, updated on September 9, 2009...
Page 2 Deployment Guide Deployment Guide Author Ella Deon Lackey Copyright © 2009 Red Hat, Inc. Copyright © 2009 Red Hat, Inc.. This material may only be distributed subject to the terms and conditions set forth in the Open Publication License, V1.0 or later (the latest version of the OPL is presently available at http://www.opencontent.org/openpub/).
Page 3: Table Of Contents
Preface 1. Directory Server Overview ....................v 2. Examples and Formatting ....................v 3. Additional Reading ......................vii 4. Giving Feedback ......................viii 5. Documentation History ....................viii 1. Introduction to Directory Services 1.1. About Directory Services ....................1 1.2. Introduction to Directory Server ..................2 1.3.
Page 4 Deployment Guide 8.1. About Security Threats ..................... 111 8.2. Analyzing Security Needs ..................112 8.3. Overview of Security Methods ................... 114 8.4. Selecting Appropriate Authentication Methods ............115 8.5. Preventing Authentication by Account Deactivation ............. 118 8.6. Designing a Password Policy ..................118 8.7.
Page 5: Preface
Preface The Red Hat Directory Server Deployment Guide provides a solid foundation on the on concepts and configuration options for planning an effective directory service. The information provided here is intended for both designers and administrators. 1. Directory Server Overview Red Hat Directory Server provides the following key features: •...
Page 6: Command And File Examples
Preface 2.1. Command and File Examples All of the examples for Red Hat Directory Server commands, file locations, and other usage are given for Red Hat Enterprise Linux 5 (32-bit) systems. Be certain to use the appropriate commands and files for your platform.
Page 7: Additional Reading
Additional Reading NOTE A note provides additional information that can help illustrate the behavior of the system or provide more detail for a specific issue. IMPORTANT Important information is necessary, but possibly unexpected, such as a configuration change that will not persist after a reboot. WARNING A warning indicates potential data loss, as may happen when tuning hardware for maximum performance.
Page 8: Giving Feedback
If there is any error in this Deployment Guide or there is any way to improve the documentation, please let us know. Bugs can be filed against the documentation for Red Hat Directory Server through Bugzilla, http://bugzilla.redhat.com/bugzilla. Make the bug report as specific as possible, so we can be more effective in correcting any issues: •...
Page 9 Documentation History Spellchecking and correcting typo, per Bugzilla #516693. Revision 8.1.0 April 28, 2009 Ella Deon Lackey dlackey@redhat.com Initial draft for version 8.1.
Page 11: Introduction To Directory Services
Chapter 1. Introduction to Directory Services Red Hat Directory Server provides a centralized directory service for an intranet, network, and extranet information. Directory Server integrates with existing systems and acts as a centralized repository for the consolidation of employee, customer, supplier, and partner information. Directory Server can even be extended to manage user profiles, preferences, and authentication.
Page 12: Introduction To Directory Server
Chapter 1. Introduction to Directory Services increased hardware and personnel costs; the increased maintenance overhead is referred to as the n +1 directory problem. A global directory service solves the n+1 directory problem by providing a single, centralized repository of directory information that any application can access. However, giving a wide variety of applications access to the directory service requires a network-based means of communicating between the applications and the directory service.
Page 13: Overview Of The Server Frontend
Overview of the Server Frontend • SNMP agent to monitor the Directory Server using the Simple Network Management Protocol (SNMP). For more information about SNMP monitoring, see the Directory Server Administrator's Guide. 1.2.1. Overview of the Server Frontend Directory Server is a multi-threaded application. This means that multiple clients can bind to the server at the same time over the same network.
Page 14 Chapter 1. Introduction to Directory Services Figure 1.1. Layout of Default Directory Server Directory Tree The root of the tree is called the root suffix. For information about naming the root suffix, see Section 4.2.1, “Choosing a Suffix”. After a standard installation, the directory contains three subtrees under the root suffix: •...
Page 15: Directory Server Data Storage
Directory Server Data Storage Figure 1.2. Expanded Directory Tree for Example Corp. 1.3. Directory Server Data Storage The database is the basic unit of storage, performance, replication, and indexing. All Directory Server operations — importing, exporting, backing up, restoring, and indexing entries — are performed on the database.
Page 16: Directory Design Overview
Chapter 1. Introduction to Directory Services For example, an entry might be of object class organizationalPerson, indicating that the entry represents a person within an organization. This object class supports the givenname and telephoneNumber attributes. The values assigned to these attributes give the name and phone number of the person represented by the entry.
Page 17 Deploying the Directory with one another. It describes the types of data that can be stored in the directory and other tasks to perform to design the contents of the Directory Server. Chapter 3, Designing the Directory Schema The directory is designed to support one or more directory-enabled applications. These applications have requirements of the data stored in the directory, such as the file format.
Page 18: Other General Directory Resources
• Understanding and Deploying LDAP Directory Services. T. Howes, M. Smith, G. Good, Macmillan Technical Publishing, 1999. http://redhat.com/docs/manuals/dir- All of the Red Hat Directory Server documentation, available at server, also contain high-level concepts about using LDAP and managing directory services, as well...
Page 19: Planning The Directory Data
Chapter 2. Planning the Directory Data The data stored in the directory may include user names, email addresses, telephone numbers, and information about groups users are in, or it may contain other types of information. The type of data in the directory determines how the directory is structured, who is given access to the data, and how this access is requested and granted.
Page 20: Defining Directory Needs
Chapter 2. Planning the Directory Data Using the Directory Server for more than just server administration requires planning what other types of information to store in the directory. For example: • Contract or client account details • Payroll data • Physical device information •...
Page 21 Identifying the Applications That Use the Directory • Identify data sources. Survey the enterprise and identify sources of data, such as Active Directory, other LDAP servers, PBX systems, human resources databases, and email systems. • Characterize the data the directory needs to contain. Determine what objects should be present in the directory (for example, people or groups) and what attributes of these objects to maintain in the directory (such as usernames and passwords).
Page 22: Identifying Data Sources
Chapter 2. Planning the Directory Data • Directory browser applications, such as online telephone books. Decide what information (such as email addresses, telephone numbers, and employee name) users need, and include it in the directory. • Email applications, especially email servers. All email servers require email addresses, user names, and some routing information to be available in the directory.
Page 23 Characterizing the Directory Data Locate all the organizations that manage information essential to the enterprise. Typically, this includes the information services, human resources, payroll, and accounting departments. • Identify the tools and processes that are information sources. Some common sources for information are networking operating systems (Windows, Novell Netware, UNIX NIS), email systems, security systems, PBX (telephone switching) systems, and human resources applications.
Page 24: Determining Level Of Service
Chapter 2. Planning the Directory Data Data Format Size Owner Related to Email address Text Many character IS department User's entry Table 2.3. Directory Data Characteristics 2.3.4. Determining Level of Service The level of service provided depends on the expectations of the people who rely on directory-enabled applications.
Page 25: Determining Data Ownership
Determining Data Ownership How master copies of the data are maintained depends on the specific directory needs. However, regardless of how data masters are maintained, keep it simple and consistent. For example, do not attempt to master data in multiple sites, then automatically exchange data between competing applications.
Page 26: Determining Data Access
Chapter 2. Planning the Directory Data This approach allows an organization's administrators to function as the directory content managers. • Create roles that give groups of people read or write access privileges. For example, there can be roles created for human resources, finance, or accounting. Allow each of these roles to have read access, write access, or both to the data needed by the group.
Page 27: Documenting The Site Survey
Documenting the Site Survey Chapter 4, Designing the Directory Tree. For For information about groups and roles, see Section 8.7, “Designing Access Control”. information about access controls, see Making these decisions for each piece of directory data defines a security policy for the directory. These decisions depend upon the nature of the site and the kinds of security already available at the site.
Page 28: Repeating The Site Survey
Chapter 2. Planning the Directory Data • 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. •...
Page 29: Designing The Directory Schema
Chapter 3. Designing the Directory Schema Chapter 2, Planning the Directory Data The site survey conducted in revealed information about the data which will be stored in the directory. The directory schema describes the types of data in the directory, so determining what schema to use reflects decisions on how to represent the data stored in the directory.
Page 30: Standard Attributes
Chapter 3. Designing the Directory Schema The Directory Server schema differs slightly from the LDAPv3 schema, because it uses its own proprietary object classes and attributes. In addition, it uses a private field in the schema entries, called X-ORIGIN, which describes where the schema entry was defined originally. For example, if a schema entry is defined in the standard LDAPv3 schema, the X-ORIGIN field refers to RFC 2252.
Page 31 Standard Attributes 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.
Page 32: Mapping The Data To The Default Schema
Chapter 3. Designing the Directory Schema Syntax Description TelephoneNumber Indicates that values for this attribute are in the form of telephone numbers. It is recommended to use telephone numbers in international form. Indicates that the values for this attribute are in the form of a URL, introduced by a string such as http://.
Page 33: Viewing The Default Directory Schema
Viewing the Default Directory Schema 3.3.1. Viewing the Default Directory Schema The default directory schema is stored in /etc/dirsrv/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 file. The configuration schema used by earlier versions of the directory can be found in the 50ns-directory.ldif file.
Page 34: Customizing The Schema
Chapter 3. Designing the Directory Schema Data Owner Object Class Attribute Employee location inetOrgPerson localityName Office phone number Facilities person telephoneNumber Table 3.2. Data Mapped to Default Directory Schema Table 3.2, “Data Mapped to Default Directory Schema”, the employee name describes a person. In the default directory schema, there is a person object class, which inherits from the top object class.
Page 35: Getting And Assigning Object Identifiers
When to Extend the Schema Custom object classes and attributes are defined in the 99user.ldif file. Each individual instance maintains its own 99user.ldif file in the /usr/lib/dirsrv/slapd-instance_name/schema directory. It is also possible to create custom schema files and dynamically reload the schema into the server.
Page 36 Chapter 3. Designing the Directory Schema • Create a single object class that supports all of the custom attributes created for the directory. This kind of object class is created by defining it as an auxiliary object class. It may be easiest to mix the two methods. For example, suppose an administrator wants to create the attributes exampleDateOfBirth, examplePreferredOS, exampleBuildingFloor, and exampleVicePresident.
Page 37: Strategies For Defining New Attributes
Strategies for Defining New Attributes • Multiple object classes require a more careful and rigid data design. Rigid data design forces attention to the object class structure under which every piece of data is placed, which can be either helpful or cumbersome. •...
Page 38: Creating Custom Schema Files
Chapter 3. Designing the Directory Schema might prevent the entries that use the object class from being modified later. Schema checks on modified entries also fails unless the unknown object class values are removed from the entry. 3.4.7. Creating Custom Schema Files Administrators can create custom schema files for the Directory Server to use, in addition to the 99user.ldif file provided with Directory Server.
Page 39: Custom Schema Best Practices
Custom Schema Best Practices 3.4.8. Custom Schema Best Practices When using schema files, be sure to create schema which will be compatible and easy to manage. 3.4.8.1. Naming Schema Files When naming custom schema files, use the following naming format: [00-99]yourName.ldif Name custom schema files lower (numerically and alphabetically) than 99user.ldif.
Page 40: Maintaining Consistent Schema
Chapter 3. Designing the Directory Schema 3.4.8.3. Defining Attributes before Object Classes When adding new schema elements, all attributes need to be defined before they can be used in an object class. Attributes and object classes can be defined in the same schema file. 3.4.8.4.
Page 41: Other Schema Resources
Selecting Consistent Data Formats to the directory entry. Attempting to add an attribute to an entry that is neither required nor allowed according to the entry's object class definition causes the Directory Server to return an object class violation message. For example, if an entry is defined to use the organizationalPerson object class, then the common name (cn) and surname (sn) attributes are required for the entry.
Page 42 Chapter 3. Designing the Directory Schema http://www.ietf.org/rfc/rfc2251.txt • RFC 2251: Lightweight Directory Access Protocol (v3), http://www.ietf.org/rfc/rfc2252.txt • RFC 2252: LDAPv3 Attribute Syntax Definitions, http://www.ietf.org/rfc/ • RFC 2256: Summary of the X.500 User Schema for Use with LDAPv3, rfc2256.txt http://www.ietf.org/ • Internet Engineering Task Force (IETF), •...
Page 43: Designing The Directory Tree
Chapter 4. Designing the Directory Tree The directory tree provides a way to refer to the data stored by the directory service. The types of information stored in the directory, the physical nature of the enterprise, the applications used with the directory, and the types of replication implemented shape the design of the directory tree.
Page 44: Choosing A Suffix
Chapter 4. Designing the Directory Tree 4.2.1. Choosing a Suffix The suffix is the name of the entry at the root of the directory tree, and the directory data are stored beneath it. The directory can contain more than one suffix. It is possible to use multiple suffixes if there are two or more directory trees of information that do not have a natural common root.
Page 45 Creating the Directory Tree Structure For example, create separate suffixes for example_a and example_b and store them in separate databases. Figure 4.1. Including Multiple Directory Trees in a Database The databases could be stored on a single server or multiple servers depending on resource constraints.
Page 46 Chapter 4. Designing the Directory Tree to branch the directory tree are stable; do not perform this kind of branching if the enterprise reorganizes frequently. • Use functional or generic names rather than actual organizational names for the branch points. Names change, and it is really bad to have to change the directory tree every time the enterprise renames its divisions.
Page 47: Identifying Branch Points
Creating the Directory Tree Structure Figure 4.3. Example Hosting Directory Tree 4.2.2.2. Identifying Branch Points When planning the branches in the directory tree, decide what attributes to 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 Example Corp., is uid=bjensen, ou=people,dc=example,dc=com.
Page 48 Chapter 4. Designing the Directory Tree Figure 4.5. Directory Tree for Example ISP Beneath the root suffix entry o=example, c=US, the tree is split into three branches. The ISP branch contains customer data and internal information for Example ISP. The Internet branch is the domain tree.
Page 49: Replication Considerations
Creating the Directory Tree Structure Attribute Name Definition A state or province name. l or locality A locality, such as a city, country, office, or facility name. Section 4.2.1.1, A domain component, as in “Suffix Naming Conventions”. Table 4.1. Traditional DN Branch Point Attributes NOTE A common mistake is to assume that the directory is searched based on the attributes used in the distinguished name.
Page 50 Chapter 4. Designing the Directory Tree Figure 4.7. Extended Branching for Example Corp. The Example ISP branches their directory as follows: Figure 4.8. Directory Branching for Example ISP After creating the initial structure of their directory tree, they create additional branches as follows:...
Page 51: Access Control Considerations
Naming Entries Figure 4.9. Extended Branching for Example ISP Both the enterprise and the hosting organization design their data hierarchies based on information that is not likely to change often. 4.2.2.4. Access Control Considerations Introducing a hierarchy into the directory tree can be used to enable certain types of access control. As with replication, it is easier to group similar entries and then administer them from a single branch.
Page 52: Naming Person Entries
Chapter 4. Designing the Directory Tree • The attribute selected for naming should be unlikely to change. • The name must be unique across the directory. A unique name ensures that a DN can refer to at most one entry in the directory. When creating entries, define the RDN within the entry.
Page 53: Naming Group Entries
Naming Entries For employees of the inetOrgPerson object class, consider using an employer assigned attribute value such as employeeNumber. Whatever is used for an attribute-data pair for person entry RDNs, make sure that they are unique, permanent values. Person entry RDNs should also be readable. For example, uid=bjensen, dc=example, dc=com is preferable to uid=b12r56A, dc=example,dc=com because recognizable DNs simplify some directory tasks, such as changing directory entries based on their distinguished names.
Page 54: Grouping Directory Entries
Chapter 4. Designing the Directory Tree In a hosted organization, we also recommend that group entries used for directory administration be located under the ou=Groups branch. 4.2.3.3. 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, such as o=example_a+st=Washington, o=ISP,c=US.
Page 55: Deciding Between Roles And Groups
Deciding Between Roles and Groups 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. Roles can organize groups in a number of different ways: •...
Page 56: About Class Of Service
Chapter 4. Designing the Directory Tree 4.3.3. About Class of Service A class of service (CoS) shares 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.
Page 57: Virtual Directory Information Tree Views
Virtual Directory Information Tree Views • 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.
Page 58 Chapter 4. Designing the Directory Tree Figure 4.10. Examples of a Flat and an Organizationally-Based DIT Using a hierarchical DIT, a deployment must then determine the subject domain of the hierarchy. Only one choice can be made; the natural tendency is to choose the organizational hierarchy. This view of the organization serves well in many cases, but having only a single view can be very limiting for directory navigation and management.
Page 59 About Virtual DIT Views Create a virtual DIT view hierarchy in the same way as a normal DIT hierarchy. Create the same entries (for example, organizational unit entries) but with an additional object class (nsview) and a filter attribute (nsviewfilter) that describes the view. After adding the additional attribute, the entries that match the view filter instantly populate the view.
Page 60: Advantages Of Using Virtual Dit Views
Chapter 4. Designing the Directory Tree Figure 4.12. A DIT with a Virtual DIT View Hierarchy • The sub-tree ou=People contains the real Entry A and Entry B entries. • The sub-tree ou=Location Views is a view hierarchy. • The leaf nodes ou=Sunnyvale and ou=Mountain View each contain an attribute, nsviewfilter, which describes the view.
Page 61: Example Of Virtual Dit Views
Example of Virtual DIT Views 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 view, thereby facilitating a more gradual changeover for the entries themselves and for the applications that use them.
Page 62: Views And Other Directory Features
Chapter 4. Designing the Directory Tree 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 ou=Location Views, dc=example, dc=com would return all entries below dc=example,dc=com which match the filters (l=Sunnyvale), (l=Santa Clara), or (l=Cupertino).
Page 63: Directory Tree Design Examples
Effects of Virtual Views on Performance If the base of a search is a view and the scope of the search is not a base, then the search is a views- based search. Otherwise, it is a conventional search. For example, performing a search with a base of dc=example, dc=com does not return any entries from the virtual search space are returned;...
Page 64: Directory Tree For An International Enterprise
Chapter 4. Designing the Directory Tree 4.5.1. Directory Tree for an International Enterprise To support an international enterprise, use the Internet domain name as the root point for the directory tree, then branch the tree immediately below that root point for each country where the enterprise has operations.
Page 65: Other Directory Tree Resources
Other Directory Tree Resources In addition, partitioning helps reduce performance problems caused by disk contention and reduces the number of accounts potentially affected by a disk outage. Figure 4.15. Directory tree for Example ISP 4.6. Other Directory Tree Resources See the following for more information about designing the directory tree: RFC 2247: •...
Page 67: Designing The Directory Topology
Chapter 5. Designing the Directory Topology Chapter 4, Designing the Directory Tree covers how to design the directory service stores entries. Because Red Hat Directory Server can store a large number of entries, it is possible to distribute directory entries across more than one server. The directory's topology describes how the directory tree is divided among multiple physical Directory Servers and how these servers link with one another.
Page 68: About Using Multiple Databases
Chapter 5. Designing the Directory Topology The following sections describe the mechanics of data distribution in more detail: Section 5.2.1, “About Using Multiple Databases” • Section 5.2.2, “About Suffixes” • 5.2.1. About Using Multiple Databases Directory Server stores data in LDBM databases. This a high-performance, disk-based database. Each database consists of a set of large files that contain all of the data assigned to it.
Page 69: About Suffixes
About Suffixes Figure 5.2. Dividing Suffix Databases Between Separate Servers Server A contains DB1 and DB2, and Server B contains DB3. Distributing databases across multiple servers reduces the workload on each server. The directory service can therefore be scaled to a much larger number of entries than would be possible with a single server.
Page 70 Chapter 5. Designing the Directory Topology If Example Corp. decided to spread their directory tree across five different databases, the new tree would appear as follows: Figure 5.4. Directory Tree Spread across Multiple Databases The resulting suffixes would contain the following entries: Figure 5.5.
Page 71: About Knowledge References
About Knowledge References Figure 5.6. Directory Tree with Multiple Root Suffixes The dc=example, dc=com entry represents a root suffix. The entry for each hosted ISP is also a root suffix (o=example_a and o=example_b). The ou=people and the ou=groups branches are subsuffixes under each root suffix.
Page 72: The Structure Of An Ldap Referral
Chapter 5. Designing the Directory Topology The default referral for each database is done through the suffix configuration information. When the suffix of the database is disabled, configure the directory service to return a default referral to client requests made to that suffix. Section 5.2.2, “About Suffixes”.
Page 73: Smart Referrals
Using Referrals For example, a directory client requests the following directory entry: uid=bjensen, ou=people,dc=example,dc=com However, the server only manages entries stored under the dc=europe,dc=example,dc=com suffix. The directory returns a referral to the client that indicates which server to contact for entries stored under the dc=example,dc=com suffix.
Page 74 Chapter 5. Designing the Directory Topology Figure 5.7. Using Smart Referrals to Redirect Requests The same mechanism can be used to redirect queries to a different server that uses a different namespace. For example, an employee working in the Italian office of Example Corp. makes a request to the European directory service for the phone number of an Example Corp.
Page 75 Using Referrals Figure 5.8. Redirecting a Query to a Different Server and Namespace Finally, if multiple suffixes are served on the same server, queries can be redirected from one namespace to another namespace served on the same machine. For example, to redirect all queries on the local machine for o=example,c=us to dc=example,dc=com, then put the smart referral ldap:///dc=example, dc=com on the o=example,c=us entry.
Page 76: Tips For Designing Smart Referrals
Chapter 5. Designing the Directory Topology Creating a referral from one namespace to another works only for clients whose searches are based at that distinguished name. Other kinds of operations, such as searches below ou=people,o=example,c=US, are not performed correctly. For more information on LDAP URLS and on how to include smart URLs on Directory Server entries, refer to the Red Hat Directory Server Administrator's Guide.
Page 77: Using Chaining
Using Chaining to secure directory structure. Limiting referrals to the suffix or major branch points of the directory tree limits the number of referrals that have to be managed, subsequently reducing the directory's administrative overhead. • Consider the security implications. Access control does not cross referral boundaries.
Page 78: Deciding Between Referrals And Chaining
Chapter 5. Designing the Directory Topology • Access control. The database link impersonates the client application, providing the appropriate authorization identity to the remote server. User impersonation can be disabled on the remote servers when access control evaluation is not required. For more information on configuring database links, refer to the Red Hat Directory Server Administrator's Guide.
Page 79 Deciding Between Referrals and Chaining Figure 5.11. Sending a Client Request to a Server Using Referrals In the illustration above, the client application performs the following steps: 1. The client application first binds with Server A. 2. Server A contains an entry for the client that provides a user name and password, so it returns a bind acceptance message.
Page 80 Chapter 5. Designing the Directory Topology Figure 5.12. Sending a Client Request to a Server Using Chaining In the illustration above, the following steps are performed: 1. The client application binds with Server A, and Server A tries to confirm that the user name and password are correct.
Page 81: Using Indexes To Improve Database Performance
Using Indexes to Improve Database Performance Figure 5.13. Authenticating a Client and Retrieving Data Using Different Servers In this illustration, the following steps are performed: 1. The client application binds with Server A, and Server A tries to confirm that the user name and password are correct.
Page 82: Overview Of Directory Index Types
Chapter 5. Designing the Directory Topology file for a particular attribute can contain multiple types of indexes, so several types of index can be maintained for each attribute. For example, a file called cn.db4 contains all of the indexes for the common name attribute.
Page 83 Evaluating the Costs of Indexing To run more efficiently, the directory service places as many index files in memory as possible. Index files use memory out of the pool available depending upon the database cache size. A large number of index files requires a larger database cache. •...
Page 85: Designing The Replication Process
Chapter 6. Designing the Replication Process Replicating the directory contents increases the availability and performance of the directory service. Chapter 4, Designing the Directory Tree Chapter 5, Designing the Directory Topology cover the design of the directory tree and the directory topology. This chapter addresses the physical and geographical location of the data and, specifically, how to use replication to ensure the data is available when and where it is needed.
Page 86: Unit Of Replication
Chapter 6. Designing the Replication Process These decisions cannot be made effectively without an understanding of how the Directory Server handles these concepts. For example, decide what information to replicate, be aware of the smallest replication unit that the Directory Server can handle. The replication concepts used by the Directory Server provide a framework for thinking about the global decisions that need to be made.
Page 87: Replication Agreement
Replication Concepts Consumers A consumer server must: • Respond to read requests. • Refer update requests to a supplier server for the replica. Whenever a consumer server receives a request to add, delete, or change an entry, the request is referred to a supplier for the replica.
Page 88: Common Replication Scenarios
Chapter 6. Designing the Replication Process 6.1.2. Data Consistency Consistency refers to how closely the contents of replicated databases match each other at a given point in time. Part of the configuration for replication between servers is to schedule updates. The supplier server always determines when consumer servers need to be updated and initiates replication.
Page 89 Single-Master Replication 6.2.1. Single-Master Replication In the most basic replication configuration, a supplier server copies a replica directly to one or more consumer servers. In this configuration, all directory modifications occur on the read-write replica on the supplier server, and the consumer servers contain read-only replicas of the data. The supplier server must perform all modifications to the read-write replicas stored on the consumer servers.
Page 90 Chapter 6. Designing the Replication Process When the same data is modified on multiple servers, there is a conflict resolution procedure to determine which change is kept. The Directory Server considers the valid change to be the most recent one. Multiple servers can have master copies of the same data, but, within the scope of a single replication agreement, there is only one supplier server and one consumer.
Page 91 Multi-Master Replication Figure 6.3. Multi-Master Replication Configuration A (Four Suppliers) Figure 6.4, “Multi-Master Replication Configuration B (Four Suppliers)” illustrates a topology where each supplier server feeds data to two other supplier servers (which also function as consumers). Only eight replication agreements exist between the four supplier servers, compared to the twelve Figure 6.3, “Multi-Master Replication Configuration A (Four agreements shown for the topology in Suppliers)”.
Page 92 Chapter 6. Designing the Replication Process Figure 6.4. Multi-Master Replication Configuration B (Four Suppliers) NOTE Red Hat Directory Server supports a maximum of four supplier servers in any replication environment. However, the number of consumer servers that hold the read-only replicas is unlimited.
Page 93: Cascading Replication
Cascading Replication Figure 6.5. Replication Traffic in a Multi-Master Environment 6.2.3. Cascading Replication In a cascading replication scenario, a hub supplier receives updates from a supplier server and replays those updates on consumer servers. The hub supplier is a hybrid; it holds a read-only replica, like a typical consumer server, and it also maintains a changelog like a typical supplier server.
Page 94 Chapter 6. Designing the Replication Process Figure 6.6. Cascading Replication Scenario Figure 6.7, “Replication Traffic and Changelogs in Cascading Replication” illustrates the same scenario from a different perspective, which shows how the replicas are configured on each server (read-write or read-only), and which servers maintain a changelog.
Page 95: Mixed Environments
Mixed Environments Figure 6.7. Replication Traffic and Changelogs in Cascading Replication 6.2.4. Mixed Environments Any of the replication scenarios can be combined to meet suit the needs of the network and directory environment. One common combination is to use a multi-master configuration with a cascading configuration.
Page 96: Defining A Replication Strategy
Chapter 6. Designing the Replication Process Figure 6.8. Combined Multi-Master and Cascading Replication 6.3. Defining a Replication Strategy The replication strategy is determined by the services that must be provided. To determine the replication strategy, start by performing a survey of the network, users, applications, and how they use the directory service.
Page 97 Conducting a Replication Survey • If high availability is the primary concern, create a data center with multiple Directory Servers on a single site. Single-master replication provides read-failover, while multi-master replication provides write-failover. Section 6.3.6, “Using Replication for High Availability” for more information.
Page 98: Replication Resource Requirements
Chapter 6. Designing the Replication Process Fractional replication is enabled and configured per replication agreement. The exclusion of attributes is applied equally to all entries. As far as the consumer server is concerned, the excluded attributes always have no value. Therefore, a client performing a search against the consumer server never sees the excluded attributes.
Page 99 Replication Across a Wide-Area Network • nsslapd-changelogmaxentries sets the maximum number of entries that are allowed in the changelog. Like nsslapd-changelogmaxage, this also trims the changelog, but be careful about the setting. This must be large enough to allow a complete set of directory information or multi- master replication may not function properly.
Page 100: Using Replication For High Availability
Chapter 6. Designing the Replication Process • When creating agreements for replication over a wide-area network, avoid constant synchronization between the servers. Replication traffic could consume a large portion of the bandwidth and slow down the overall network and Internet connections. •...
Page 101: Using Replication For Load Balancing
Using Replication for Load Balancing Intermittent network connections can occur if there are unreliable WANs, as often occurs in international networks. • To offset periodic, extremely heavy network loads that may cause the performance of the directory service to be severely reduced. Performance may also be affected in enterprises with aging networks, which may experience these conditions during normal business hours.
Page 102: Example Of Network Load Balancing
Chapter 6. Designing the Replication Process benefits of locally available directory data can far outweigh any considerations regarding network loads. A good compromise between making data available to local sites and overloading the network is to use scheduled replication. For more information on data consistency and replication schedules, see Section 6.1.2, “Data Consistency”.
Page 103: Example Of Load Balancing For Improved Performance
Using Replication for Load Balancing 6.3.8.2. Example of Load Balancing for Improved Performance Suppose that the enterprise has the following characteristics: • Uses a Directory Server that includes 1.5 million entries in support of one million users • Each user performs ten directory lookups per day •...
Page 104: Example Replication Strategy For A Small Site
Chapter 6. Designing the Replication Process Access Type Type Count Accesses per Day Total Accesses Total 135 million (3,125/ second) Table 6.2. Calculating Directory Server Load If the hardware that runs the Directory Servers supports 500 reads per second, at least six or seven Directory Servers must be used to support this load.
Page 105: Using Replication With Other Directory Server Features
Using Replication with Other Directory Server Features As their network needs changes, then Example Corp.'s administrators adjust their replication strategy: • Choose a single server in one of the two buildings to contain a master copy of the directory data. This server should be placed in the building that contains the largest number of people responsible for the master copy of the directory data.
Page 106: Replication And Database Links
Chapter 6. Designing the Replication Process 6.4.3. Replication and Database Links With chaining to distribute directory entries, the server containing the database link references a remote server that contains the actual data. In this environment, the database link itself cannot be replicated.
Page 107: Replication And Synchronization
Replication and Synchronization A consumer might contain replicated data from two suppliers, each with different schema. Whichever supplier was updated last wins, and its schema is propagated to the consumer. WARNING Never update the schema on a consumer server, because the supplier server is unable to resolve conflicts that occur, and replication fails.
Page 109: Designing Synchronization
Chapter 7. Designing Synchronization (Section 2.3, An important factor to consider while conducting the site survey for an existing site “Performing a Site Survey”) is to include the structure and data types of Active Directory directory services. Through Windows Sync, an existing Windows directory service can be synchronized and integrated with the Directory Server, including creating, modifying, and deleting Windows accounts on the Directory Server or, oppositely, the Directory Server accounts on Windows.
Page 110: Planning Windows Synchronization
Chapter 7. Designing Synchronization A single Windows subtree is synchronized with a single Directory Server subtree, and vice versa. Unlike replication, which connects databases, synchronization is between suffixes, parts of the directory tree structure. Therefore, when designing the directory tree, consider the Windows subtrees that should be synchronized with the Directory Server, and design or add corresponding Directory Server subtrees.
Page 111: Resource Requirements
Resource Requirements 7.2.1. Resource Requirements Synchronization uses server resources. Consider the following resource requirements when defining the replication strategy: • Disk usage — The changelog is written after each update operation. Servers receiving many update operations may see higher disk usage. In addition, a single changelog is maintained for all replication databases and synchronized databases.
Page 112: Interaction With A Replicated Environment
Chapter 7. Designing Synchronization • nsDS5ReplicaTombstonePurgeInterval sets the frequency which the server runs a purge operation. At this interval, the Directory Server runs an internal operation to clean the tombstone and state entries out of the changelog. Make sure that the maximum age is longer than the longest replication update schedule or multi-master replication may not be able to update replicas properly.
Page 113 Identifying the Directory Data to Synchronize (cn=Users,dc=test,dc=com). Each subtree can be synchronized only to one other subtree to avoid naming conflicts and change conflicts. To take advantage of Windows Sync, use it with a Directory Server supplier in multi-master replication synchronized to a member of a Windows domain.
Page 114 Chapter 7. Designing Synchronization Which entries are synchronized is set in the synchronization agreement. User entries are synchronized separately from group entries. Additionally, deleting entries is configured separately; deletions have to be specifically synchronized. In the Directory Server, only entries that contain the ntGroup or ntUser object classes and required attributes are synchronized;...
Page 115: Schema Elements Synchronized Between Active Directory And Directory Server
Schema Elements Synchronized Between Active Directory and Directory Server Changing the default sync agreement is described in the Administrator's Guide, and the available sync agreement attributes are listed in the Configuration, Command, and File Reference. 7.3. Schema Elements Synchronized Between Active Directory and Directory Server All synchronized entries in the Directory Server, whether they originated in the Directory Server or in the Windows server, have the following special synchronization attributes:...
Page 116 Chapter 7. Designing Synchronization Directory Server Active Directory name ntUserDomainId sAMAccountName ntUserHomeDir homeDirectory ntUserScriptPath scriptPath ntUserLastLogon lastLogon ntUserLastLogoff lastLogoff ntUserAcctExpires accountExpires ntUserCodePage codePage ntUserLogonHours logonHours ntUserMaxStorage maxStorage ntUserProfile profilePath ntUserParms userParameters ntUserWorkstations userWorkstations Table 7.1. User Schema Mapped between Directory Server and Active Directory physicalDeliveryOfficeName description postOfficeBox...
Page 117: Password Policies
User Schema Differences between Red Hat Directory Server and Active Directory 7.3.2.1. Values for cn Attributes In Directory Server, the cn attribute can be multi-valued, while in Active Directory this attribute must have only a single value. When the Directory Server cn attribute is synchronized, then, only one value is sent to the Active Directory peer.
Page 118: Active Directory
Chapter 7. Designing Synchronization 7.3.2.4. Constraints on the initials Attribute For the initials attribute, Active Directory imposes a maximum length constraint of six characters, but Directory Server does not have a length limit. If an initials attribute longer than six characters is added to Directory Server, the value is trimmed when it is synchronized with the Active Directory entry.
Page 119 Group Schema Differences between Red Hat Directory Server and Active Directory 7.3.4. Group Schema Differences between Red Hat Directory Server and Active Directory Although Active Directory supports the same basic X.500 object classes as Directory Server, there are a few incompatibilities of which administrators should be aware. Nested groups (where a group contains another group as a member) are supported and for WinSync are synchronized.
Page 121: Designing A Secure Directory
Chapter 8. Designing a Secure Directory How the data in Red Hat Directory Server are secured affects all of the previous design areas. Any security design needs to protect the data contained by the directory and meet the security and privacy needs of the users and applications.
Page 122: Analyzing Security Needs
Chapter 8. Designing a Secure Directory For example, if the directory cannot detect tampering, an attacker could change a client's request to the server (or not forward it) and change the server's response to the client. SSL and similar technologies can solve this problem by signing information at either end of the connection. For more Section 8.9, “Securing Server to Server information about using SSL with Directory Server, see Connections”.
Page 123: Ensuring Data Privacy And Integrity
Ensuring Data Privacy and Integrity A restrictive method requires minutely understanding the information needs of each category of user inside, and possibly outside, of the organization. Irrespective of the method used to determine access rights, create a simple table that lists the categories of users in the organization and the access rights granted to each.
Page 124: Overview Of Security Methods
Chapter 8. Designing a Secure Directory • Information pertaining to individual subscribers example.com needs the following access controls: • Provide access to the directory administrators of hosted companies (example_a and example_b) to their own directory information. • Implement access control policies for hosted companies' directory information. •...
Page 125: Selecting Appropriate Authentication Methods
Selecting Appropriate Authentication Methods 8.4. Selecting Appropriate Authentication Methods A basic decision regarding the security policy is how users access the directory. Are anonymous users allowed to access the directory, or is every user required to log into the directory with a username and password (authenticate)? Directory Server provides the following methods for authentication: Section 8.4.1, “Anonymous Access”...
Page 126: Simple Password
Chapter 8. Designing a Secure Directory Although the directory allows anonymous access for read, Joe cannot access his own entry because it does not contain a password that matches the one he provided in the ldapsearch command. 8.4.2. Simple Password If anonymous access is not allowed, users must authenticate to the directory before they can access the directory contents.
Page 127: Proxy Authentication
Simple Password over SSL/TLS For more information about certificates and SSL, see the Administrator's Guide. 8.4.4. Simple Password over SSL/TLS When a secure connection is established between Directory Server and a client application using SSL or the Start TLS operation, the server can demand an extra level of authentication by requesting a password.
Page 128: Preventing Authentication By Account Deactivation
Chapter 8. Designing a Secure Directory For more information on this topic, check out the "Proxied Authorization ACI Example" section in the "Managing Access Control" chapter of the Administrator's Guide. 8.5. Preventing Authentication by Account Deactivation A user account or a set of accounts can be temporarily deactivated. After an account has been deactivated, that user cannot bind to the directory, and the authentication operation fails.
Page 129 How Password Policy Works • A particular user of the directory. Such a policy is known as the user level or local password policy. When configured and enabled, the policy is applied to the specified user only. This can define different password policies for different directory users. For example, specify that some users change their passwords daily, some users change it monthly, and all other users change it every six months.
Page 130 Chapter 8. Designing a Secure Directory Figure 8.1. Password Policy Checking Process In addition to bind requests, password policy checking also occurs during add and modify operations if the userPassword attribute (explained in the following section) is present in the request. Modifying the value of userPassword checks two password policy settings: •...
Page 131: Password Policy Attributes
Password Policy Attributes • The password minimum length policy is activated. If the new value of userPassword is less than the required minimum length, the server returns a constraintViolation error. The password update operation fails. • The password syntax checking policy is activated. If the new value of userPassword is the same as another attribute of the entry, the server returns a constraintViolation error.
Page 132: Password Expiration
Chapter 8. Designing a Secure Directory 8.6.2.2. User-Defined Passwords The password policy can be set either to allow or not to allow users to change their own passwords. A good password is the key to a strong password policy. Good passwords do not use trivial words; any word that can be found in a dictionary, names of pets or children, birthdays, user IDs, or any other information about the user that can be easily discovered (or stored in the directory itself), is a poor choice for a password.
Page 133: Grace Login Limit
Password Policy Attributes 8.6.2.5. Grace Login Limit A grace period for expired passwords means that users can still log in to the system, even if their password has expired. To allow some users to log in using an expired password, specify the number of grace login attempts that are allowed to a user after the password has expired.
Page 134: Password Minimum Age
Chapter 8. Designing a Secure Directory 8.6.2.8. Password Minimum Age The password policy can prevent users from changing their passwords for a specified time. When used in conjunction with the passwordHistory attribute, users are discouraged from reusing old passwords. For example, if the password minimum age (passwordMinAge) attribute is two days, users cannot repeatedly change their passwords during a single session.
Page 135: Designing Access Control
Designing a Password Policy in a Replicated Environment The lockout policy works in conjunction with the password policy to provide further security. The account lockout feature protects against crackers who try to break into the directory by repeatedly trying to guess a user's password. A specific user can be locked out of the directory after a given number of failed attempts to bind.
Page 136: About The Aci Format
Chapter 8. Designing a Secure Directory In addition, permissions can be set for a specific user, for all users belonging to a specific group, or for all users of the directory. Lastly, access can be defined for a network location such as an IP address or a DNS name.
Page 137 About the ACI Format attributes that are targeted or by explicitly naming the attributes that are not targeted by the ACI. Excluding attributes in the target sets a permission for all but a few attributes allowed by an object class structure. 8.7.1.2.
Page 138: Bind Rules
Chapter 8. Designing a Secure Directory Permission Description Proxy Indicates that the user can use any other DN, except Directory Manager, to access the directory with the rights of this DN. 8.7.1.3. Bind Rules The bind rule usually indicates the bind DN subject to the permission. It can also specify bind attributes such as time of day or IP address.
Page 139: Allowing Or Denying Access
Setting Permissions rule states that when two conflicting permissions exist, the permission that denies access always takes precedence over the permission that grants access. For example, if write permission is denied at the directory's root level, and that permission is applied to everyone accessing the directory, then no user can write to the directory regardless of any other permissions that may allow write access.
Page 140: Where To Place Access Control Rules
Chapter 8. Designing a Secure Directory For example, to make sure that Mail Administrators do not allow write access to the common name attribute, then set an ACI that explicitly denies write access to the common name attribute. 8.7.2.4. Where to Place Access Control Rules Access control rules can be placed on any entry in the directory.
Page 141 Viewing ACIs: Get Effective Rights • An administrator can use the get effective rights command for minute access control, such as allowing certain groups or users access to entries and restricting others. For example, members of the QA Managers group may have the right to search and read attributes such as title and salary, but only HR Group members have the rights to modify or delete them.
Page 142 Chapter 8. Designing a Secure Directory street attribute were added with read, compare, and search rights, then street: rsc would appear in the attributeLevelRights results. It is possible to return rights for attributes which are not normally included in the search results, like non-existent attributes or operational attributes.
Page 143: Database Encryption
Database Encryption • Identify the smallest set of attributes on any given ACI. When allowing or denying access to a subset of attributes on an object, determine whether the smallest list is the set of attributes that are allowed or the set of attributes that are denied. Then express the ACI so that it only requires managing the smallest list.
Page 144: Securing Server To Server Connections
Chapter 8. Designing a Secure Directory For information on using database encryption, refer to the "Configuring Directory Databases" chapter in the Red Hat Directory Server Administrator's Guide. 8.9. Securing Server to Server Connections After designing the authentication scheme for identified users and the access control scheme for protecting information in the directory, to design a way to protect the integrity of the information passed between servers and client applications.
Page 145 Other Security Resources http://www.securityfocus.com • SecurityFocus.com http://www.cert.org • Computer Emergency Response Team (CERT) Coordination Center http://www.cert.org/security-improvement/ • CERT Security Improvement Modules...
Page 147: Directory Design Examples
Chapter 9. Directory Design Examples The design the directory service depends on the size and nature of the enterprise. This chapter provides a couple of examples of how a directory can be applied within a variety of different settings. These examples are a starting point for developing a real-life directory service deployment plan. 9.1.
Page 148 Chapter 9. Directory Design Examples The examplePerson object class allows one attribute, the exampleID attribute. This attribute contains the special employee number assigned to each Example Corp. employee. In the future, Example Corp. can add new attributes to the examplePerson object class as needed. 9.1.3.
Page 149: Database Topology
Local Enterprise Topology Design Figure 9.1. Directory Tree for Example Corp. 9.1.4. Local Enterprise Topology Design At this point, Example Corp. needs to design its database and server topologies. The following sections describe each topology in detail. 9.1.4.1. Database Topology The company designs a database topology in which the people branch is stored in one database (DB1), the groups branch is stored in another database (DB2), and the resources branch, roles branch, and the root suffix information are stored in a third database (DB3).
Page 150: Supplier Architecture
Chapter 9. Directory Design Examples Figure 9.3. Server Topology for Example Corp. Modify requests from compatible servers are routed to the appropriate consumer server. The consumer server uses smart referrals to route the request to the supplier server responsible for the master copy of the data being modified.
Page 151: Supplier Consumer Architecture
Local Enterprise Replication Design Figure 9.4. Supplier Architecture for Example Corp. 9.1.5.2. Supplier Consumer Architecture The following diagram describes how the supplier servers replicate to each consumer in the Example Corp. deployment of the directory. Each of the three consumer servers is updated by the two supplier servers.
Page 152 Chapter 9. Directory Design Examples Figure 9.5. Supplier and Consumer Architecture for Example Corp. 9.1.6. Local Enterprise Security Design Example Corp. decides on the following security design to protect its directory data: • They create an ACI that allows employees to modify their own entries. Users can modify all attributes except the uid, manager and department attributes.
Page 153: Design Example: A Multinational Enterprise And Its Extranet
Local Enterprise Tuning and Optimizations For more information about setting resource limits based on the bind DN, refer to the "User Account Management" chapter in the Red Hat Directory Server Administrator's Guide. • They create a password policy which specifies that passwords must be at least eight characters in length and expire after 90 days.
Page 154 Chapter 9. Directory Design Examples work in the countries where the Example Corp. offices are located. Example Corp. decides to launch a company-wide LDAP directory to improve internal communication, to make it easier to develop and deploy web applications, and to increase security and privacy. Designing a directory tree for an international corporation involves determining how to collect directory entries logically, how to support data management, and how to support replication on a global scale.
Page 155 Multinational Enterprise Directory Tree Design The examplePartner object class allows one attribute, the examplePartnerID attribute. This attribute contains the unique ID assigned by Example Corp. International to each trade partner. Section 3.4, “Customizing the For information about customizing the default directory schema, see Schema”.
Page 156 Chapter 9. Directory Design Examples Figure 9.7. Directory Tree for Example Corp. International's Intranet The entry for the l=Asia entry appears in LDIF as follows: dn: l=Asia, dc=exampleCorp,dc=com objectclass: top objectclass: locality l: Asia description: includes all sites in Asia The following diagram illustrates the directory tree for Example Corp.'s extranet:...
Page 157 Multinational Enterprise Topology Design Figure 9.8. Directory Tree for Example Corp. International's Extranet 9.2.4. Multinational Enterprise Topology Design At this point, Example Corp. designs its database and server topologies. The following sections describe each topology in more detail. 9.2.4.1. Database Topology The following diagram illustrates the database topology of one of Example Corp.'s main localities, Europe: Figure 9.9.
Page 158: Server Topology
Chapter 9. Directory Design Examples The database links point to databases stored locally in each country. For example, operation requests received by the Example Corp. Europe server for the data under the l=US branch are chained by a database link to a database on a server in Austin, Texas. For more information about database links Section 5.3.2, “Using Chaining”.
Page 159 Multinational Enterprise Topology Design Figure 9.11. Server Topology for Example Corp. Europe The data master for Example Corp.'s extranet is in Europe. This data is replicated to two consumer servers in the US data center and two consumer servers in the Asia data center. Overall, Example Corp.
Page 160 Chapter 9. Directory Design Examples Figure 9.12. Server Topology for Example Corp. International's Extranet The hub servers replicate data to two consumer servers in each of the data centers in Europe, the US and Asia. 9.2.5. Multinational Enterprise Replication Design Example Corp.
Page 161 Multinational Enterprise Replication Design 9.2.5.1. Supplier Architecture For the Example Corp. intranet, each locality stores the master copy of its data and uses database links to chain to the data of other localities. For the master copy of its data, each locality uses a multi- master replication architecture.
Page 162 Chapter 9. Directory Design Examples Figure 9.14. Multi-Master Replication Design for Example Corp. Europe and Example Corp. US The same relationship exists between Example Corp. US and Example Corp. Asia, and between Example Corp. Europe and Example Corp. Asia. 9.2.6. Multinational Enterprise Security Design Example Corp.
Page 163 Multinational Enterprise Security Design For more information about macro ACIs, refer to the Red Hat Directory Server Administrator's Guide. Example Corp. adds the following access controls to support its extranet: • Example Corp. decides to use certificate-based authentication for all extranet activities. When people log in to the extranet, they need a digital certificate.

Red Hat DIRECTORY SERVER 8.1 - DEPLOYMENT Deployment Manual

Quick Links

Need help?

Questions and answers

Subscribe to Our Youtube Channel

Related Manuals for Red Hat DIRECTORY SERVER 8.1 - DEPLOYMENT

Summary of Contents for Red Hat DIRECTORY SERVER 8.1 - DEPLOYMENT

Table of Contents