Deployment Guide
Concepts and configuration options for planning an effective directory service
Abstract
Making Open Source More Inclusive
Preface
1. Directory Server Overview
- Multi-supplier replication — Provides a highly available directory service for both read and write operations. Multi-supplier replication can be combined with simple and cascading replication scenarios to provide a highly flexible and scalable replication environment.
- Chaining and referrals — Increases the power of the directory by storing a complete logical view of the directory on a single server while maintaining data on a large number of Directory Servers transparently for clients.
- Roles and classes of service — Provides a flexible mechanism for grouping and sharing attributes between entries dynamically.
- Efficient access control mechanisms — Provides support for macros that dramatically reduce the number of access control statements used in the directory and increase the scalability of access control evaluation.
- Resource-limits by bind DN — Grants the power to control the amount of server resources allocated to search operations based on the bind DN of the client.
- Multiple databases — Provides a simple way of breaking down the directory data to simplify the implementation of replication and chaining in the directory service.
- Password policy and account lockout — Defines a set of rules that govern how passwords and user accounts are managed in the Directory Server.
- TLS provides secure authentication and communication over the network, using the Mozilla Network Security Services (NSS) libraries for cryptography.
- An LDAP server — The LDAP v3-compliant network daemon.
- A web console — A graphical management console that reduces the effort of setting up and maintaining the directory service.
- SNMP agent — Can monitor the Directory Server using the Simple Network Management Protocol (SNMP).
Chapter 1. Introduction to Directory Services
1.1. About Directory Services
- Physical device information, such as data about the printers in an organization, such as location, color or black and white, manufacturer, date of purchase, and serial number.
- Public employee information, such as name, email address, and department.
- Private employee information, such as salary, government identification numbers, home addresses, phone numbers, and pay grade.
- Contract or account information, such as the name of a client, final delivery date, bidding information, contract numbers, and project dates.
1.1.1. About Global Directory Services
1.1.2. About LDAP
1.2. Introduction to Directory Server
- The core Directory Server LDAP server, the LDAP v3-compliant network daemon (
ns-slapd
) and all of the associated plug-ins, command-line tools for managing the server and its databases, and its configuration and schema files. For more information about the command-line tools, see the Red Hat Directory Server Configuration, Command, and File Reference. - Administration Server, a web server which controls the different portals that access the LDAP server. For more information about the Administration Server, see Red Hat Directory Server Administration Guide.
- Web Console, a graphical management console that reduces the effort of setting up and maintaining the directory service. For more information about the web console, see the Red Hat Directory Server Administration Guide.
- SNMP agent to monitor the Directory Server using the Simple Network Management Protocol (SNMP). For more information about SNMP monitoring, see the Red Hat Directory Server Administration Guide.
1.2.1. Overview of the Server Frontend
Note
ns-slapd
.
1.2.2. Server Plug-ins Overview
1.2.3. Overview of the Basic Directory Tree
Figure 1.1. Layout of Default Directory Server Directory Tree
cn=config
, the subtree containing information about the server's internal configuration.cn=monitor
, the subtree containing Directory Server server and database monitoring statistics.cn=schema
, the subtree containing the schema elements currently loaded in the server.- user_suffix, the suffix for the default user database created when the Directory Server is setup. The name of the suffix is defined by the user when the server is created; the name of the associated database is
userRoot
. The database can be populated with entries by importing an LDIF file at setup or entries can be added to it later.The user_suffix suffix frequently has adc
naming convention, likedc=example,dc=com
. Another common naming attribute is theo
attribute, which is used for an entire organization, likeo=example.com
.
Figure 1.2. Expanded Directory Tree for Example Corp.
1.3. Directory Server Data Storage
1.3.1. About Directory Entries
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.
1.3.1.1. Performing Queries on Directory Entries
ou=people,dc=example,dc=com
, then the search operation examines only the ou=people
subtree in the dc=example,dc=com
directory tree.
ldapsubentry
object class) are not returned by default with LDAP searches. Administrative objects, for example, can be entries used to define a role or a class of service. To include these entries in the search response, clients need to search specifically for entries with the ldapsubentry
object class. See Section 4.3.2, “About Roles” for more information about roles and Section 5.3, “About Classes of Service” for more information about class of service.
1.3.2. Distributing Directory Data
1.4. Directory Design Overview
1.4.1. Design Process Outline
- The directory contains data such as user names, telephone numbers, and group details. This chapter analyzes the various sources of data in the organization and understand their relationship 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.
- The directory is designed to support one or more directory-enabled applications. These applications have requirements of the data stored in the directory, such as the file format. The directory schema determines the characteristics of the data stored in the directory. The standard schema shipped with Directory Server is introduced in this chapter, as well as a description of how to customize the schema and tips for maintaining a consistent schema.
- Along with determining what information is contained in the Directory Server, it is important to determine how that information is going to be organized and referenced. This chapter introduces the directory tree and gives an overview of the design of the data hierarchy. Sample directory tree designs are also provided.
- Topology design means how the directory tree is divided among multiple physical Directory Servers and how these servers communicate with one another. The general principles behind design, using multiple databases, the mechanisms available for linking the distributed data together, and how the directory itself keeps track of distributed data are all described in this chapter.
- When replication is used, multiple Directory Servers maintain the same directory data to increase performance and provide fault tolerance. This chapter describes how replication works, what kinds of data can be replicated, common replication scenarios, and tips for building a high-availability directory service.
- The information stored in the Red Hat Directory Server can by synchronized with information stored in Microsoft Active Directory databases for better integration with a mixed-platform infrastructure. This chapter describes how synchronization works, what kinds of data can be synched, and considerations for the type of information and locations in the directory tree which are best for synchronization.
- Finally, plan how to protect the data in the directory and design the other aspects of the service to meet the security requirements of the users and applications. This chapter covers common security threats, an overview of security methods, the steps involved in analyzing security needs, and tips for designing access controls and protecting the integrity of the directory data.
1.4.2. Deploying the Directory
- An estimate of the required resources
- A schedule of what needs to be accomplished and when
- A set of criteria for measuring the success of the deployment
1.5. Other General Directory Resources
- 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.
Chapter 2. Planning the Directory Data
2.1. Introduction to Directory Data
- It is read more often than written.
- It is of interest to more than one person or group. For example, an employee's name or the physical location of a printer can be of interest to many people and applications.
- It will be accessed from more than one physical location.
2.1.1. Information to Include in the Directory
- Contact information, such as telephone numbers, physical addresses, and email addresses.
- Descriptive information, such as an employee number, job title, manager or administrator identification, and job-related interests.
- Organization contact information, such as a telephone number, physical address, administrator identification, and business description.
- Device information, such as a printer's physical location, type of printer, and the number of pages per minute that the printer can produce.
- Contact and billing information for a corporation's trading partners, clients, and customers.
- Contract information, such as the customer's name, due dates, job description, and pricing information.
- Individual software preferences or software configuration information.
- Resource sites, such as pointers to web servers or the file system of a certain file or application.
- Contract or client account details
- Payroll data
- Physical device information
- Home contact information
- Office contact information for the various sites within the enterprise
2.1.2. Information to Exclude from the Directory
2.2. Defining Directory Needs
- What should be put in the directory today?
- What immediate problem is solved by deploying a directory?
- What are the immediate needs of the directory-enabled application being used?
- What information is going to be added to the directory in the near future? For example, an enterprise might use an accounting package that does not currently support LDAP but will be LDAP-enabled in a few months. Identify the data used by LDAP-compatible applications, and plan for the migration of the data into the directory as the technology becomes available.
- What information might be stored in the directory in the future? For example, a hosting company may have future customers with different data requirements than their current customers, such as needing to store images or media files. While this is the hardest answer to anticipate, doing so may pay off in unexpected ways. At a minimum, this kind of planning helps identify data sources that might not otherwise have been considered.
2.3. Performing a Site Survey
- Identify the applications that use the directory.Determine the directory-enabled applications deployed across the enterprise and their data needs.
- Identify data sources.Survey the enterprise and identify sources of data, such as Active Directory, other LDAP servers, PBX systems, human resources databases, and email systems.
- Characterize the data the directory needs to contain.Determine what objects should be present in the directory (for example, people or groups) and what attributes of these objects to maintain in the directory (such as usernames and passwords).
- Determine the level of service to provide.Decide how available the directory data needs to be to client applications, and design the architecture accordingly. How available the directory needs to be affects how data are replicated and how chaining policies are configured to connect data stored on remote servers.See Chapter 7, Designing the Replication Process for more information about replication and Section 6.1, “Topology Overview” for more information on chaining.
- Identify a data supplier.A data supplier 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 supplier.
- Determine data ownership.For each piece of data, determine the person responsible for ensuring that the data is up-to-date.
- Determine data access.If data are imported from other sources, develop a strategy for both bulk imports and incremental updates. As a part of this strategy, try to manage data in a single place, and limit the number of applications that can change the data. Also, limit the number of people who write to any given piece of data. A smaller group ensures data integrity while reducing the administrative overhead.
- Document the site survey.
2.3.1. Identifying the Applications That Use the Directory
- Directory browser applications, such as online telephone books. Decide what information (such as email addresses, telephone numbers, and employee name) users need, and include it in the directory.
- Email applications, especially email servers. All email servers require email addresses, user names, and some routing information to be available in the directory. Others, however, require more advanced information such as the place on disk where a user's mailbox is stored, vacation notification information, and protocol information (IMAP versus POP, for example).
- Directory-enabled human resources applications. These require more personal information such as government identification numbers, home addresses, home telephone numbers, birth dates, salary, and job title.
- Microsoft Active Directory. Through Windows User Sync, Windows directory services can be integrated to function in tandem with the Directory Server. Both directories can store user information (user names and passwords, email addresses, telephone numbers) and group information (members). Style the Directory Server deployment after the existing Windows server deployment (or vice versa) so that the users, groups, and other directory data can be smoothly synchronized.
Application | Class of Data | Data |
---|---|---|
Phonebook | People | Name, email address, phone number, user ID, password, department number, manager, mail stop. |
Web server | People, groups | User ID, password, group name, groups members, group owner. |
Calendar server | People, meeting rooms | Name, user ID, cube number, conference room name. |
- The data required by various legacy applications and users
- The ability of legacy applications to communicate with an LDAP directory
2.3.2. Identifying Data Sources
- Identify organizations that provide information.Locate all the organizations that manage information essential to the enterprise. Typically, this includes the information services, human resources, payroll, and accounting departments.
- Identify the tools and processes that are information sources.Some common sources for information are networking operating systems (Windows, Novell Netware, UNIX NIS), email systems, security systems, PBX (telephone switching) systems, and human resources applications.
- Determine how centralizing each piece of data affects the management of data.Centralized data management can require new tools and new processes. Sometimes centralization requires increasing staff in some organizations while decreasing staff in others.
Data Source | Class of Data | Data |
---|---|---|
Human resources database | People | Name, address, phone number, department number, manager. |
Email system | People, Groups | Name, email address, user ID, password, email preferences. |
Facilities system | Facilities | Building names, floor names, cube numbers, access codes. |
2.3.3. Characterizing the Directory Data
- Format
- Size
- Number of occurrences in various applications
- Data owner
- Relationship to other directory data
Data | Format | Size | Owner | Related to |
---|---|---|---|---|
Employee Name | Text string | 128 characters | Human resources | User's entry |
Fax number | Phone number | 14 digits | Facilities | User's entry |
Email address | Text | Many character | IS department | User's entry |
2.3.4. Determining Level of Service
2.3.5. Considering a Data Supplier
- Replication among Directory Servers
- Synchronization between Directory Server and Active Directory
- Independent client applications which access the Directory Server data
- Manage the data in both the directory and all applications that do not use the directory.Maintaining multiple data suppliers does not require custom scripts for moving data in and out of the directory and the other applications. However, if data changes in one place, someone has to change it on all the other sites. Maintaining supplier data in the directory and all applications not using the directory can result in data being unsynchronized across the enterprise (which is what the directory is supposed to prevent).
- Manage the data in some application other than the directory, and then write scripts, programs, or gateways to import that data into the directory.Managing data in non-directory applications makes the most sense if there are one or two applications that are already used to manage data, and the directory will be used only for lookups (for example, for online corporate telephone books).
2.3.6. Determining Data Ownership
- Allow read-only access to the directory for everyone except a small group of directory content managers.
- Allow individual users to manage some strategic subset of information for themselves.This subset of information might include their passwords, descriptive information about themselves and their role within the organization, their automobile license plate number, and contact information such as telephone numbers or office numbers.
- Allow a person's manager to write to some strategic subset of that person's information, such as contact information or job title.
- Allow an organization's administrator to create and manage entries for that organization.This approach allows an organization's administrators to function as the directory content managers.
- Create roles that give groups of people read or write access privileges.For example, there can be roles created for human resources, finance, or accounting. Allow each of these roles to have read access, write access, or both to the data needed by the group. This could include salary information, government identification numbers, and home phone numbers and address.For more information about roles and grouping entries, see Section 4.3, “Grouping Directory Entries”.
2.3.7. Determining Data Access
- Can the data be read anonymously?The LDAP protocol supports anonymous access and allows easy lookups for common information such as office sites, email addresses, and business telephone numbers. However, anonymous access gives anyone with access to the directory access to the common information. Consequently, use anonymous access sparingly.
- Can the data be read widely across the enterprise?Access control can be set so that the client must log into (or bind to) the directory to read specific information. Unlike anonymous access, this form of access control ensures that only members of the organization can view directory information. It also captures login information in the directory's access log so there is a record of who accessed the information.For more information about access controls, see Section 9.7, “Designing Access Control”.
- Is there an identifiable group of people or applications that need to read the data?Anyone who has write privileges to the data generally also needs read access (with the exception of write access to passwords). There may also be data specific to a particular organization or project group. Identifying these access needs helps determine what groups, roles, and access controls the directory needs.For information about groups and roles, see Chapter 4, Designing the Directory Tree. For information about access controls, see Section 9.7, “Designing Access Control”.
2.4. Documenting the Site Survey
Data Name | Owner | Supplier Server/Application | Self Read/Write | Global Read | HR Writable | IS Writable |
---|---|---|---|---|---|---|
Employee name | HR | PeopleSoft | Read-only | Yes (anonymous) | Yes | Yes |
User password | IS | Directory US-1 | Read/Write | No | No | Yes |
Home phone number | HR | PeopleSoft | Read/Write | No | Yes | No |
Employee location | IS | Directory US-1 | Read-only | Yes (must log in) | No | Yes |
Office phone number | Facilities | Phone switch | Read-only | Yes (anonymous) | No | No |
- Owner. Human Resources owns this information and therefore is responsible for updating and changing it.
- Supplier Server/Application. The PeopleSoft application manages employee name information.
- Self Read/Write. A person can read his own name but not write (or change) it.
- Global Read. Employee names can be read anonymously by everyone with access to the directory.
- HR Writable. Members of the human resources group can change, add, and delete employee names in the directory.
- IS Writable. Members of the information services group can change, add, and delete employee names in the directory.
2.5. Repeating the Site Survey
Chapter 3. Designing the Directory Schema
3.1. Schema Design Process Overview
- Choosing predefined schema elements to meet as many of data needs as possible.
- Extending the standard Directory Server schema to define new elements to meet other remaining needs.
- Planning for schema maintenance.
3.2. Standard Schema
3.2.1. Schema Format
cn=schema
entry.
X-ORIGIN
, which describes where the schema entry was defined originally.
X-ORIGIN
field refers to RFC 2252. If the entry is defined by Red Hat for the Directory Server's use, the X-ORIGIN
field contains the value Netscape Directory Server
.
person
object class appears in the schema as follows:
objectclasses: ( 2.5.6.6 NAME 'person' DESC 'Standard Person Object Class' SUP top MUST (objectclass $ sn $ cn) MAY (description $ seeAlso $ telephoneNumber $ userPassword) X-ORIGIN 'RFC 2252' )
2.5.6.6
), the name of the object class (person
), a description of the class (Standard Person
), and then lists the required attributes (objectclass
, sn
, and cn
) and the allowed attributes (description
, seeAlso
, telephoneNumber
, and userPassword
).
3.2.2. Standard Attributes
commonName
(cn
). So, an entry for a person named Babs Jensen has the attribute-data pair cn: Babs Jensen
.
dn: uid=bjensen,ou=people,dc=example,dc=com objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson cn: Babs Jensen sn: Jensen givenName: Babs givenName: Barbara mail: bjensen@example.com
givenName
attribute appears twice, each time with a unique value.
- 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.
cn
attribute definition appears in the schema as follows:
attributetypes: ( 2.5.4.3 NAME 'cn' DESC 'commonName Standard Attribute' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
3.2.3. Standard Object Classes
- A unique name.
- An object identifier (OID) that names the object.
- A set of mandatory attributes.
- A set of allowed (or optional) attributes.
person
object class appears in the schema as follows:
objectclasses: ( 2.5.6.6 NAME 'person' DESC 'Standard Person Object Class' SUP top MUST (objectclass $ sn $ cn) MAY (description $ seeAlso $ telephoneNumber $ userPassword) X-ORIGIN 'RFC 2252' )
3.3. Mapping the Data to the Default Schema
3.3.1. Viewing the Default Directory Schema
/usr/share/dirsrv/schema/
directory.
00core.ldif
file. The configuration schema used by earlier versions of the directory can be found in the 50ns-directory.ldif
file.
Warning
3.3.2. Matching Data to Schema Elements
- Identify the type of object the data describes.Select an object that best matches the data described in the site survey. Sometimes, a piece of data can describe multiple objects. Determine if the difference needs to be noted in the directory schema.For example, a telephone number can describe an employee's telephone number and a conference room's telephone number. Determine if these different sorts of data need to be considered different objects in the directory schema.
- Select a similar object class from the default schema.It is best to use the common object classes, such as groups, people, and organizations.
- Select a similar attribute from the matching object class.Select an attribute from within the matching object class that best matches the piece of data identified in the site survey.
- Identify the unmatched data from the site survey.If there are some pieces of data that do not match the object classes and attributes defined by the default directory schema, customize the schema. See Section 3.4, “Customizing the Schema” for more information.
Data | Owner | Object Class | Attribute |
---|---|---|---|
Employee name | HR | person | cn (commonName) |
User password | IS | person | userPassword |
Home phone number | HR | inetOrgPerson | homePhone |
Employee location | IS | inetOrgPerson | localityName |
Office phone number | Facilities | person | telephoneNumber |
person
object class, which inherits from the top
object class. This object class allows several attributes, one of which is the cn
or commonName
attribute to describe the full name of the person. This attribute makes the best match for containing the employee name data.
person
object class, and the userPassword
attribute is listed in the allowed attributes for the person
object class.
person
object class. The home phone number describes an aspect of a person in an organization's enterprise network. This object corresponds to the inetOrgPerson
object class in the directory schema. The inetOrgPerson
object class inherits from the organizationPerson
object class, which in turn inherits from the person
object class. Among the inetOrgPerson
object's allowed attributes is the homePhone
attribute, which is appropriate for containing the employee's home telephone number.
Note
3.4. Customizing the Schema
- Keep the schema as simple as possible.
- Reuse existing schema elements whenever possible.
- Minimize the number of mandatory attributes defined for each object class.
- Do not define more than one object class or attribute for the same purpose (data).
- Do not modify any existing definitions of attributes or object classes.
Note
99user.ldif
file. Each individual instance maintains its own 99user.ldif
file in the /etc/dirsrv/slapd-instance_name/schema/
directory. It is also possible to create custom schema files and dynamically reload the schema into the server.
3.4.1. When to Extend the Schema
3.4.2. Getting and Assigning Object Identifiers
- Obtain an OID from the Internet Assigned Numbers Authority (IANA) or a national organization.In some countries, corporations already have OIDs assigned to them. If your organization does not already have an OID, one can be obtained from IANA. For more information, go to the IANA website at http://www.iana.org/cgi-bin/enterprise.pl.
- Create an OID registry to track OID assignments.An OID registry is a list of the OIDs and descriptions of the OIDs used in the directory schema. This ensures that no OID is ever used for more than one purpose. Then publish the OID registry with the schema.
- Create branches in the OID tree to accommodate schema elements.Create at least two branches under the OID branch or the directory schema, using OID
.1
for attributes and OID.2
for object classes. To define custom matching rules or controls, add new branches as needed (OID.3
, for example).
3.4.3. Naming Attributes and Object Classes
example
before each of their custom schema elements. They might add a special object class called examplePerson
to identify Example Corp. employees in their directory.
3.4.4. Strategies for Defining New Object Classes
- Create many new object classes, one for each object class structure to which to add an attribute.
- 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.
exampleDateOfBirth
, examplePreferredOS
, exampleBuildingFloor
, and exampleVicePresident
. A simple solution is to create several object classes that allow some subset of these attributes.
- One object class,
examplePerson
, is created and allowsexampleDateOfBirth
andexamplePreferredOS
. The parent ofexamplePerson
isinetOrgPerson
. - A second object class,
exampleOrganization
, allowsexampleBuildingFloor
andexampleVicePresident
. The parent ofexampleOrganization
is theorganization
object class.
objectclasses: ( 2.16.840.1.117370.999.1.2.3 NAME 'examplePerson' DESC 'Example Person Object Class' SUP inetorgPerson MAY (exampleDateOfBirth $ examplePreferredOS) ) objectclasses: ( 2.16.840.1.117370.999.1.2.4 NAME 'exampleOrganization' DESC 'Organization Object Class' SUP organization MAY (exampleBuildingFloor $ exampleVicePresident) )
objectclasses: (2.16.840.1.117370.999.1.2.5 NAME 'exampleEntry' DESC 'Standard Entry Object Class' SUP top AUXILIARY MAY (exampleDateOfBirth $ examplePreferredOS $ exampleBuildingFloor $ exampleVicePresident) )
exampleEntry
object class is marked AUXILIARY
, meaning that it can be used with any entry regardless of its structural object class.
Note
2.16.840.1.117370
) is based on the former Netscape OID prefix. To create custom object classes, obtain an OID as described in Section 3.4.2, “Getting and Assigning Object Identifiers”.
- Multiple object classes result in more schema elements to create and maintain.Generally, the number of elements remains small and needs little maintenance. However, it may be easier to use a single object class if there are more than two or three object classes added to the schema.
- 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.
- Single object classes simplify data design when there is data that can be applied to more than one type of object class, such as both people and asset entries.For example, a custom
preferredOS
attribute may be set on both a person and a group entry. A single object class can allow this attribute on both types of entries. - Avoid required attributes for new object classes.Specifying
require
instead ofallow
for attributes in new object classes can make the schema inflexible. When creating a new object class, useallow
rather thanrequire
as much as possible.After defining a new object class, decide what attributes it allows and requires, and from what object classes it inherits attributes.
3.4.5. Strategies for Defining New Attributes
person
, organizationalPerson
, or inetOrgPerson
object classes support by default. As an example, no attribute exists within the standard Directory Server schema to store birth dates. A new attribute, dateOfBirth
, can be created and set as an allowed attribute within a new auxiliary object class, examplePerson
.
attributetypes: ( dateofbirth-oid NAME 'dateofbirth' DESC 'For employee birthdays' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 X-ORIGIN 'Example defined') objectclasses: ( 2.16.840.1.117370.999.1.2.3 NAME 'examplePerson' DESC 'Example Person Object Class' SUP inetorgPerson MAY (exampleDateOfBirth $ cn) X-ORIGIN 'Example defined')
3.4.6. Deleting Schema Elements
3.4.7. Creating Custom Schema Files
99user.ldif
file provided with Directory Server. These schema files hold new, custom attributes and object classes that are specific to the organization. The new schema files should be located in the schema directory, /etc/dirsrv/slapd-instance_name/schema/
.
Note
99user.ldif
or the server could experience problems.
- Manually copy these custom schema files to the instance's schema directory,
/etc/dirsrv/slapd-instance/schema
. To load the schema, restart the server or reload the schema dynamically by running theschema-reload.pl
script. - Modify the schema on the server with an LDAP client such as the web console or
ldapmodify
. - If the server is replicated, then allow the replication process to copy the schema information to each of the consumer servers.With replication, all of the replicated schema elements are copied into the consumer servers'
99user.ldif
file. To keep the schema in a custom schema file, like90example_schema.ldif
, the file has to be copied over to the consumer server manually. Replication does not copy schema files.
ldapmodify
.
99user.ldif
file. The directory does not track where schema definitions are stored. Storing schema elements in the 99user.ldif
file of consumers does not create a problem as long as the schema is maintained on the supplier server only.
99user.ldif
file on the consumer. Having the changes in the 99user.ldif
file may make schema management difficult, as some attributes will appear in two separate schema files on a consumer, once in the original custom schema file copied from the supplier and again in the 99user.ldif
file after replication.
3.4.8. Custom Schema Best Practices
3.4.8.1. Naming Schema Files
[00-99]yourName.ldif
99user.ldif
. This lets Directory Server write to 99user.ldif
, both through LDAP tools and the web console.
99user.ldif
file contains attributes with an X-ORIGIN
value of 'user defined'
; however, the Directory Server writes all 'user defined'
schema elements to the highest named file, numerically then alphabetically. If there is a schema file called 99zzz.ldif
, the next time the schema is updated (either through LDAP command-line tools or the web console) all of the attributes with an X-ORIGIN
value of 'user defined'
are written to 99zzz.ldif
. The result is two LDIF files that contain duplicate information, and some information in the 99zzz.ldif
file might be erased.
3.4.8.2. Using 'user defined' as the Origin
'user defined'
in the X-ORIGIN
field of custom schema files (such as 60example.ldif
), because 'user defined'
is used internally by the Directory Server when a schema is added over LDAP. In custom schema files, use something more descriptive, such as 'Example Corp. defined'
.
99user.ldif
manually, use 'user defined'
as the value of X-ORIGIN
. If a different X-ORIGIN
value is set, the server simply may overwrite it.
X-ORIGIN
of value 'user defined'
ensures that schema definitions in the 99user.ldif
file are not removed from the file by the Directory Server. The Directory Server does not remove them because it relies on an X-ORIGIN
of value 'user defined'
to tell it what elements should reside in the 99user.ldif
file.
attributetypes: ( exampleContact-oid NAME 'exampleContact' DESC 'Example Corporate contact' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 X-ORIGIN 'Example defined')
attributetypes: ( exampleContact-oid NAME 'exampleContact' DESC 'Example Corporate contact' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 X-ORIGIN ('Example defined' 'user defined') )
3.4.8.3. Defining Attributes before Object Classes
3.4.8.4. Defining Schema in a Single File
- Be careful with what schema elements are included in each schema file.
- Be careful in naming and updating the schema files. When schema elements are edited through LDAP tools, the changes are automatically written to the last file (alphabetically). Most schema changes, then, write to the default file
99user.ldif
and not to the custom schema file, such as60example.ldif
. Also, the schema elements in99user.ldif
override duplicate elements in other schema files. - Add all the schema definitions to the
99user.ldif
file. This is useful if your are managing the schema through the web console.
3.5. Maintaining Consistent Schema
- Use schema checking to ensure that attributes and object classes conform to the schema rules.
- Use syntax validation to ensure that attribute values match the required attribute syntax.
- Select and apply a consistent data format.
3.5.1. Schema Checking
Note
organizationalPerson
object class, then the common name (cn
) and surname (sn
) attributes are required for the entry. That is, values for these attributes must be set when the entry is created. In addition, there is a long list of attributes that can optionally be used on the entry, including descriptive attributes like telephoneNumber
, uid
, streetAddress
, and userPassword
.
3.5.2. Syntax Validation
telephoneNumber
attribute actually has a valid telephone number for its value.
3.5.2.1. Overview of Syntax Validation
syntax-validate.pl
.
3.5.2.2. Syntax Validation and Other Directory Server Operations
For normal LDAP operations, an attribute is encrypted just before the value is written to the database. This means That encryption occurs after the attribute syntax is validated.
-E
flag with db2ldif
and ldif2db
, which allows syntax validation to occur just fine for the import operation. However, if the encrypted database is exported without using the -E
flag (which is not supported), then an LDIF with encrypted values is created. When this LDIF is then imported, the encrypted attributes cannot be validated, a warning is logged, and attribute validation is skipped in the imported entry.
There may be differences in the allowed or enforced syntaxes for attributes in Windows Active Directory entries and Red Hat Directory Server entries. In that case, the Active Directory values could not be properly synced over because syntax validation enforces the RFC standards in the Directory Server entries.
If the Directory Server 11.0 instance is a supplier which replicates its changes to a consumer, then there is no issue with using syntax validation. However, if the supplier in replication is an older version of Directory Server or has syntax validation disabled, then syntax validation should not be used on the 11.0 consumer because the Directory Server 11.0 consumer may reject attribute values that the supplier allows.
3.5.3. Selecting Consistent Data Formats
- ITU-T Recommendation E.123. Notation for national and international telephone numbers.
- ITU-T Recommendation E.163. Numbering plan for the international telephone services. For example, a US phone number is formatted as
+1 555 222 1717
.
postalAddress
attribute expects an attribute value in the form of a multi-line string that uses dollar signs ($) as line delimiters. A properly formatted directory entry appears as follows:
postalAddress: 1206 Directory Drive$Pleasant View, MN$34200
3.5.4. Maintaining Consistency in Replicated Schema
- Do not modify the schema on a read-only replica.Modifying the schema on a read-only replica introduces an inconsistency in the schema and causes replication to fail.
- Do not create two attributes with the same name that use different syntaxes.If an attribute is created in a read-write replica that has the same name as an attribute on the supplier replica but has a different syntax from the attribute on the supplier, replication will fail.
3.6. Other Schema Resources
- RFC 2251: Lightweight Directory Access Protocol (v3), http://www.ietf.org/rfc/rfc2251.txt
- RFC 2252: LDAPv3 Attribute Syntax Definitions, http://www.ietf.org/rfc/rfc2252.txt
- RFC 2256: Summary of the X.500 User Schema for Use with LDAPv3, http://www.ietf.org/rfc/rfc2256.txt
- Internet Engineering Task Force (IETF), http://www.ietf.org/
- Understanding and Deploying LDAP Directory Services. T. Howes, M. Smith, G. Good, Macmillan Technical Publishing, 1999.
Chapter 4. Designing the Directory Tree
4.1. Introduction to the Directory Tree
- Simplified directory data maintenance.
- Flexibility in creating replication policies and access controls.
- Support for the applications using the directory service.
- Simplified directory navigation for directory users.
Note
4.2. Designing the Directory Tree
- Choosing a suffix to contain the data.
- Determining the hierarchical relationship among data entries.
- Naming the entries in the directory tree hierarchy.
4.2.1. Choosing a Suffix
4.2.1.1. Suffix Naming Conventions
- Globally unique.
- Static, so it rarely, if ever, changes.
- Short, so that entries beneath it are easier to read on screen.
- Easy for a person to type and remember.
example.com
, then the directory suffix is logically dc=example,dc=com
.
dc
attribute represents the suffix by breaking the domain name into its component parts.
dc
defines an component of the domain name.c
contains the two-digit code representing the country name, as defined by ISO.l
identifies the county, city, or other geographical area where the entry is located or that is associated with the entry.st
identifies the state or province where the entry resides.o
identifies the name of the organization to which the entry belongs.
example_a
, such as o=example_a, st=Washington,c=US
.
4.2.1.2. Naming Multiple Suffixes
example_a
and example_b
and store them in separate databases.
Figure 4.1. Including Multiple Directory Trees in a Database
4.2.2. Creating the Directory Tree Structure
4.2.2.1. Branching the Directory
- Branch the tree to represent only the largest organizational subdivisions in the enterprise.Any such branch points should be limited to divisions (such as Corporate Information Services, Customer Support, Sales, and Engineering). Make sure that the divisions used 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. While subtrees can be renamed, it can be a long and resource-intensive process for large suffixes with many children entries. Using generic names that represent the function of the organization (for example, use
Engineering
instead ofWidget Research and Development
) makes it much less likely that you will need to rename a subtree after organizational or project changes. - If there are multiple organizations that perform similar functions, try creating a single branch point for that function instead of branching based along divisional lines.For example, even if there are multiple marketing organizations, each of which is responsible for a specific product line, create a single
ou=Marketing
subtree. All marketing entries then belong to that tree.
Name changes can be avoided if the directory tree structure is based on information that is not likely to change. For example, base the structure on types of objects in the tree rather than organizations. This helps avoid shuffling an entry between organizational units, which requires modifying the distinguished name (DN), which is an expensive operation.
ou=people
ou=groups
ou=services
Figure 4.2. Example Environment Directory Tree
For a hosting environment, create a tree that contains two entries of the object class organization
(o
) and one entry of the object class organizationalUnit
(ou
) beneath the root suffix. For example, Example ISP branches their directory as shown below.
Figure 4.3. Example Hosting Directory Tree
4.2.2.2. Identifying Branch Points
uid=bjensen,ou=people,dc=example,dc=com
.
Figure 4.4. The Directory Tree for Example Corp.
Figure 4.5. Directory Tree for Example ISP
c=US,o=example
, 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. The groups branch contains information about the administrative groups.
- Be consistent.Some LDAP client applications may be confused if the distinguished name (DN) format is inconsistent across the directory tree. That is, if
l
is subordinate toou
in one part of the directory tree, then make surel
is subordinate toou
in all other parts of the directory service. - Try to use only the traditional attributes (shown in Section 4.2.2.2, “Identifying Branch Points”).Using traditional attributes increases the likelihood of retaining compatibility with third-party LDAP client applications. Using the traditional attributes also means that they are known to the default directory schema, which makes it easier to build entries for the branch DN.
Attribute | Definition |
---|---|
dc | An element of the domain name, such as dc=example ; this is frequently specified in pairs, or even longer, depending on the domain, such as dc=example,dc=com or dc=mtv,dc=example,dc=com . |
c | A country name. |
o | An organization name. This attribute is typically used to represent a large divisional branching such as a corporate division, academic discipline (the humanities, the sciences), subsidiary, or other major branching within the enterprise, as in Section 4.2.1.1, “Suffix Naming Conventions”. |
ou | An organizational unit. This attribute is typically used to represent a smaller divisional branching of the enterprise than an organization. Organizational units are generally subordinate to the preceding organization. |
st | A state or province name. |
l or locality | A locality, such as a city, country, office, or facility name. |
Note
uid=bjensen,ou=People,dc=example,dc=com
, then a search for dc=example
does not match that entry unless dc:example
has explicitly been added as an attribute in that entry.
4.2.2.3. Replication Considerations
flightdeck.example.com
, tickets.example.com
, and hangar.example.com
. They initially branch their directory tree into three main groups for their major organizational divisions.
Figure 4.6. Initial Branching of the Directory Tree for Example Corp.
Figure 4.7. Extended Branching for Example Corp.
Figure 4.8. Directory Branching for Example ISP
Figure 4.9. Extended Branching for Example ISP
4.2.2.4. Access Control Considerations
ou=Sales
.
4.2.3. Naming Entries
- 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 see at most one entry in the directory.
l
to represent an organization, or c
to represent an organizational unit.
4.2.3.1. Naming Person Entries
commonName
, or cn
, attribute to name their person entries. That is, an entry for a person named Babs Jensen might have the distinguished name of cn=Babs Jensen,dc=example,dc=com
.
cn=Babs Jensen+employeeNumber=23,dc=example,dc=com
.
cn
. Consider using one of the following attributes:
uid
Use theuid
attribute to specify some unique value of the person. Possibilities include a user login ID or an employee number. A subscriber in a hosting environment should be identified by theuid
attribute.mail
Themail
attribute contains a person's email address, which is always unique. This option can lead to awkward DNs that include duplicate attribute values (such asmail=bjensen@example.com,dc=example,dc=com
), so use this option only if there is not some other unique value to use with theuid
attribute. For example, use themail
attribute instead of theuid
attribute if the enterprise does not assign employee numbers or user IDs for temporary or contract employees.employeeNumber
For employees of theinetOrgPerson
object class, consider using an employer assigned attribute value such asemployeeNumber
.
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. Also, some directory client applications assume that the uid
and cn
attributes use human-readable names.
If a person is a subscriber to a service, the entry should be of object class inetUser
, and the entry should contain the uid
attribute. The attribute must be unique within a customer subtree.
inetOrgPerson
with the nsManagedPerson
object class.
The following are some guidelines for placing person entries in the directory tree:
- People in an enterprise should be located in the directory tree below the organization's entry.
- Subscribers to a hosting organization need to be below the
ou=people
branch for the hosted organization.
4.2.3.2. Naming Group Entries
- A static group explicitly defines is members. The
groupOfNames
orgroupOfUniqueNames
object classes contain values naming the members of the group. Static groups are suitable for groups with few members, such as the group of directory administrators. Static groups are not suitable for groups with thousands of members.Static group entries must contain auniqueMember
attribute value becauseuniqueMember
is a mandatory attribute of thegroupOfUniqueNames
object. This object class requires thecn
attribute, which can be used to form the DN of the group entry. - A dynamic group uses an entry representing the group with a search filter and subtree. Entries matching the filter are members of the group.
- Roles unify the static and dynamic group concept. See Section 4.3, “Grouping Directory Entries” for more information.
groupOfUniqueNames
object class to contain the values naming the members of groups used in directory administration. In a hosted organization, we also recommend that group entries used for directory administration be located under the ou=Groups
branch.
4.2.3.3. Naming Organization Entries
o=example_a+st=Washington,o=ISP,c=US
.
organization
(o
) attribute as the naming attribute.
4.2.3.4. Naming Other Kinds of Entries
cn
attribute in the RDN if possible. Then, for naming a group entry, name it something like cn=administrators,dc=example,dc=com
.
commonName
attribute. Instead, use an attribute that is supported by the entry's object class.
4.2.4. Renaming Entries and Subtrees
Example 4.1. Building Entry DNs
dc=example,dc=com => root suffix ou=People,dc=example,dc=com => org unit st=California,ou=People,dc=example,dc=com => state/province l=Mountain View,st=California,ou=People,dc=example,dc=com => city ou=Engineering,l=Mountain View,st=California,ou=People,dc=example,dc=com => org unit uid=jsmith,ou=Engineering,l=Mountain View,st=California,ou=People,dc=example,dc=com => leaf entry
Figure 4.10. modrdn Operations for a Leaf Entry
Figure 4.11. modrdn Operations for a Subtree Entry
Important
newsuperior
attribute which moves the entry from one parent to another.
Figure 4.12. modrdn Operations to a New Parent Entry
entryrdn.db
index. Each entry is identified by its own key (a self-link) and then a subkey which identifies its parent (the parent link) and any children. This has a format that lays out the directory tree hierarchy by treating parents and children as attribute to an entry, and every entry is described by a unique ID and its RDN, rather than the full DN.
numeric_id:RDN => self link ID: #; RDN: "rdn"; NRDN: normalized_rdn P#:RDN => parent link ID: #; RDN: "rdn"; NRDN: normalized_rdn C#:RDN => child link ID: #; RDN: "rdn"; NRDN: normalized_rdn
ou=people
subtree has a parent of dc=example,dc=com
and a child of uid=jsmith
.
4:ou=people ID: 4; RDN: "ou=People"; NRDN: "ou=people" P4:ou=people ID: 1; RDN: "dc=example,dc=com"; NRDN: "dc=example,dc=com" C4:ou=people ID: 10; RDN: "uid=jsmith"; NRDN: "uid=jsmith"
- You cannot rename the root suffix.
- Subtree rename operations have minimal effect on replication. Replication agreements are applied to an entire database, not a subtree within the database, so a subtree rename operation does not require re-configuring a replication agreement. All of the name changes after a subtree rename operation are replicated as normal.
- Renaming a subtree may require any synchronization agreements to be re-configured. Sync agreements are set at the suffix or subtree level, so renaming a subtree may break synchronization.
- Renaming a subtree requires that any subtree-level ACIs set for the subtree be re-configured manually, as well as any entry-level ACIs set for child entries of the subtree.
- You can rename a subtree with children, but you cannot delete a subtree with children.
- Trying to change the component of a subtree, like moving from
ou
todc
, may fail with a schema violation. For example, theorganizationalUnit
object class requires theou
attribute. If that attribute is removed as part of renaming the subtree, then the operation will fail.
4.3. Grouping Directory Entries
- Using groups
- Using roles
4.3.1. About Groups
groupOfUniqueNames
) and a corresponding member attribute (such as uniqueMember
).
- Static groups have a finite and defined list of members which are added manually to the group entry.
- Dynamic groups use filters to recognize which entries are members of the group, so the group membership is constantly changed as the entries which match the group filter change.
4.3.1.1. Listing Group Membership in User Entries
memberOf
attribute on the user entry, with the name of the group.
memberOf
attribute. The name of every group to which a user belongs is listed as a memberOf
attribute. The values of those memberOf
attributes are managed by the Directory Server.
Note
memberOf
attributes because the plug-in cannot ascertain the relationship between them.
memberOfAllBackends
attributes.
memberofgroupattr
in the plug-in entry, so the MemberOf Plug-in can manage multiple types of groups.
4.3.1.2. Automatically Adding New Entries to Groups
Figure 4.13. Regular Expression Conditions
Note
4.3.2. About Roles
- Explicitly listing role members. Viewing the role will display the complete list of members for that role. The role itself can be queried to check membership (which is not possible with a dynamic group).
- Showing to what roles an entry belongs. Because role membership is determined by an attribute on an entry, simply viewing an entry will show all of the roles to which it belongs. This is similar to the memberOf attributes for groups, only it is not necessary to enable or configure a plug-in instance for this functionality to work. It is automatic.
- Assigning the appropriate roles. Role membership is assigned through the entry, not through the role, so the roles to which a user belongs can be easily assigned and removed by editing the entry, in a single step.
- Managed roles have an explicit enumerated list of members.
- Filtered roles are assigned entries to the role depending upon the attribute contained by each entry, specified in an LDAP filter. Entries that match the filter possess the role.
- Nested roles are roles that contain other roles.
nsAccountLock
attribute set to true
.
nsAccountLock
set to true
. There can be several layers of nested roles, and inactivating a nested role at any point in the nesting will inactivate all roles and users beneath it.
4.3.3. Deciding Between Roles and Groups
nsRole
operational attribute on entries; this multi-valued attribute identifies every role to which the entry belongs. From the client application point of view, the method for checking membership is uniform and is performed on the server side.
Note
memberOf
strikes a nice balance between being simple for the client to use and being efficient for the server to calculate.
memberOf
attribute on a user entry whenever a user is added to a group. A client can run a single search on a group entry to get a list of all of its members, or a single search on a user entry to get a complete list of all the groups it belongs to.
memberOf
(user) attributes are stored in the database, there is no extra processing required for searches, which makes the searches from the clients very efficient.
4.4. Virtual Directory Information Tree Views
Note
4.4.1. About Virtual DIT Views
- A hierarchical directory information tree.
- A flat directory information tree.
Figure 4.14. Examples of a Flat and an Organizationally-Based DIT
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. The target entries only appear to exist in the view; their true location never changes. Virtual DIT views behave like normal DITs in that a subtree or a one-level search can be performed with the expected results being returned.
Figure 4.15. A Combined DIT Using Views
ou=Sales
entry to enable viewing the Sales entries either by location or by product.
Figure 4.16. A DIT with a Virtual DIT View Hierarchy
- The sub-tree
ou=People
contains the realEntry A
andEntry B
entries. - The sub-tree
ou=Location Views
is a view hierarchy. - The leaf nodes
ou=Sunnyvale
andou=Mountain View
each contain an attribute,nsviewfilter
, which describes the view.These are leaf nodes because they do not contain the real entries. However, when a client application searches these views, it findsEntry A
underou=Sunnyvale
andEntry B
underou=Mountain View
. This virtual search space is described by thensviewfilter
attributes of all ancestor views. A search made from a view returns both entries from the virtual search space and those from the actual search space. This enables the view hierarchies to function as a conventional DIT or change a conventional DIT into a view hierarchy.
4.4.2. Advantages of Using Virtual DIT Views
- Views facilitate the use of a flat namespace for entries, because virtual DIT views provide navigational and managerial support similar to those provided by traditional hierarchies.In addition, whenever there is a change to the DIT, the entries never need to be moved; only the virtual DIT view hierarchies change. Because these hierarchies contain no real entries, they are simple and quick to modify.
- Oversights during deployment planning are less catastrophic with virtual DIT views. If the hierarchy is not developed correctly in the first instance, it can be changed easily and quickly without disrupting the service.
- View hierarchies can be completely revised in minutes and the results instantly realized, significantly reducing the cost of directory maintenance.Changes to a virtual DIT hierarchy are instantly realized. When an organizational change occurs, a new virtual DIT view can be created quickly. The new virtual DIT view can exist at the same time as the old view, thereby facilitating a more gradual changeover for the entries themselves and for the applications that use them. Because an organizational change in the directory is not an all-or-nothing operation, it can be performed over a period of time and without service disruption.
- Using multiple virtual DIT views for navigation and management allows for more flexible use of the directory service.With the functionality provided by virtual DIT views, an organization can use both the old and new methods to organize directory data without any requirement to place entries at certain points in the DIT.
- Virtual DIT view hierarchies can be created as a kind of ready-made query to facilitate the retrieval of commonly-required information.
- Views promote flexibility in working practices and reduce the requirement that directory users create complex search filters, using attribute names and values that they would otherwise have no need to know.The flexibility of having more than one way to view and query directory information allows end users and applications to find what they need intuitively through hierarchical navigation.
4.4.3. Example of Virtual DIT Views
dc=example,dc=com
and fits the view description appears in this view, organized by location.
dn: ou=Location Views,dc=example,dc=com objectclass: top objectclass: organizationalUnit objectclass: nsView ou: Location Views description: views categorized by location dn: ou=Sunnyvale,ou=Location Views,dc=example,dc=com objectclass: top objectclass: organizationalUnit objectclass: nsView ou: Sunnyvale nsViewFilter: (l=Sunnyvale) description: views categorized by location dn: ou=Santa Clara,ou=Location Views,dc=example,dc=com objectclass: top objectclass: organizationalUnit objectclass: nsView ou: Santa Clara nsViewFilter: (l=Santa Clara) description: views categorized by location dn: ou=Cupertino,ou=Location Views,dc=example,dc=com objectclass: top objectclass: organizationalUnit objectclass: nsView ou: Cupertino nsViewFilter: (l=Cupertino) description: views categorized by location
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)
. Conversely, a one-level search would return no entries other than the child view entries because all qualifying entries reside in the three descendant views.
ou=Location Views,dc=example,dc=com
view entry itself does not contain a filter. This feature facilitates hierarchical organization without the requirement to further restrict the entries contained in the view. Any view may omit the filter. Although the example filters are very simple, the filter used can be as complex as necessary.
nsfilter
attribute to ou=Location Views,dc=example,dc=com
with the filter value (objectclass=organizationalperson)
.
ou=Location Views
first together with the new filter mentioned above would create a view with all entries with the organization
object class. When the descendant views are added that further restrict entries, the entries that now appear in the descendant views are removed from the ancestor views. This demonstrates how virtual DIT views mimic the behavior of traditional DITs.
Entry B
with both Mountain View
and Sunnyvale
(see Figure 4.16, “A DIT with a Virtual DIT View Hierarchy”), add the Sunnyvale
value to the location attribute, and the entry appears in both views.
4.4.4. Views and Other Directory Features
dc=example,dc=com
does not return any entries from the virtual search space; in fact, no virtual-search-space search is performed. Views processing occurs only if the search base is ou=Location Views
. This way, views ensure that the search does not result in entries from both locations. (If it were a conventional DIT, entries from both locations would be returned.)
4.4.5. Effects of Virtual Views on Performance
4.4.6. Compatibility with Existing Applications
- Applications that use the DN of a target entry to navigate up the DIT.This type of application would find that it is navigating up the hierarchy in which the entry physically exists instead of the view hierarchy in which the entry was found. The reason for this is that views make no attempt to disguise the true location of an entry by changing the DN of the entry to conform to the view's hierarchy. This is by design - many applications would not function if the true location of an entry were disguised, such as those applications that rely on the DN to identify a unique entry. This upward navigation by deconstructing a DN is an unusual technique for a client application, but, nonetheless, those clients that do this may not function as intended.
- Applications that use the
numSubordinates
operational attribute to determine how many entries exist beneath a node.For the nodes in a view, this is currently a count of only those entries that exist in the real search space, ignoring the virtual search space. Consequently, applications may not evaluate the view with a search.
4.5. Directory Tree Design Examples
4.5.1. Directory Tree for an International Enterprise
c
attribute can represent each country branch:
Figure 4.17. Using the c Attribute to Represent Different Countries
l
attribute to represent different countries:
Figure 4.18. Using the l Attribute to Represent Different Countries
4.5.2. Directory Tree for an ISP
Figure 4.19. Directory tree for Example ISP
Chapter 5. Defining Dynamic Attribute Values
5.1. Introduction to Managed Attributes
- Attribute uniqueness requires that every instance of a particular attribute within the subtree or database has a unique value. This is enforced whenever an entry is created or an attribute is modified.
- Classes of service use one entry as a template; whenever that attribute value changes, then all other entries within the scope of the CoS automatically have the same attribute on their entries changed. (The entries affected by the CoS are identified through a definition entry.)
- Managed entries create one entry according to a defined template whenever another entry in a defined scope is created. There are times, particularly with integration with external clients, when it may be necessary to have entry pairs created and managed automatically. Managed entries defines the template of the second entry and provides a mechanism to update it automatically.
- Linked attributes follow DN values in attributes in one entry and automatically add a pre-determined attribute (with a value that points back to the original entry) to the referenced entries. So, if entry A lists entry B as a direct report, then entry B can automatically be updated to have a
manager
attribute with entry A as its specified manager. - Distributed numeric assignments automatically assign unique identifying numbers to entries. This is useful for GID or UID number assignments, which must be unique across an organization.
- How are the entries related? Are there common attributes which are shared among entries? Are there attributes which must represent connections between entries?
- How and where (in what entry) is the original source of the data likely to be maintained? How often is this information updated and how many entries are affected when the data are changed?
- What schema elements are used by these entries and what is the syntax of those attributes?
- How does the plug-in handle distributed directory configuration, such as replication or synchronization?
5.2. About Attribute Uniqueness
LDAP_CONSTRAINT_VIOLATION
error to the client.
- It can check every entry in the specified subtrees.For example, if a company,
example.com
, hosts the directories forexample_a.com
andexample_b.com
, when an entry such asuid=jdoe,ou=people,o=example_a,dc=example,dc=com
is added, uniqueness needs to be enforced only in theo=example_a,dc=example,dc=com
subtree. This is done by listing the DN of the subtree explicitly in the Attribute Uniqueness Plug-in configuration. - Specify an object class pertaining to an entry in the DN of the updated entry and perform the uniqueness check on all the entries beneath it.This option is useful in hosted environments. For example, when adding an entry such as
uid=jdoe,ou=people,o=example_a,dc=example,dc=com
, enforce uniqueness under theo=example_a,dc=example,dc=com
subtree without listing this subtree explicitly in the configuration but, instead, by indicating a marker object class. If the marker object class is set toorganization
, the uniqueness check algorithm locates the entry in the DN that has this object class (o=example_a
) and performs the check on all entries beneath it.Additionally, it is possible to check uniqueness only if the updated entry includes a specified object class. For example, a check may be performed only if the updated entry includesobjectclass=inetorgperson
.
uid
attribute when the Directory Server was first set up. This plug-in instance ensures that values given to the uid
attribute are unique in the root suffix (the suffix corresponding to the userRoot
database).
- The attribute on which the uniqueness check is performed is a naming attribute.
- The Attribute Uniqueness Plug-in is enabled on both supplier servers.
5.3. About Classes of Service
facsimileTelephoneNumber
. Traditionally, to change the fax number required updating each entry individually, a large job for administrators that runs the risk of not updating all entries. With CoS, the attribute value can be generated dynamically. The facsimileTelephoneNumber
attribute is stored in one location, and each entry retrieves its fax number attribute from that location. For the application, these attributes appear just like all other attributes, despite not actually being stored on the entries themselves.
- The entry's DN (different portions of the directory tree might contain different CoS).
- A service class attribute value stored with the entry.The absence of a service class attribute can imply a specific default CoS.
- The attribute value stored in the CoS template entry.Each CoS template entry supplies the attribute value for a particular CoS.
- The object class of the entry.CoS attribute values are generated only when an entry contains an object class allowing the attribute when schema checking is turned on; otherwise, all attribute values are generated.
- The attribute stored in some particular entry in the directory tree.
Important
cosAttribute
parameter).
Note
5.3.1. About a Pointer CoS
dc=example,dc=com
.
Figure 5.1. Sample Pointer CoS
cn=exampleUS,cn=data
, in the CoS definition entry. Each time the postalCode
attribute is queried on the entry cn=wholiday,ou=people,dc=example,dc=com
, the Directory Server returns the value available in the template entry cn=exampleUS,cn=data
.
5.3.2. About an Indirect CoS
Figure 5.2. Sample Indirect CoS
manager
attribute. William's manager is Carla Fuentes, so the manager
attribute contains a pointer to the DN of the template entry, cn=Carla Fuentes,ou=people,dc=example,dc=com
. The template entry in turn provides the departmentNumber
attribute value of 318842
.
5.3.3. About a Classic CoS
Figure 5.3. Sample Classic CoS
cosSpecifier
attribute specifies the employeeType
attribute. This attribute, in combination with the template DN, identify the template entry as cn=sales,cn=exampleUS,cn=data
. The template entry then provides the value of the postalCode
attribute to the target entry.
5.4. About Managed Entries
posixAccount
entry) is created, a corresponding group entry (posixGroup
entry) should also be created. An instance of the Managed Entries Plug-in identifies what entry (the origin entry) triggers the plug-in to automatically generate a new entry (the managed entry). It also identifies a separate template entry which defines the managed entry configuration.
- The search criteria to identify the origin entries (using a search scope and a search filter)
- The subtree under which to create the managed entries (the new entry location)
- The template entry to use for the managed entries
Figure 5.4. Defining Managed Entries
dn: cn=Posix User-Group,cn=Managed Entries,cn=plugins,cn=config objectclass: extensibleObject cn: Posix User-Group originScope: ou=people,dc=example,dc=com originFilter: objectclass=posixAccount managedBase: ou=groups,dc=example,dc=com managedTemplate: cn=Posix User-Group Template,ou=Templates,dc=example,dc=com
5.4.1. Defining the Template for Managed Entries
dn: cn=Posix User-Group Template,ou=Templates,dc=example,dc=com objectclass: mepTemplateEntry cn: Posix User-Group Template mepRDNAttr: cn mepStaticAttr: objectclass: posixGroup mepMappedAttr: cn: $uid Group mepMappedAttr: gidNumber: $gidNumber mepMappedAttr: memberUid: $uid
Figure 5.5. Managed Entries, Templates, and Origin Entries
Note
5.4.2. Entry Attributes Written by the Managed Entries Plug-in
dn: uid=jsmith,ou=people,dc=example,dc=com objectclass: mepOriginEntry objectclass: posixAccount ... sn: Smith mail: jsmith@example.com mepManagedEntry: cn=jsmith Posix Group,ou=groups,dc=example,dc=com
dn: cn=jsmith Posix Group,ou=groups,dc=example,dc=com objectclass: mepManagedEntry objectclass: posixGroup ... mepManagedBy: uid=jsmith,ou=people,dc=example,dc=com
5.4.3. Managed Entries Plug-in and Directory Server Operations
- Add. With every add operation, the server checks to see if the new entry is within the scope of any Managed Entries Plug-in instance. If it meets the criteria for an origin entry, then a managed entry is created and managed entry-related attributes are added to both the origin and managed entry.
- Modify. If an origin entry is modified, it triggers the plug-in to update the managed entry.Changing a template entry, however, does not update the managed entry automatically. Any changes to the template entry are not reflected in the managed entry until after the next time the origin entry is modified.The mapped managed attributes within a managed entry cannot be modified manually, only by the Managed Entry Plug-in. Other attributes in the managed entry (including static attributes added by the Managed Entry Plug-in) can be modified manually.
- Delete. If an origin entry is deleted, then the Managed Entries Plug-in will also delete any managed entry associated with that entry.There are some limits on what entries can be deleted.
- A template entry cannot be deleted if it is currently referenced by a plug-in instance definition.
- A managed entry cannot be deleted except by the Managed Entries Plug-in.
- Rename. If an origin entry is renamed, then plug-in updates the corresponding managed entry. If the entry is moved out of the plug-in scope, then the managed entry is deleted, while if an entry is moved into the plug-in scope, it is treated like an add operation and a new managed entry is created.As with delete operations, there are limits on what entries can be renamed or moved.
- A configuration definition entry cannot be moved out of the Managed Entries Plug-in container entry. If the entry is removed, that plug-in instance is inactivated.
- If an entry is moved into the Managed Entries Plug-in container entry, then it is validated and treated as an active configuration definition.
- A template entry cannot be renamed or moved if it is currently referenced by a plug-in instance definition.
- A managed entry cannot be renamed or moved except by the Managed Entries Plug-in.
- Replication. The Managed Entries Plug-in operations are not initiated by replication updates. If an add or modify operation for an entry in the plug-in scope is replicated to another replica, that operation does not trigger the Managed Entries Plug-in instance on the replica to create or update an entry. The only way for updates for managed entries to be replicated is to replicate the final managed entry over to the replica.
5.5. About Linking Attributes
member
. It is natural for there to be an indication in the user entry of what groups the user belongs to; this is set in the memberOf
attribute. The memberOf
attribute is a managed attribute through the MemberOf Plug-in. The plug-in polls every group entry for changes in their respective member attributes. Whenever a group member is added or dropped from the group, the corresponding user entry is updated with changed memberOf
attributes. In this way, the member
(and other member attributes) and memberOf
attributes are linked.
linkType
) and one attribute which is automatically maintained by the plug-in (managedType
).
Figure 5.6. Basic Linked Attribute Configuration
Note
Figure 5.7. Restricting the Linked Attribute Plug-in to a Specific Subtree
5.5.1. Schema Requirements for Linking Attributes
Figure 5.8. Wrong: Using a Single-Valued Linked Attribute
5.5.2. Using Linked Attributes with Replication
Figure 5.9. Linking Attributes and Replication
5.6. About Dynamically Assigning Unique Number Values
uidNumber
and gidNumber
. The Directory Server can automatically generate and supply unique numbers for specified attributes using the Distributed Numeric Assignment (DNA) Plug-in.
Note
5.6.1. How the Directory Server Manages Unique Numbers
- A single number assigned to a single attribute type from a single range of unique numbers.
- The same unique number assigned to two attributes for a single entry.
- Two different attributes assigned two different numbers from the same range of unique numbers.
employeeID
to a new employee entry, it is important each employee entry is assigned a unique employeeID
.
uidNumber
and a gidNumber
to a posixAccount
entry, the DNA Plug-in can be configured to assign the same number to both attributes.
ou=Example Corp.
branch and another clients' users in the ou=Acme Company
branch. In this case, the assigned numbers have to be unique within the subtree but not necessarily across the entire directory. In this case, it is all right for Barbara Jensen in the ou=Example Corp.
branch to have uidNumber:5
in her entry and for John Smith in the ou=Acme Company
branch to have uidNumber:5
in his entry, because these are separate organizations. Applying ranges to a specific subtree is set in the DNA scope, such as dnaScope: ou=people,dc=example,dc=com
.
acme
, then the unique numbers in the Acme Company branch have acme
in front of the number, like uid: acme5
.
5.6.2. Using DNA to Assign Values to Attributes
posixAccount
object class requires the uidNumber
attribute. If the uidNumber
attribute is managed by the DNA Plug-in and a user entry is added without the uidNumber
attribute within the scope of the filter, then the server checks the new entry, sees that it needs the managed uidNumber
attribute, and adds the attribute with an automatically assigned value.
ldapmodify-a
-D "cn=Directory Manager" -W -p 389 -h server.example.com -x dn: uid=jsmith,ou=people,dc=example,dc=com objectClass: top objectClass: personobjectClass: posixAccount
uid: jsmith cn: John Smith ....
uidNumber
and a gidNumber
to a posixAccount
entry, the DNA Plug-in will assign the same number to both attributes. To do this, then pass both managed attributes to the modify operation, specifying the magic number. For example:
ldapmodify-a
-D "cn=Directory Manager" -W -p 389 -h server.example.com -x dn: uid=jsmith,ou=people,dc=example,dc=com objectClass: top objectClass: person objectClass: posixAccount uid: jsmith cn: John SmithuidNumber: magic
gidNumber: magic
....
Note
5.6.3. Using the DNA Plug-in with Replication
- The managed ranges for the DNA Plug-in
- A shared configuration entry which stores the information about the server's available ranges
dn: dnaHostname=ldap1.example.com+dnaPortNum=389,cn=Account UIDs,ou=Ranges,dc=example,dc=com objectClass: extensibleObject objectClass: top dnahostname: ldap1.example.com dnaPortNum: 389 dnaSecurePortNum: 636 dnaRemainingValues: 1000
Chapter 6. Designing the Directory Topology
6.1. Topology Overview
- Achieve the best possible performance for directory-enabled applications.
- Increase the availability of the directory service.
- Improve the management of the directory service.
ou=people,dc=example,dc=com
suffix, or branch, of the directory tree.
6.2. Distributing the Directory Data
6.2.1. About Using Multiple Databases
Figure 6.1. Storing Suffix Data in Separate Databases
Figure 6.2. Dividing Suffix Databases Between Separate Servers
6.2.2. About Suffixes
Figure 6.3. Directory Tree for Example Corp.
Figure 6.4. Directory Tree Spread across Multiple Databases
Figure 6.5. Suffixes for a Distributed Directory Tree
dc=example,dc=com
suffix is a root suffix. The ou=testing,dc=example,dc=com
suffix, the ou=development,dc=example,dc=com
suffix, and the ou=partners,ou=development,dc=example,dc=com
suffix are all subsuffixes of the dc=example,dc=com
root suffix. The root suffix dc=example,dc=com
contains the data in the ou=marketing
branch of the original directory tree.
The directory service might contain more than one root suffix. For example, an ISP called "Example" might host several websites, one for example_a.com and one for example_b.com. The ISP would create two root suffixes, one corresponding to the o=example_a.com
naming context and one corresponding to the o=example_b.com
naming context.
Figure 6.6. Directory Tree with Multiple Root Suffixes
dc=example,dc=com
entry represents a root suffix. The entry for each hosted customer 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.
6.3. About Knowledge References
- Referrals — The server returns a piece of information to the client application indicating that the client application needs to contact another server to fulfill the request.
- Chaining — The server contacts other servers on behalf of the client application and returns the combined results to the client application when the operation is finished.
6.3.1. Using Referrals
- Default referrals — The directory returns a default referral when a client application presents a DN for which the server does not have a matching suffix. Default referrals are stored in the configuration file of the server. One default referral can be set for the Directory Server and a separate default referral for each database.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.For more information about suffixes, see Section 6.2.2, “About Suffixes”. For information on configuring suffixes, see the Red Hat Directory Server Administration Guide .
- Smart referrals — Smart referrals are stored on entries within the directory service itself. Smart referrals point to Directory Servers that have knowledge of the subtree whose DN matches the DN of the entry containing the smart referral.
6.3.1.1. The Structure of an LDAP Referral
- The host name of the server to contact.
- The port number on the server that is configured to listen for LDAP requests.
- The base DN (for search operations) or target DN (for add, delete, and modify operations).
dc=example,dc=com
for entries with a surname value of Jensen
. A referral returns the following LDAP URL to the client application:
ldap://europe.example.com:389/ou=people, l=europe,dc=example,dc=com
europe.example.com
on port 389 and submit a search using the root suffix ou=people, l=europe,dc=example,dc=com
.
6.3.1.2. About Default Referrals
uid=bjensen,ou=people,dc=example,dc=com
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. The client then contacts the appropriate server and resubmits the original request.
nsslapd-referral
attribute. Default referrals for each database in the directory installation are set by the nsslapd-referral
attribute in the database entry in the configuration. These attribute values are stored in the dse.ldif
file.
6.3.1.3. Smart Referrals
- The same namespace contained on a different server.
- Different namespaces on a local server.
- Different namespaces on the same server.
ou=people,dc=example,dc=com
directory branch point.
ou=people
branch of the European office of Example Corp. by specifying a smart referral on the ou=people
entry itself. The smart referral is ldap://europe.example.com:389/ou=people,dc=example,dc=com
.
Figure 6.7. Using Smart Referrals to Redirect Requests
ldap://europe.example.com:389/ou=US employees,dc=example,dc=com
.
Figure 6.8. Redirecting a Query to a Different Server and Namespace
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.
Figure 6.9. Redirecting a Query from One Namespace to Another Namespace on the Same Server
Note
ou=people,o=example,c=US
, are not performed correctly.
6.3.1.4. Tips for Designing Smart Referrals
- Keep the design simple.Deploying the directory service using a complex web of referrals makes administration difficult. Overusing smart referrals can also lead to circular referral patterns. For example, a referral points to an LDAP URL, which in turn points to another LDAP URL, and so on until a referral somewhere in the chain points back to the original server. This is illustrated below:
Figure 6.10. A Circular Referral Pattern
- Redirect at major branchpoints.Limit referral usage to handle redirection at the suffix level of the directory tree. Smart referrals redirect lookup requests for leaf (non-branch) entries to different servers and DNs. As a result, it is tempting to use smart referrals as an aliasing mechanism, leading to a complex and difficult method 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. Even if the server where the request originated allows access to an entry, when a smart referral sends a client request to another server, the client application may not be allowed access.In addition, the client's credentials need to be available on the server to which the client is referred for client authentication to occur.
6.3.2. Using Chaining
- Invisible access to remote data.Because the database link resolves client requests, data distribution is completely hidden from the client.
- Dynamic management.A part of the directory service can be added or removed from the system while the entire system remains available to client applications. The database link can temporarily return referrals to the application until entries have been redistributed across the directory service.This can also be implemented through the suffix itself, which can return a referral rather than forwarding a client application to the database.
- 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, see the Red Hat Directory Server Administration Guide.
6.3.3. Deciding Between Referrals and Chaining
6.3.3.1. Usage Differences
6.3.3.2. Evaluating Access Controls
The following diagram illustrates a client request to a server using referrals:
Figure 6.11. Sending a Client Request to a Server Using Referrals
- The client application first binds with Server A.
- Server A contains an entry for the client that provides a user name and password, so it returns a bind acceptance message. In order for the referral to work, the client entry must be present on server A.
- The client application sends the operation request to Server A.
- However, Server A does not contain the requested information. Instead, Server A returns a referral to the client application instructing it to contact Server B.
- The client application then sends a bind request to Server B. To bind successfully, Server B must also contain an entry for the client application.
- The bind is successful, and the client application can now resubmit its search operation to Server B.
The problem of replicating client entries across servers is resolved using chaining. On a chained system, the search request is forwarded multiple times until there is a response.
Figure 6.12. Sending a Client Request to a Server Using Chaining
- The client application binds with Server A, and Server A tries to confirm that the user name and password are correct.
- Server A does not contain an entry corresponding to the client application. Instead, it contains a database link to Server B, which contains the actual entry of the client. Server A sends a bind request to Server B.
- Server B sends an acceptance response to Server A.
- Server A then processes the client application's request using the database link. The database link contacts a remote data store located on Server B to process the search operation.
Figure 6.13. Authenticating a Client and Retrieving Data Using Different Servers
- The client application binds with Server A, and Server A tries to confirm that the user name and password are correct.
- Server A does not contain an entry corresponding to the client application. Instead, it contains a database link to Server B, which contains the actual entry of the client. Server A sends a bind request to Server B.
- Server B sends an acceptance response to Server A.
- Server A then processes the client application's request using another database link. The database link contacts a remote data store located on Server C to process the search operation.
Database links do not support the following access controls:
- Controls that must access the content of the user entry are not supported when the user entry is located on a different server. This includes access controls based on groups, filters, and roles.
- Controls based on client IP addresses or DNS domains may be denied. This is because the database link impersonates the client when it contacts remote servers. If the remote database contains IP-based access controls, it evaluates them using the database link's domain rather than the original client domain.
6.4. Using Indexes to Improve Database Performance
cn.db
contains all of the indexes for the common name attribute.
6.4.1. Overview of Directory Index Types
- Presence index — Lists entries that possess a particular attribute, such as
uid
. - Equality index — Lists entries that contain a specific attribute value, such as
cn=Babs Jensen
. - Approximate index — Allows approximate (or "sounds-like") searches. For example, an entry might contain the attribute value of
cn=Babs L. Jensen
. An approximate search would return this value for searches againstcn~=Babs Jensen
,cn~=Babs
, andcn~=Jensen
.Note
Approximate indexes require that names be written in English using ASCII characters. - Substring index — Allows searches against substrings within entries. For example, a search for
cn=*derson
would match common names containing this string (such as Bill Anderson, Norma Henderson, and Steve Sanderson). - International index — Improves the performance of searches for information in international directories. Configure the index to apply a matching rule by associating a locale (internationalization OID) with the attribute being indexed.
- Browsing index or virtual list view (VLV) index — Improves the display performance of entries in the web console. A browsing index can be created on any branch in the directory tree to improve the display performance.
6.4.2. Evaluating the Costs of Indexing
- Indexes increase the time it takes to modify entries.The more indexes being maintained, the longer it takes the directory service to update the database.
- Index files use disk space.The more attributes being indexed, the more files are created. If there are approximate and substring indexes for attributes that contain long strings, these files can grow rapidly.
- Index files use memory.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.
- Index files take time to create.Although index files save time during searches, maintaining unnecessary indexes can waste time. Be certain to maintain only the files needed by the client applications using the directory service.
Chapter 7. Designing the Replication Process
7.1. Introduction to Replication
- Fault tolerance and failover — By replicating directory trees to multiple servers, the directory service is available even if hardware, software, or network problems prevent the directory client applications from accessing a particular Directory Server. Clients are referred to another Directory Server for read and write operations.
Note
Write failover is only possible with multi-supplier replication. - Load balancing — Replicating the directory tree across servers reduces the access load on any given machine, thereby improving server response time.
- Higher performance and reduced response times — Replicating directory entries to a location close to users significantly improves directory response times.
- Local data management — Replication allows information to be owned and managed locally while sharing it with other Directory Servers across the enterprise.
7.1.1. Replication Concepts
- What information to replicate.
- Which servers hold the main copy, or read-write replica, of that information.
- Which servers hold the read-only copy, or read-only replica, of that information.
- What should happen when a read-only replica receives an update request; that is, to which server it should refer the request.
7.1.1.1. Unit of Replication
7.1.1.2. Read-Write and Read-Only Replicas
7.1.1.3. Suppliers and Consumers
- In the case of cascading replication, the hub supplier holds a read-only replica that it supplies to consumers. For more information, see Section 7.2.3, “Cascading Replication”.
- In the case of multi-supplier replication, the suppliers function as both suppliers and consumers for the same read-write replica. For more information, see Section 7.2.2, “Multi-Supplier Replication”.
Note
For any particular replica, the supplier server must:
- Respond to read requests and update requests from directory clients.
- Maintain state information and a changelog for the replica.
- Initiate replication to consumer servers.
A consumer server must:
- Respond to read requests.
- Refer update requests to a supplier server for the replica.
In the special case of cascading replication, the hub supplier must:
- Respond to read requests.
- Refer update requests to a supplier server for the replica.
- Initiate replication to consumer servers.
7.1.1.4. Replication and Changelogs
nsslapd-changelogmaxage
or nsslapd-changelogmaxentries
. These attributes trim the old changelogs to keep the changelog size reasonable.
7.1.1.5. Replication Agreement
- The database to replicate.
- The consumer server to which the data is pushed.
- The times that replication can occur.
- The DN that the supplier server must use to bind (called the supplier bind DN).
- How the connection is secured (TLS, Start TLS, client authentication, SASL, or simple authentication).
- Any attributes that will not be replicated (see Section 7.3.2, “Replicate Selected Attributes with Fractional Replication”).
7.1.2. Data Consistency
- There is a reliable, high-speed connection between servers.
- The client requests serviced by the directory service are mainly search, read, and compare operations, with relatively few update operations.
- There are unreliable or intermittently available network connections.
- The client requests serviced by the directory service are mainly update operations.
- Communication costs have to be lowered.
- There is a latency in the propagation of update operations between suppliers.
- The supplier that serviced the update operation does not wait for the second supplier to validate it before returning an "operation successful" message to the client.
7.2. Common Replication Scenarios
7.2.1. Single-Supplier Replication
Figure 7.1. Single-Supplier Replication
7.2.2. Multi-Supplier Replication
Note
Figure 7.2. Simplified Multi-Supplier Replication Configuration
Figure 7.3. Replication Traffic in a Simple Multi-Supplier Environment
Figure 7.4. Multi-Supplier Replication Configuration A
Figure 7.5. Multi-Supplier Replication Configuration B
- How many suppliers there will be
- What their geographic locations are
- The path the suppliers will use to update servers in other locations
- The topologies, directory trees, and schemas of the different suppliers
- The network quality
- The server load and performance
- The update interval required for directory data
7.2.3. Cascading Replication
Figure 7.6. Cascading Replication Scenario
Figure 7.7. Replication Traffic and Changelogs in Cascading Replication
7.2.4. Mixed Environments
Figure 7.8. Combined Multi-Supplier and Cascading Replication
7.3. Defining a Replication Strategy
- Assess the resources within the network, the traffic loads, and resource requirements for the directory service.
- If there are multiple consumers for different locations or sections of the company or if some servers are insecure, then use fractional replication to exclude sensitive or seldom-modified information to maintain data integrity without compromising sensitive information.See Section 7.3.2, “Replicate Selected Attributes with Fractional Replication” for more information.
- If the network is stretched across a wide geographical area, there are multiple Directory Servers at multiple sites, with local data suppliers connected by multi-supplier replication.See Section 7.3.5, “Replication Across a Wide-Area Network” for more information.
- If high availability is the primary concern, create a data center with multiple Directory Servers on a single site. Single-supplier replication provides read-failover, while multi-supplier replication provides write-failover.See Section 7.3.6, “Using Replication for High Availability” for more information.
- If local availability is the primary concern, use replication to distribute data geographically to Directory Servers in local offices around the world. A main copy of all information can be maintained in a single location, such as the company headquarters, or each local site can manage the parts of the DIT that are relevant for them.See Section 7.3.7, “Using Replication for Local Availability” for more information.
- In all cases, balance the load of requests serviced by the Directory Servers and avoid network congestion.See Section 7.3.8, “Using Replication for Load Balancing” for more information.
7.3.1. Conducting a Replication Survey
- The quality of the LANs and WANs connecting different buildings or remote sites and the amount of available bandwidth.
- The physical location of users, how many users are at each site, and their usage patterns; that is how they intend to use the directory service.
- The number of applications that access the directory service and the relative percentage of read, search, and compare operations to write operations.
- If the messaging server uses the directory, find out how many operations it performs for each email message it handles. Other products that rely on the directory service are typically products such as authentication applications or meta-directory applications. For each one, determine the type and frequency of operations that are performed in the directory service.
- The number and size of the entries stored in the directory service.
7.3.2. Replicate Selected Attributes with Fractional Replication
- Where the consumer server is connected using a slow network, excluding infrequently changed attributes or larger attributes such as
jpegPhoto
results in less network traffic. - Where the consumer server is placed on an untrusted network such as the public Internet, excluding sensitive attributes such as telephone numbers provides an extra level of protection that guarantees no access to those attributes even if the server's access control measures are defeated or the machine is compromised by an attacker.
7.3.3. Replication Resource Requirements
- Disk usage — On supplier servers, the changelog is written after each update operation. Supplier servers that receive many update operations may experience higher disk usage.
Note
Each supplier server uses a single changelog. If a supplier contains multiple replicated databases, the changelog is used more frequently, and the disk usage is even higher. - Server threads — Each replication agreement consumes one server thread. So, the number of threads available to client applications is reduced, possibly affecting the server performance for the client applications.
- File descriptors — The number of file descriptors available to the server is reduced by the changelog (one file descriptor) and each replication agreement (one file descriptor per agreement).
7.3.4. Managing Disk Space Required for Multi-Supplier Replication
cn=changelog5
and relate directly to trimming the changelog:
nsslapd-changelogmaxage
sets the maximum age that the entries in the changelog can be; once an entry is older than that limit, it is deleted. This keeps the changelog from growing indefinitely.nsslapd-changelogmaxentries
sets the maximum number of entries that are allowed in the changelog. Likensslapd-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-supplier replication may not function properly.
cn=replica, cn=
suffixDN,
cn=mapping tree, cn=config
. These two attributes relate to maintenance information kept in the changelog, the tombstone and state information, rather than the directory edits information.
nsDS5ReplicaPurgeDelay
sets the maximum age that tombstone (deleted) entries and state information can be in the changelog. Once a tombstone or state information entry is older than that age, it is deleted. This differs from thensslapd-changelogmaxage
attribute in that thensDS5ReplicaPurgeDelay
value applies only to tombstone and state information entries;nsslapd-changelogmaxage
applies to every entry in the changelog, including directory modifications.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-supplier replication may not be able to update replicas properly.
7.3.5. Replication Across a Wide-Area Network
Note
- Where replication is performed across a public network such as the Internet, the use of TLS is highly recommended. This guards against eavesdropping of the replication traffic.
- Use a T-1 or faster Internet connection for the network.
- 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.
- When initializing consumers, do not initialize the consumer immediately; instead, utilize file system replica initialization, which is much faster than online initialization or initializing from file. See the Red Hat Directory Server Administration Guide for information on using file system replica initialization.
7.3.6. Using Replication for High Availability
Note
7.3.7. Using Replication for Local Availability
- To keep a local main copy of the data.This is an important strategy for large, multinational enterprises that need to maintain directory information of interest only to the employees in a specific country. Having a local main copy of the data is also important to any enterprise where interoffice politics dictate that data be controlled at a divisional or organizational level.
- To mitigate unreliable or intermittently available network connections.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.
7.3.8. Using Replication for Load Balancing
- By spreading the users' search activities across several servers.
- By dedicating servers to read-only activities (writes occur only on the supplier server).
- By dedicating special servers to specific tasks, such as supporting mail server activities.
Load Type | Objects[a] | Accesses/Day[b] | Avg. Entry Size | Load |
---|---|---|---|---|
Replication | 1 million | 100,000 | 1KB | 100Mb/day |
Remote Lookup | 100 | 1,000 | 1KB | 1Mb/day |
[a]
For replication, objects refers to the number of entries in the database. For remote lookup, it refers to the number of users who access the database.
[b]
For replication, Accesses/Day is based on a 10% change rate to the database that needs to be replicated. For remote lookup, it is based on ten lookups per day for each remote user.
|
7.3.8.1. Example of Network Load Balancing
Figure 7.9. Managing Enterprise Subtrees in Remote Offices
- Select one server in each office to be the supplier server for the locally managed data.
- Replicate locally managed data from that server to the corresponding supplier server in the remote office.
- Replicate the directory tree on each supplier server (including data supplied from the remote office) to at least one local Directory Server to ensure availability of the directory data. Use multi-supplier replication for the suffix that is managed locally, and cascading replication for the suffix that receives a main copy of the data from a remote server.
7.3.8.2. Example of Load Balancing for Improved Performance
- Uses a Directory Server that includes 1.5 million entries in support of one million users
- Each user performs ten directory lookups per day
- Uses a messaging server that handles 25 million mail messages per day
- The messaging server performs five directory lookups for every mail message that it handles
Access Type | Type Count | Accesses per Day | Total Accesses |
---|---|---|---|
User Lookup | 1 million | 10 | 10 million |
Email Lookup | 25 million | 5 | 125 million |
Combined accesses | 135 million | ||
Total | 135 million (3,125/second) |
- Place two Directory Servers in a multi-supplier configuration in one city to handle all write traffic.This configuration assumes that there should be a single point of control for all directory data.
- Use these supplier servers to replicate to one or more hub suppliers.The read, search, and compare requests serviced by the directory service should be targeted at the consumer servers, thereby freeing the supplier servers to handle write requests.
- Use the hub supplier to replicate to local sites throughout the enterprise.Replicating to local sites helps balance the workload of the servers and the WANs, as well as ensuring high availability of directory data.
- At each site, replicate at least once to ensure high availability, at least for read operations.
- Use DNS sort to ensure that local users always find a local Directory Server they can use for directory lookups.
7.3.8.3. Example Replication Strategy for a Small Site
- The entire enterprise is contained within a single building.
- The building has a very fast (100 Mb per second) and lightly used network.
- The network is very stable, and the server hardware and OS platforms are reliable.
- A single server is capable of easily handling the site's load.
7.3.8.4. Example Replication Strategy for a Large Site
- The enterprise is contained within two separate buildings.
- There are slow connections between the buildings, and these connections are very busy during normal business hours.
- Choose a single server in one of the two buildings to contain a main copy of the directory data.This server should be placed in the building that contains the largest number of people responsible for the main copy of the directory data. We shall see this building as Building A.
- Replicate at least once within Building A for high availability of directory data.Use a multi-supplier replication configuration to ensure write-failover.
- Create two replicas in the second building (Building B).
- If there is no need for close consistency between the supplier and consumer server, schedule replication so that it occurs only during off-peak hours.
7.4. Using Replication with Other Directory Server Features
7.4.1. Replication and Access Control
7.4.2. Replication and Directory Server Plug-ins
- Attribute Uniqueness Plug-inThe Attribute Uniqueness Plug-in validate attribute values added to local entries to make sure that all values are unique. However, this checking is done directly on the server, not replicated from other suppliers. For example, Example Corp. requires that the
mail
attribute be unique, but two users are added with the samemail
attribute to two different supplier servers at the same time. As long as there it no a naming conflict, then there is no replication conflict, but themail
attribute is not unique. - Referential Integrity Plug-inReferential integrity works with multi-supplier replication, provided that this plug-in is enabled on only one supplier in the multi-supplier set. This ensures that referential integrity updates occur on only one of the supplier servers and propagated to the others.
Note
7.4.3. Replication and Database Links
Figure 7.10. Replicating Chained Databases
7.4.4. Schema Replication
- If the schema entries on both supplier and consumers are the same, the replication operation proceeds.
- If the version of the schema on the supplier server is more recent than the version stored on the consumer, the supplier server replicates its schema to the consumer before proceeding with the data replication.
- If the version of the schema on the supplier server is older than the version stored on the consumer, the server may return many errors during replication because the schema on the consumer cannot support the new data.
Note
ldapmodify
, and changes made directly to the 99user.ldif
file. Custom schema files, and any changes made to custom schema files, are not replicated.
Warning
If the standard 99user.ldif
file is used for custom schema, these changes are replicated to all consumers.
ldapmodify
.
7.4.5. Replication and Synchronization
Chapter 8. Designing Synchronization
8.1. Windows Synchronization Overview
- User and Group Sync. As with multi-supplier replication, user and group entries are synchronized through a plug-in, which is enabled by default. The same changelog that is used for multi-supplier replication is also used to send updates from the Directory Server to the Windows synchronization peer server as an LDAP operation. The server also performs LDAP search operations against its Windows server to synchronize changes made to Windows entries to the corresponding Directory Server entry.
- Password Sync. This application captures password changes for Windows users and relays those changes back to the Directory Server over LDAPS. It must be installed on the Active Directory machine.
Figure 8.1. The Sync Process
8.1.1. Synchronization Agreements
Note
8.1.2. Changelogs
8.2. Supported Active Directory Versions
8.3. Planning Windows Synchronization
8.3.1. Resource Requirements
- 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. If a supplier contains multiple replicated and synchronized databases, the changelog is used more frequently, and the disk usage is even higher.
- Server threads — The synchronization agreement uses one server thread.
- File descriptors — The number of file descriptors available to the server is reduced by the changelog (one file descriptor) and each replication and synchronization agreement (one file descriptor per agreement).
- Quality of the LANs and WANs connecting different buildings or remote sites and the amount of available bandwidth.
- The number and size of the entries stored in the directory.
8.3.2. Managing Disk Space for the Changelog
cn=changelog5
and relate directly to trimming the changelog:
nsslapd-changelogmaxage
sets the maximum age that the entries in the changelog can be; once an entry is older than that limit, it is deleted. This keeps the changelog from growing indefinitely.nsslapd-changelogmaxentries
sets the maximum number of entries that are allowed in the changelog. Likensslapd-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 synchronization may not function properly.
cn=
sync_agreement, cn=WindowsReplica,cn=
suffixDN,cn=mapping tree,cn=config
. These two attributes relate to maintenance information kept in the changelog, the tombstone and state information, rather than the directory edits information.
nsDS5ReplicaPurgeDelay
sets the maximum age that tombstone (deleted) entries and state information can be in the changelog. Once a tombstone or state information entry is older than that age, it is deleted. This differs from thensslapd-changelogmaxage
attribute in that thensDS5ReplicaPurgeDelay
value applies only to tombstone and state information entries;nsslapd-changelogmaxage
applies to every entry in the changelog, including directory modifications.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-supplier replication may not be able to update replicas properly.
8.3.3. Defining the Connection Type
8.3.4. Considering a Data Supplier
8.3.5. Determining the Subtree to Synchronize
samAccount
in the Active Directory and the uid
attribute in Directory Server. The synchronization plug-in notes if an entry (based on the samAccount/uid
relationship) is removed from the synced subtree either because it is deleted or moved. That is the signal to the synchronization plug-in that the entry is no longer to be synced. The issue is that the sync process needs some configuration to determine how to handle that moved entry. There are three options which can be set in the synchronization agreement: delete the corresponding Directory Server entry, ignore the change (the default), or unsync the entries but leave them otherwise intact.
8.3.6. Interaction with a Replicated Environment
ou=People,dc=example,dc=com
) to a corresponding Windows domain and subtree (cn=Users,dc=test,dc=com
). Each subtree can be synchronized only to one other subtree to avoid naming conflicts and change conflicts.
Figure 8.2. Multi-Supplier Directory Server — Windows Domain Synchronization
8.3.7. Controlling the Sync Direction
oneWaySync
parameter to the sync agreement. This attribute defines which direction to send changes.
fromWindows
. In this case, during the regular synchronization update interval, the Directory Server contacts the Active Directory server and sends the DirSync control to request updates. However, the Directory Server does not send any changes or entries from its side. So, the sync update consists of the Active Directory changes being sent to and updating the Directory Server entries.
toWindows
. The Directory Server sends entry modifications to the Active Directory server in a normal update, but it does not include the DirSync control so that it does not request any updates from the Active Directory side.
8.3.8. Controlling Which Entries Are Synced
- Within the Windows subtree, only user and group entries can be synchronized to Directory Server. When creating the synchronization agreement, there is an option to synchronize new Windows user and group entries as they are created. If these attributes are set to
on
, then existing Windows entries are synchronized to the Directory Server, and entries as they are created in the Windows server are synchronized to the Directory Server. - As with Active Directory entries, only user and group entries in Directory Server can be synchronized. Entries which will be synchronized must have the
ntUser
orntGroup
object classes and required attributes; all other entries are ignored.
8.3.9. Identifying the Directory Data to Synchronize
- Contact information for directory users and employees, such as telephone numbers, home and office addresses, and email addresses.
- Contact information for trading partners, clients, and customers.
- User's software preferences or software configuration information.
- Group information and group membership.Group members are synchronized only if they are within the synchronized suffix. Group members that are not within the scope of the agreement are left unchanged on both sides; that is, they are listed as members of the group on the appropriate directory service, but their
member
attribute in the group entry is not synchronized with the synchronization peer.
ntGroup
or ntUser
object classes and required attributes are synchronized; determine what existing and future entries should be synchronized with the Windows server.
8.3.10. Synchronizing POSIX Attributes for Users and Groups
ntUser
and ntGroup
attributes automatically added which identify them as Windows accounts, but no POSIX attributes are synced over (even if they exist on the Active Directory entry) and no POSIX attributes are added on the Directory Server side.
Note
uidNumber
, gidNumber
, and homeDirectory
) are synchronized between Active Directory and Directory Server entries if the plug-in is enabled. However, if a new POSIX entry or POSIX attributes are added to an existing entry in the Directory Server, only the POSIX attributes are synchronized over to the Active Directory corresponding entry. The POSIX object class (posixAccount
for users and posixGroup
for groups) is not added to the Active Directory entry.
8.3.11. Synchronizing Passwords and Installing Password Services
userPassword
attribute) is not enabled. What this means is that even if Directory Server user entries are synchronized over to the Windows server, the user entries are not active on the Windows domain (meaning, among other things, those synced users cannot log into the domain, since they do not have a password).
Note
passwordTrackUpdateTime
which records a separate timestamp for the last update of the user password. This can make it simpler to synchronize password changes between Active Directory and Directory Server or with other clients.
8.3.12. Defining an Update Strategy
winSyncInterval
) or by setting a different update schedule (nsDS5ReplicaUpdateSchedule
).
8.3.13. Editing the Sync Agreement
8.4. Schema Elements Synchronized Between Active Directory and Directory Server
ntUniqueId
contains the value of theobjectGUID
attribute for the corresponding Windows entry. This attribute is set by the synchronization process and should not be set or modified manually.ntUserDeleteAccount
is set automatically when a Windows entry is synchronized but must be set manually for Directory Server entries. IfntUserDeleteAccount
has the valuetrue
, the corresponding Windows entry is deleted when the Directory Server entry is deleted.ntDomainUser
corresponds to thesamAccountName
attribute for Active Directory entries. User entries only.ntGroupType
is set automatically for Windows groups that are synchronized, but must be set manually on Directory Server entries before they are synchronized. Group entries only.
givenName
attribute in Directory Server matches the givenName
attribute in Active Directory. Because the defined schema in Active Directory and Red Hat Directory Server are slightly different, other attributes are mapped between Active Directory and Red Hat Directory Server; most of these are Windows-specific attributes in Directory Server.
8.4.1. User Attributes Synchronized Between Directory Server and Active Directory
Directory Server | Active Directory |
---|---|
cn | 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 |
cn | physicalDeliveryOfficeName |
description | postOfficeBox |
destinationIndicator | postalAddress |
facsimileTelephoneNumber | postalCode |
givenName | registeredAddress |
homePhone | sn |
homePostalAddress | st |
initials | street |
l | telephoneNumber |
teletexTerminalIdentifier | |
manager | telexNumber |
mobile | title |
o | userCertificate |
ou | x121Address |
pager |
8.4.2. User Schema Differences between Red Hat Directory Server and Active Directory
8.4.2.1. Values for cn Attributes
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.
cn
value is added to an Active Directory entry and that value is not one of the values for cn
in Directory Server, then all of the Directory Server cn
values are overwritten with the single Active Directory value.
cn
attribute as its naming attribute, where Directory Server uses uid
. This means that there is the potential to rename the entry entirely if the cn
attribute is edited in the Directory Server. If that cn
change is written over to the Active Directory entry, then the entry is renamed, and the new named entry is written back over to Directory Server. This only happens, however, if the cn
attribute is synced. If the change is not synchronized, then the entry is not renamed.
8.4.2.2. Password Policies
8.4.2.3. Values for street and streetAddress
streetAddress
for a user or group's postal address; this is the way that Directory Server uses the street
attribute. There are two important differences in the way that Active Directory and Directory Server use the streetAddress
and street
attributes, respectively:
- In Directory Server,
streetAddress
is an alias forstreet
. Active Directory also has thestreet
attribute, but it is a separate attribute that can hold an independent value, not an alias forstreetAddress
. - Active Directory defines both
streetAddress
andstreet
as single-valued attributes, while Directory Server definesstreet
as a multi-valued attribute, as specified in RFC 4519.
streetAddress
and street
attributes, there are two rules to follow when setting address attributes in Active Directory and Directory Server:
- Windows Sync maps
streetAddress
in the Windows entry tostreet
in Directory Server. To avoid conflicts, thestreet
attribute should not be used in Active Directory. - Only one Directory Server
street
attribute value is synced to Active Directory. If thestreetAddress
attribute is changed in Active Directory and the new value does not already exist in Directory Server, then allstreet
attribute values in Directory Server are replaced with the new, single Active Directory value.
8.4.2.4. Constraints on the initials Attribute
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.
8.4.3. Group Attributes Synchronized Between Directory Server and Active Directory
Directory Server | Active Directory | |||
---|---|---|---|---|
cn | name | |||
ntGroupAttributes | groupAttributes | |||
ntGroupId |
| |||
ntGroupType | groupType |
cn | member |
description | ou |
l | seeAlso |
8.4.4. Group Schema Differences between Red Hat Directory Server and Active Directory
Chapter 9. Designing a Secure Directory
9.1. About Security Threats
- Unauthorized access
- Unauthorized tampering
- Denial of service
9.1.1. Unauthorized Access
9.1.2. Unauthorized Tampering
9.1.3. Denial of Service
9.2. Analyzing Security Needs
- How to provide users and applications with access to the information they need to perform their jobs.
- How to protect sensitive data regarding employees or the business from general access.
- How to offer customers a guarantee of privacy.
- How to guarantee information integrity.
9.2.1. Determining Access Rights
- Grant all categories of users as many rights as possible while still protecting sensitive data.An open method requires accurately determining what data are sensitive or critical to the business.
- Grant each category of users the minimum access they require to do their jobs.A restrictive method requires minutely understanding the information needs of each category of user inside, and possibly outside, of the organization.
9.2.2. Ensuring Data Privacy and Integrity
- By encrypting data transfers.
- By using certificates to sign data transfers.
9.2.3. Conducting Regular Audits
9.2.4. Example Security Needs Analysis
- example.com internal information
- Information belonging to corporate customers
- Information pertaining to individual subscribers
- 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.
- Implement a standard access control policy for all individual clients who use example.com for Internet access from their homes.
- Deny access to example.com's corporate directory to all outsiders.
- Grant read access to example.com's directory of subscribers to the world.
9.3. Overview of Security Methods
Security Method | Description |
---|---|
Authentication | A means for one party to verify another's identity. For example, a client gives a password to Directory Server during an LDAP bind operation. |
Password policies | Defines the criteria that a password must satisfy to be considered valid; for example, age, length, and syntax. |
Encryption | Protects the privacy of information. When data is encrypted, it is scrambled in a way that only the recipient can understand. |
Access control | Tailors the access rights granted to different directory users and provides a means of specifying required credentials or bind attributes. |
Account deactivation | Disables a user account, group of accounts, or an entire domain so that all authentication attempts are automatically rejected. |
Secure connections | Maintains the integrity of information by encrypting connections with TLS, Start TLS, or SASL. If information is encrypted during transmission, the recipient can determine that it was not modified during transit. Secure connections can be required by setting a minimum security strength factor. |
Auditing | Determines if the security of the directory has been compromised; one simple auditing method is reviewing the log files maintained by the directory. |
SELinux | Uses security policies on the Red Hat Enterprise Linux machine to restrict and control access to Directory Server files and processes. |
9.4. Selecting Appropriate Authentication Methods
9.4.1. Anonymous and Unauthenticated Access
ldapsearch -x -D "cn=jsmith,ou=people,dc=example,dc=com" -b "dc=example,dc=com" "(cn=joe)"
9.4.2. Simple Binds and Secure Binds
userPassword
attribute. This ensures that the directory recognizes the bind DN and password.
- The user enters a unique identifier, such as a user ID (for example,
fchen
). - The LDAP client application searches the directory for that identifier and returns the associated distinguished name (such as
uid=fchen,ou=people,dc=example,dc=com
). - The LDAP client application binds to the directory using the retrieved distinguished name and the password supplied by the user.
Note
nsslapd-require-secure-binds
configuration attribute requires simple password authentication to occur over a secure connection, using TLS or Start TLS. This effectively encrypts the plaintext password so it cannot be sniffed by a hacker.
nsslapd-require-secure-binds
configuration attribute requires simple password authentication over a secure connection, meaning TLS or Start TLS. This setting allows alternative secure connections, like SASL authentication or certificate-based authentication, as well.
9.4.3. Certificate-Based Authentication
9.4.4. Proxy Authentication
ldapmodify -D "cn=Directory Manager" -W -x -D "cn=directory manager" -W -p 389 -h server.example.com -x -Y "cn=joe,dc=example,dc=com" -f mods.ldif
ldapmodify
command gives the manager entry (cn=Directory Manager
) the permissions of a user named Joe (cn=joe
) to apply the modifications in the mods.ldif
file. The manager does not need to provide Joe's password to make this change.
Note
dc=example,dc=com
tree, that entity can do anything. Therefore, ensure that the proxy ACI is set at the lowest possible level of the DIT.
9.4.5. Pass-through Authentication
Figure 9.1. Simple Pass-through Authentication Process
Figure 9.2. PAM Pass-through Authentication Process
Note
pam_ldap
module must be properly configured. For general configuration information about pam_ldap
, look at the manpage (such as http://linux.die.net/man/5/pam_ldap).
/etc/pam.d/system-auth
by default.
9.4.6. Password-less Authentication
ldapsearch
es. This control returns information about the account status and any password policies in effect (like requiring a reset, a password expiration warning, or the number of grace logins left after password expiration) — all the information that would be returned in a bind attempt but without authenticating and binding to the Directory Server as that user. That allows the client to determine if the user should be allowed to authenticate based on the Directory Server settings and information, but the actual authentication process is performed outside of Directory Server.
Note
oid=1.3.6.1.4.1.42.2.27.9.5.8,cn=features,cn=config
.
9.5. Designing an Account Lockout Policy
nsAccountLock
. When an entry contains the nsAccountLock
attribute with a value of true
, the server rejects a bind attempt by that account.
- An account lockout policy can be associated with the password policy (Section 9.6, “Designing a Password Policy”). When a user fails to log in with the proper credentials after a specified number of times, the account is locked until an administrator manually unlocks it.This protects against crackers who try to break into the directory by repeatedly trying to guess a user's password.
- An account can be locked after a certain amount of time has lapsed. This can be used to control access for temporary users — such as interns, students, or seasonal workers — who have time-limited access based on the time the account was created. Alternatively, an account policy can be created that inactivates user accounts if the account has been inactive for a certain amount of time since the last login time.A time-based account lockout policy is defined through the Account Policy Plug-in, which sets global settings for the directory. Multiple account policy subentries can be created for different expiration times and types and then applied to entries through classes of service.
Note
9.6. Designing a Password Policy
9.6.1. How Password Policy Works
- The entire directory.Such a policy is known as the global password policy. When configured and enabled, the policy is applied to all users within the directory except for the Directory Manager entry and those user entries that have local password policies enabled.This can define a common, single password policy for all directory users.
- A particular subtree of the directory.Such a policy is known as the subtree level or local password policy. When configured and enabled, the policy is applied to all users under the specified subtree.This is good in a hosting environment to support different password policies for each hosted company rather than enforcing a single policy for all the hosted companies.
- 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.
nsslapd-pwpolicy-local
attribute of the cn=config
entry. This attribute acts as a switch, turning fine-grained password policy on and off.
dsconf pwpolicy
command to change global policies and the dsconf localpwp
command to change local policies. For more information about setting password policies, see the Administration Guide.
Note
ns-newpwpolicy.pl
script that previously managed local password policies has been deprecated. However, this script is still available in the 389-ds-base-legacy-tools
package.
- To determine whether the fine-grained password policy is enabled, the server checks the value (
on
oroff
) assigned to thensslapd-pwpolicy-local
attribute of thecn=config
entry. If the value isoff
, the server ignores the policies defined at the subtree and user levels and enforces the global password policy. - To determine whether a local policy is defined for a subtree or user, the server checks for the
pwdPolicysubentry
attribute in the corresponding user entry. If the attribute is present, the server enforces the local password policy configured for the user. If the attribute is absent, the server logs an error message and enforces the global password policy.
Figure 9.3. Password Policy Checking Process
userPassword
attribute (explained in the following section) is present in the request.
userPassword
checks two password policy settings:
- The password minimum age policy is activated. If the minimum age requirement has not been satisfied, the server returns a constraintViolation error. The password update operation fails.
- The password history policy is activated. If the new value of
userPassword
is in the password history, or if it is the same as the current password, the server returns a constraintViolation error. The password update operation fails.
userPassword
checks password policies set for the password syntax:
- 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. The password update operation fails.
9.6.2. Password Policy Attributes
9.6.2.1. Maximum Number of Failures
passwordMaxFailure
parameter.
passwordLegacyPolicy
parameter.
9.6.2.2. Password Change After Reset
9.6.2.3. User-Defined Passwords
- It requires a substantial amount of an administrator's time.
- Because administrator-specified passwords are typically more difficult to remember, users are more likely to write their password down, increasing the risk of discovery.
9.6.2.4. Password Expiration
9.6.2.5. Expiration Warning
Note
9.6.2.6. Grace Login Limit
9.6.2.7. Password Syntax Checking
passwordCheckSyntax
attribute.
uid
, cn
, sn
, givenName
, ou
, or mail
attributes of the user's entry.
- Minimum required number of characters in the password (
passwordMinLength
) - Minimum number of digit characters, meaning numbers between zero and nine (
passwordMinDigits
) - Minimum number of ASCII alphabetic characters, both upper- and lower-case (
passwordMinAlphas
) - Minimum number of uppercase ASCII alphabetic characters (
passwordMinUppers
) - Minimum number of lowercase ASCII alphabetic characters (
passwordMinLowers
) - Minimum number of special ASCII characters, such as
!@#$
(passwordMinSpecials
) - Minimum number of 8-bit characters (
passwordMin8bit
) - Maximum number of times that the same character can be immediately repeated, such as
aaabbb
(passwordMaxRepeats
) - Minimum number of character categories required per password; a category can be upper- or lower-case letters, special characters, digits, or 8-bit characters (
passwordMinCategories
) - Directory Server checks the password against the
CrackLib
dictionary (passwordDictCheck
) - Directory Server checks if the password contains a palindrome (
passwordPalindrome
) - Directory Server prevents setting a password that has more consecutive characters from the same category (
passwordMaxClassChars
) - Directory Server prevents setting a password that contains certain strings (
passwordBadWords
) - Directory Server prevents setting a password that contains strings set in administrator-defined attributes (
passwordUserAttributes
)
9.6.2.8. Password Length
9.6.2.9. Password Minimum Age
passwordHistory
attribute, users are discouraged from reusing old passwords.
passwordMinAge
) attribute is two days, users cannot repeatedly change their passwords during a single session. This prevents them from cycling through the password history so that they can reuse an old password.
9.6.2.10. Password History
9.6.2.11. Password Storage Schemes
- CLEAR, meaning no encryption. This is the only option which can be used with SASL Digest-MD5, so using SASL requires the CLEAR password storage scheme.Although passwords stored in the directory can be protected through the use of access control information (ACI) instructions, it is still not a good idea to store plain text passwords in the directory.
- Secure Hash Algorithm (SHA, SHA-256, SHA-384, and SHA-512). This is less secure than SSHA.
- UNIX CRYPT algorithm. This algorithm provides compatibility with UNIX passwords.
- MD5. This storage scheme is less secure than SSHA, but it is included for legacy applications which require MD5.
- Salted MD5. This storage scheme is more secure than plain MD5 hash, but still less secure than SSHA. This storage scheme is not included for use with new passwords but to help with migrating user accounts from directories which support salted MD5.
9.6.2.12. Password Last Change Time
passwordTrackUpdateTime
attribute tells the server to record a timestamp for the last time that the password was updated for an entry. The password change time itself is stored as an operational attribute on the user entry, pwdUpdateTime
(which is separate from the modifyTimestamp
or lastModified
operational attributes).
9.6.3. Designing a Password Policy in a Replicated Environment
- Password policies are enforced on the data supplier.
- Account lockout is enforced on all servers in the replication setup.
- All replicas issue warnings of an impending password expiration. This information is kept locally on each server, so if a user binds to several replicas in turn, the user receives the same warning several times. In addition, if the user changes the password, it may take time for this information to filter through to the replicas. If a user changes a password and then immediately rebinds, the bind may fail until the replica registers the changes.
- The same bind behavior should occur on all servers, including suppliers and replicas. Always create the same password policy configuration information on each server.
- Account lockout counters may not work as expected in a multi-supplier environment.
9.7. Designing Access Control
- The entire directory.
- A particular subtree of the directory.
- Specific entries in the directory.
- A specific set of entry attributes.
- Any entry that matches a given LDAP search filter.
9.7.1. About the ACI Format
- target. Specifies the entry (usually a subtree) that the ACI targets, the attribute it targets, or both. The target identifies the directory element that the ACI applies to. An ACI can target only one entry, but it can target multiple attributes. In addition, the target can contain an LDAP search filter. Permissions can be set for widely scattered entries that contain common attribute values.
- permission. Identifies the actual permission being set by this ACI. The permission variable states that the ACI is allowing or denying a specific type of directory access, such as read or search, to the specified target.
- bind rule. Identifies the bind DN or network location to which the permission applies. The bind rule may also specify an LDAP filter, and if that filter is evaluated to be true for the binding client application, then the ACI applies to the client application.
target (permission bind_rule)(permission bind_rule)...
9.7.1.1. Targets
targetattr
parameter to target one or more attributes. If the targetattr
parameter is not set, no attributes are targeted. For further details, see the corresponding section in the Red Hat Directory Server Administration Guide.
9.7.1.2. Permissions
Permission | Description |
---|---|
Read | Indicates whether directory data may be read. |
Write | Indicates whether directory data may be changed or created. This permission also allows directory data to be deleted but not the entry itself. To delete an entire entry, the user must have delete permissions. |
Search |
Indicates whether the directory data can be searched. This differs from the read permission in that read allows directory data to be viewed if it is returned as part of a search operation.
For example, if searching for common names is allowed as well as read permission for a person's room number, then the room number can be returned as part of the common name search, but the room number itself cannot be used as the subject of a search. Use this combination to prevent people from searching the directory to see who sits in a particular room.
|
Compare | Indicates whether the data may be used in comparison operations. The compare permission implies the ability to search, but actual directory information is not returned as a result of the search. Instead, a simple Boolean value is returned which indicates whether the compared values match. This is used to match userPassword attribute values during directory authentication. |
Self-write | Used only for group management. This permission enables a user to add to or delete themselves from a group. |
Add | Indicates whether child entries can be created. This permission enables a user to create child entries beneath the targeted entry. |
Delete | Indicates whether an entry can be deleted. This permission enables a user to delete the targeted entry. |
Proxy | Indicates that the user can use any other DN, except Directory Manager, to access the directory with the rights of this DN. |
9.7.1.3. Bind Rules
- Only if the bind operation is arriving from a specific IP address (IPv4 or IPv6) or DNS host name. This is often used to force all directory updates to occur from a given machine or network domain.
- If the person binds anonymously. Setting a permission for anonymous bind also means that the permission applies to anyone who binds to the directory as well.
- For anyone who successfully binds to the directory. This allows general access while preventing anonymous access.
- Only if the client has bound as the immediate parent of the entry.
- Only if the entry as which the person has bound meets a specific LDAP search criteria.
- Parent. If the bind DN is the immediate parent entry, then the bind rule is true. This means that specific permissions can be granted that allow a directory branch point to manage its immediate child entries.
- Self. If the bind DN is the same as the entry requesting access, then the bind rule is true. Specific permission can be granted to allow individuals to update their own entries.
- All. The bind rule is true for anyone who has successfully bound to the directory.
- Anyone. The bind rule is true for everyone. This keyword is used to allow or deny anonymous access.
9.7.2. Setting Permissions
9.7.2.1. The Precedence Rule
9.7.2.2. Allowing or Denying Access
uid
attribute. Alternatively, write two access rules that allow write access in the following ways:
- Create one rule that allows write privileges to every attribute except the
uid
attribute. This rule should apply to everyone. - Create one rule that allows write privileges to the
uid
attribute. This rule should apply only to members of the Directory Administrators group.
9.7.2.3. When to Deny Access
- There is a large directory tree with a complex ACL spread across it.For security reasons, it may be necessary to suddenly deny access to a particular user, group, or physical location. Rather than spending the time to carefully examine the existing ACL to understand how to appropriately restrict the allow permissions, temporarily set the explicit deny privilege until there is time to do the analysis. If the ACL has become this complex, then, in the long run, the deny ACI only adds to the administrative overhead. As soon as possible, rework the ACL to avoid the explicit deny privilege and then simplify the overall access control scheme.
- Access control should be based on a day of the week or an hour of the day.For example, all writing activities can be denied from Sunday at 11:00 p.m. (2300) to Monday at 1:00 a.m. (0100). From an administrative point of view, it may be easier to manage an ACI that explicitly restricts time-based access of this kind than to search through the directory for all the allow-for-write ACIs and restrict their scopes in this time frame.
- Privileges should be restricted when delegating directory administration authority to multiple people.To allow a person or group of people to manage some part of the directory tree, without allowing them to modify some aspect of the tree, use an explicit deny privilege.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.
9.7.2.4. Where to Place Access Control Rules
domainComponent
, country
, organization
, organizationalUnit
, inetOrgPerson
, or group
.
9.7.2.5. Using Filtered Access Control Rules
organizationalUnit
attribute that is set to Marketing.
- Create an attribute on every user's directory entry called
publishHomeContactInfo
. - Set an access control rule that grants read access to the
homePhone
andhomePostalAddress
attributes only for entries whosepublishHomeContactInfo
attribute is set totrue
(meaning enabled). Use an LDAP search filter to express the target for this rule. - Allow the directory users to change the value of their own
publishHomeContactInfo
attribute to eithertrue
orfalse
. In this way, the directory user can decide whether this information is publicly available.
9.7.3. Viewing ACIs: Get Effective Rights
ldapsearch
which returns the access control permissions set on each attribute within an entry, and allows an LDAP client to determine what operations the server's access control configuration allows a user to perform.
- 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
andsalary
, but only HR Group members have the rights to modify or delete them. - A user can use the get effective rights option to determine what attributes they can view or modify on their personal entry. For example, a user should have access to attributes such as
homePostalAddress
andcn
, but may only have read access totitle
andsalary
.
ldapsearch
executed using the -E
switch returns the access controls on a particular entry as part of the normal search results. The following search shows the rights that user Ted Morris has to his personal entry:
ldapsearch -x -p 389 -h server.example.com -D "uid=tmorris,ou=people,dc=example,dc=com" -W -b "uid=tmorris,ou=people,dc=example,dc=com" -E !1.3.6.1.4.1.42.2.27.9.5.2:dn:uid=tmorris,ou=people,dc=example,dc=com "(objectClass=*)" version: 1 dn: uid=tmorris,ou=People,dc=example,dc=com givenName: Ted sn: Morris ou: Accounting ou: People l: Santa Clara manager: uid=dmiller,ou=People,dc=example,dc=com roomNumber: 4117 mail: tmorris@example.com facsimileTelephoneNumber: +1 408 555 5409 objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson uid: tmorris cn: Ted Morris userPassword: {SSHA}bz0uCmHZM5b357zwrCUCJs1IOHtMD6yqPyhxBA== entryLevelRights: vadn attributeLevelRights: givenName:rsc, sn:rsc, ou:rsc, l:rscow, manager:rsc, roomNumber:rscwo, mail:rscwo, facsimileTelephoneNumber:rscwo, objectClass:rsc, uid:rsc, cn:rsc, userPassword:wo
entryLevelRights
. He can read, search, compare, self-modify, or self-delete the location (l
) attribute but only self-write and self-delete rights to his password, as shown in the attributeLevelRights
result.
userPassword
value is removed, then a future effective rights search on the above entry would not return any effective rights for userPassword
, even though self-write and self-delete rights could be allowed. Similarly, if the street
attribute were added with read, compare, and search rights, then street: rsc
would appear in the attributeLevelRights
results.
*
) returns the rights for all possible attributes for an entry, including non-existent attributes.
ldapsearch -x -E !1.3.6.1.4.1.42.2.27.9.5.2:dn:uid=scarter,ou=people,dc=example,dc=com "(objectclass=*)" "*"
+
) returns operational attributes for the entry, which are not normally returned in an ldapsearch
asterisk (*). For example:
ldapsearch -x -E !1.3.6.1.4.1.42.2.27.9.5.2:dn:uid=scarter,ou=people,dc=example,dc=com "(objectclass=*)" "+"
*
) and the plus sign (+
) can be used together to return every attribute for the entry.
9.7.4. Using ACIs: Some Hints and Tricks
- Minimize the number of ACIs in the directory.Although the Directory Server can evaluate over 50,000 ACIs, it is difficult to manage a large number of ACI statements. A large number of ACIs makes it hard for human administrators to immediately determine the directory object available to particular clients.Directory Server minimizes the number of ACIs in the directory by using macros. Macros are placeholders that are used to represent a DN, or a portion of a DN, in an ACI. Use the macro to represent a DN in the target portion of the ACI or in the bind rule portion, or both. For more information on macro ACIs, see the "Managing Access Control" chapter in the Red Hat Directory Server Administration Guide.
- Balance allow and deny permissions.Although the default rule is to deny access to any user who has not been specifically granted access, it may be better to reduce the number of ACIs by using one ACI to allow access close to the root of the tree, and a small number of deny ACIs close to the leaf entries. This scenario can avoid the use of multiple allow ACIs close to the leaf entries.
- 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.For example, the
person
object class contains a large number of attributes. To allow a user to update only one or two of these attributes, write the ACI so that it allows write access for only those few attributes. However, to allow a user to update all but one or two attributes, create the ACI so that it allows write access for everything but a few named attributes. - Use LDAP search filters cautiously.Search filters do not directly name the object for which you are managing access. Consequently their use can produce unexpected results. This is especially true as the directory becomes more complex. Before using search filters in ACIs, run an
ldapsearch
operation using the same filter to make clear what the results of the changes mean to the directory. - Do not duplicate ACIs in differing parts of the directory tree.Guard against overlapping ACIs. For example, if there is an ACI at the directory root point that allows a group write access to the
commonName
andgivenName
attributes, and another ACI that allows the same group write access for only thecommonName
attribute, then consider reworking the ACIs so that only one control grants the write access for the group.As the directory grows more complex, the risk of accidentally overlapping ACIs quickly increases. By avoiding ACI overlap, security management becomes easier while potentially reducing the total number of ACIs contained in the directory. - Name ACIs.While naming ACIs is optional, giving each ACI a short, meaningful name helps with managing the security model.
- Group ACIs as closely together as possible within the directory.Try to limit ACI placement to the directory root point and to major directory branch points. Grouping ACIs helps to manage the total list of ACIs, as well as helping keep the total number of ACIs in the directory to a minimum.
- Avoid using double negatives, such as deny write if the bind DN is not equal to cn=Joe.Although this syntax is perfectly acceptable for the server, it is confusing for a human administrator.
9.7.5. Applying ACIs to the Root DN (Directory Manager)
dse.ldif
file, not in the regular user database, and so ACI targets do not include that user.
- Time-based access controls for time ranges, such as 8a.m. to 5p.m. (0800 to 1700).
- Day-of-week access controls, so access is only allowed on explicitly defined days
- IP address rules, where only specified IP addresses, domains, or subnets are explicitly allowed or denied
- Host access rules, where only specified host names, domain names, or subdomains are explicitly allowed or denied
Important
Note
9.8. Encrypting the Database
9.9. Securing Server Connections
- Transport Layer Security (TLS).To provide secure communications over the network, the Directory Server can use LDAP over the Transport Layer Security (TLS).TLS can be used in conjunction with encryption algorithms from RSA. The encryption method selected for a particular connection is the result of a negotiation between the client application and Directory Server.
- Start TLS.Directory Server also supports Start TLS, a method of initiating a Transport Layer Security (TLS) connection over a regular, unencrypted LDAP port.
- Simple Authentication and Security Layer (SASL).SASL is a security framework, meaning that it sets up a system that allows different mechanisms to authenticate a user to the server, depending on what mechanism is enabled in both client and server applications. It can also establish an encrypted session between the client and a server. In Directory Server, SASL is used with GSS-API to enable Kerberos logins and can be used for almost all server to server connections, including replication, chaining, and pass-through authentication. (SASL cannot be used with Windows Sync.)
9.10. Using SELinux Policies
- dirsrv_t for the Directory Server
- dirsrv_snmp_t for the SNMP
Figure 9.4. Editing Directory Server File Labeling
- Files and directories for each instance are labeled with a specific SELinux context. (Most of the main directories used by Directory Server have subdirectories for all local instances, no matter how many, so a single policy is easily applied to new instances.)
- The ports for each instance are labeled with a specific SELinux context.
- All Directory Server processes are constrained within the appropriate domain.
- Each domain has specific rules that define what actions are authorized for the domain.
- Any access not specified in the SELinux policy is denied to the instance.
9.11. Other Security Resources
- Understanding and Deploying LDAP Directory Services. T. Howes, M. Smith, G. Good, Macmillan Technical Publishing, 1999.
- SecurityFocus.com http://www.securityfocus.com
- Computer Emergency Response Team (CERT) Coordination Center http://www.cert.org
Chapter 10. Directory Design Examples
10.1. Design Example: A Local Enterprise
10.1.1. Local Enterprise Data Design
- Example Corp.'s directory will be used by a messaging server, a web server, a calendar server, a human resources application, and a white pages application.
- The messaging server performs exact searches on attributes such as
uid
,mailServerName
, andmailAddress
. To improve database performance, Example Corp. will maintain indexes for these attributes to support searches by the messaging server.For more information on using indexes, see Section 6.4, “Using Indexes to Improve Database Performance”. - The white pages application frequently searches for user names and phone numbers. The directory therefore needs to be capable of frequent substring, wildcard, and fuzzy searches, which return large sets of results. Example Corp. decides to maintain presence, equality, approximate, and substring indexes for the
cn
,sn
, andgivenName
attributes and presence, equality, and substring indexes for thetelephoneNumber
attribute. - Example Corp.'s directory maintains user and group information to support an LDAP server-based intranet deployed throughout the organization. Most of Example Corp.'s user and group information will be centrally managed by a group of directory administrators. However, Example Corp. also wants email information to be managed by a separate group of mail administrators.
- Example Corp. plans to support public key infrastructure (PKI) applications in the future, such as S/MIME email, so it needs to be prepared to store users' public key certificates in the directory.
10.1.2. Local Enterprise Schema Design
inetOrgPerson
object class to represent the entries in the directory. This object class is appealing because it allows the userCertificate
and uid
(userID) attributes, both of which are needed by the applications supported by Example Corp.'s directory.
examplePerson
object class to represent employees of Example Corp. It derives this object class from the inetOrgPerson
object class.
examplePerson
object class allows one attribute, the exampleID
attribute. This attribute contains the special employee number assigned to each Example Corp. employee.
examplePerson
object class as needed.
10.1.3. Local Enterprise Directory Tree Design
- The root of the directory tree is Example Corp.'s Internet domain name:
dc=example,dc=com
. - The directory tree has four branch points:
ou=people
,ou=groups
,ou=roles
,
andou=resources
. - All of Example Corp.'s people entries are created under the
ou=people
branch.The people entries are all members of theperson
,organizationalPerson
,inetOrgPerson
, andexamplePerson
object classes. Theuid
attribute uniquely identifies each entry's DN. For example, Example Corp. contains entries for Babs Jensen (uid=bjensen)
and Emily Stanton (uid=estanton
). - They create three roles, one for each department in Example Corp.: sales, marketing, and accounting.Each person entry contains a role attribute which identifies the department to which the person belongs. Example Corp. can now create ACIs based on these roles.For more information about roles, see Section 4.3.2, “About Roles”.
- They create two group branches under the
ou=groups
branch.The first group,cn=administrators
, contains entries for the directory administrators, who manage the directory contents.The second group,cn=messaging admin
, contains entries for the mail administrators, who manage mail accounts. This group corresponds to the administrators group used by the messaging server. Example Corp. ensures that the group it configures for the messaging server is different from the group it creates for Directory Server. - They create two branches under the
ou=resources
branch, one for conference rooms (ou=conference rooms
) and one for offices (ou=offices
). - They create a class of service (CoS) that provides values for the
mailquota
attribute depending on whether an entry belongs to the administrative group.This CoS gives administrators a mail quota of 100GB while ordinary Example Corp. employees have a mail quota of 5GB.See Section 5.3, “About Classes of Service” for more information about class of service.
Figure 10.1. Directory Tree for Example Corp.
10.1.4. Local Enterprise Topology Design
10.1.4.1. Database Topology
root suffix
information are stored in a third database (DB3). This is illustrated in Figure 10.2, “Database Topology for Example Corp.”.
Figure 10.2. Database Topology for Example Corp.
Figure 10.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 main copy of the data being modified.
10.1.5. Local Enterprise Replication Design
10.1.5.1. Supplier Architecture
Figure 10.4. Supplier Architecture for Example Corp.
10.1.5.2. Supplier Consumer Architecture
Figure 10.5. Supplier and Consumer Architecture for Example Corp.
10.1.6. Local Enterprise Security Design
- They create an ACI that allows employees to modify their own entries.Users can modify all attributes except the
uid
,manager
anddepartment
attributes. - To protect the privacy of employee data, they create an ACI that allows only the employee and their manager to see the employee's home address and phone number.
- They create an ACI at the root of the directory tree that allows the two administrator groups the appropriate directory permissions.The directory administrators group needs full access to the directory. The messaging administrators group needs write and delete access to the
mailRecipient
andmailGroup
object classes and the attributes contained on those object classes, as well as themail
attribute. Example Corp. also grants the messaging administrators groupwrite
,delete
, andadd
permissions to the group subdirectory for creation of mail groups. - They create a general ACI at the root of the directory tree that allows anonymous access for read, search, and compare access.This ACI denies anonymous write access to password information.
- To protect the server from denial of service attacks and inappropriate use, they set resource limits based on the
DN
used by directory clients to bind.Example Corp. allows anonymous users to receive 100 entries at a time in response to search requests, messaging administrative users to receive 1,000 entries, and directory administrators to receive an unlimited number of entries.For more information about setting resource limits based on the bind DN, see 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.For more information about password policies, see Section 9.6, “Designing a Password Policy”.
- They create an ACI that gives members of the accounting role access to all payroll information.
10.1.7. Local Enterprise Operations Decisions
- Back up the databases every night.
- Use SNMP to monitor the server status.For more information about SNMP, see the Red Hat Directory Server Administrator's Guide.
- Auto-rotate the access and error logs.
- Monitor the error log to ensure that the server is performing as expected.
- Monitor the access log to screen for searches that should be indexed.
10.2. Design Example: A Multinational Enterprise and Its Extranet
10.2.1. Multinational Enterprise Data Design
- A messaging server is used to provide email routing, delivery, and reading services for most of Example Corp.'s sites. An enterprise server provides document publishing services. All servers run on Red Hat Enterprise Linux 7.
- Example Corp. needs to allow data to be managed locally. For example, the European site will be responsible for managing the Europe branch of the directory. This also means that Europe will be responsible for the main copy of its data.
- Because of the geographic distribution of Example Corp.'s offices, the directory needs to be available to users and applications 24 hours a day.
- Many of the data elements need to accommodate data values of several different languages.
Note
All data use the UTF-8 characterset; any other characterset violates LDAP standards.
- Parts suppliers need to log in to Example Corp.'s directory to manage their contracts with Example Corp. Parts suppliers depend on data elements used for authentication, such as name and user password.
- Example Corp.'s partners will use the directory to look up contact details of people in the partner network, such as email addresses and phone numbers.
10.2.2. Multinational Enterprise Schema Design
exampleSupplier
object class and the examplePartner
object class.
exampleSupplier
object class allows one attribute, the exampleSupplierID
attribute. This attribute contains the unique ID assigned by Example Corp. International to each automobile parts supplier with which it works.
examplePartner
object class allows one attribute, the examplePartnerID
attribute. This attribute contains the unique ID assigned by Example Corp. International to each trade partner.
10.2.3. Multinational Enterprise Directory Tree Design
- The root of the directory tree is the
dc=com
suffix. Under this suffix, Example Corp. creates two branches. One branch,dc=exampleCorp,dc=com
, contains data internal to Example Corp. International. The other branch,dc=exampleNet,dc=com
, contains data for the extranet. - The directory tree for the intranet (under
dc=exampleCorp,dc=com)
has three main branches, each corresponding to one of the regions where Example Corp. has offices. These branches are identified using thel
(locality) attribute. - Each main branch under
dc=exampleCorp,dc=com
mimics the original directory tree design of Example Corp. Under each locality, Example Corp. creates anou=people
, anou=groups
, anou=roles
, and anou=resources
branch. See Figure 10.1, “Directory Tree for Example Corp.” for more information about this directory tree design. - Under the
dc=exampleNet,dc=com
branch, Example Corp. creates three branches. One branch for suppliers (o=suppliers
), one branch for partners (o=partners
), and one branch for groups (ou=groups
). - The
ou=groups
branch of the extranet contains entries for the administrators of the extranet as well as for mailing lists that partners subscribe to for up-to-date information on automobile parts manufacturing.
Figure 10.6. Basic Directory Tree for Example Corp. International
Figure 10.7. Directory Tree for Example Corp. International's Intranet
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
Figure 10.8. Directory Tree for Example Corp. International's Extranet
10.2.4. Multinational Enterprise Topology Design
10.2.4.1. Database Topology
Figure 10.9. Database Topology for Example Corp. Europe
l=US
branch are chained by a database link to a database on a server in Austin, Texas. For more information about database links and chaining, see Section 6.3.2, “Using Chaining”.
dc=exampleCorp,dc=com
and the root entry, dc=com
, is stored in the l=Europe
database.
o=suppliers
is stored in database one (DB1), that for o=partners
is stored in database two (DB2), and that for ou=groups
is stored in database three (DB3).
Figure 10.10. Database Topology for Example Corp. International's Extranet
10.2.4.2. Server Topology
Figure 10.11. Server Topology for Example Corp. Europe
Figure 10.12. Server Topology for Example Corp. International's Extranet
10.2.5. Multinational Enterprise Replication Design
- Data will be managed locally.
- The quality of network connections varies from site to site.
- Database links will be used to connect data on remote servers.
- Hub servers that contain read-only copies of the data will be used to replicate data to consumer servers.
10.2.5.1. Supplier Architecture
dc=exampleCorp,dc=com
and dc=com
information:
Figure 10.13. Supplier Architecture for Example Corp. Europe
Figure 10.14. Multi-Supplier Replication Design for Example Corp. Europe and Example Corp. US
10.2.6. Multinational Enterprise Security Design
- Example Corp. adds general ACIs to the root of the intranet, creating more restrictive ACIs in each country and the branches beneath each country.
- Example Corp. decides to use macro ACIs to minimize the number of ACIs in the directory.Example Corp. uses a macro to represent a DN in the target or bind rule portion of the ACI. When the directory gets an incoming LDAP operation, the ACI macros are matched against the resource targeted by the LDAP operation. If there is a match, the macro is replaced by the value of the DN of the targeted resource.For more information about macro ACIs, see the Red Hat Directory Server Administrator's Guide.
- Example Corp. decides to use certificate-based authentication for all extranet activities. When people log in to the extranet, they need a digital certificate. The directory is used to store the certificates. Because the directory stores the certificates, users can send encrypted email by looking up public keys stored in the directory.
- Example Corp. creates an ACI that forbids anonymous access to the extranet. This protects the extranet from denial of service attacks.
- Example Corp. wants updates to the directory data to come only from an Example Corp. hosted application. This means that partners and suppliers using the extranet can only use the tools provided by Example Corp. Restricting extranet users to Example Corp.'s preferred tools allows Example Corp. administrators to use the audit logs to track the use of the directory and limits the types of problems that can be introduced by extranet users outside of Example Corp. International.
Appendix A. Directory Server RFC Support
Note
A.1. LDAPv3 Features
- Technical Specification Road Map (RFC 4510)
- This is a tracking document and does not contain requirements.
- The Protocol (RFC 4511)
- Supported. Exceptions:
- RFC 4511 Section 4.4.1. Notice of Disconnection: Directory Server terminates the connections in this case.
- RFC 4511 Section 4.5.1.3. SearchRequest.derefAliases: LDAP aliases are not supported.
- Directory Information Models (RFC 4512)
- Supported. Exceptions:
- RFC 4512 Section 2.4.2. Structural Object Classes: Directory Server supports entries with multiple structural object classes.
- RFC 4512 Section 4.1.2. Attribute Types: The attribute type
COLLECTIVE
is not supported.
Note that RFC 4512 enables LDAP servers to not support the previously listed exceptions. For further details, see RFC 4512 Section 7.1. Server Guidelines. - Authentication Methods and Security Mechanisms (RFC 4513)
- Supported.
- String Representation of Distinguished Names (RFC 4514)
- Supported.
- String Representation of Search Filters (RFC 4515)
- Supported.
- Uniform Resource Locator (RFC 4516)
- Supported. However, this RFC is mainly focused on LDAP clients.
- Syntaxes and Matching Rules (RFC 4517)
- Supported. Exceptions:
directoryStringFirstComponentMatch
integerFirstComponentMatch
objectIdentifierFirstComponentMatch
objectIdentifierFirstComponentMatch
keywordMatch
wordMatch
- Internationalized String Preparation (RFC 4518)
- Supported.
- Schema for User Applications (RFC 4519)
- Supported.
A.2. Authentication Methods
- Anonymous SASL Mechanism (RFC 4505)
- Not supported. Note that RFC 4512 does not require the
ANONYMOUS
SASL mechanism. However, Directory Server support LDAP anonymous binds. - External SASL Mechanism (RFC 4422)
- Supported.
- Plain SASL Mechanism (RFC 4616)
- Not supported. Note that RFC 4512 does not require the
PLAIN
SASL mechanism. However, Directory Server support LDAP anonymous binds. - SecurID SASL Mechanism (RFC 2808)
- Not supported. However if a Cyrus SASL plug-in exists, Directory Server is able to use it.
- Kerberos V5 (GSSAPI) SASL Mechanism (RFC 4752)
- Supported.
- CRAM-MD5 SASL Mechanism (RFC 2195)
- Supported.
- Digest-MD5 SASL Mechanism (RFC 2831)
- Supported.
- One-time Password SASL Mechanism (RFC 2444)
- Not supported. However if a Cyrus SASL plug-in exists, Directory Server is able to use it.
A.3. X.509 Certificates Schema and Attributes Support
- LDAP Schema Definitions for X.509 Certificates (RFC 4523)
- Attribute types and object classes: Supported.
- Syntaxes: Not supported. Directory Server uses binary and octet syntax.
- Matching rules: Not supported.
Appendix B. Revision History
Revision History | |||
---|---|---|---|
Revision 11.5-1 | Tue May 10 2022 | ||
| |||
Revision 11.4-1 | Tue Nov 09 2021 | ||
| |||
Revision 11.3-1 | Tue May 11 2021 | ||
| |||
Revision 11.2-1 | Tue Nov 03 2020 | ||
| |||
Revision 11.1-1 | Tue Apr 28 2020 | ||
|
Revision History | |||
---|---|---|---|
Revision 11.0-1 | Thu Nov 21 2019 | ||
|