Planning and designing Directory Server

Red Hat Directory Server provides global directory services by providing information to a wide variety of applications. Until recently, many applications came bundled with their own proprietary user databases, with information about the users specific to that application. While a proprietary database is convenient if you use only one application, multiple databases become an administrative burden if the databases manage the same information.

For example, a company runs three different proprietary email systems, and each email system has its own proprietary directory service. If users change their passwords in one directory, the changes are not automatically replicated to other directories. Management of the same information in different places increases the hardware and personnel costs. The increased maintenance overhead is referred to as the n+1 directory problem.

A global directory service solves the n+1 directory problem by offering a centralized repository accessible to any application. However, giving a wide variety of applications access to the directory service requires a network-based means of communicating between the applications and the directory service.

Red Hat Directory Server uses LDAP for applications to access to its global directory service.

LDAP provides a common language that client applications and servers use to communicate with one another. LDAP is a "lightweight" version of the Directory Access Protocol (DAP) that the ISO X.500 standard describes.

DAP gives any application access to the directory through an extensible and robust information framework but at a high administrative cost. DAP uses a communications layer that is not the Internet standard protocol and has complex directory-naming conventions.

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

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

The server frontend of Directory Server manages communications with directory client applications using LDAP over TCP/IP and LDAP over Unix sockets (LDAPI).

Directory Server can establish a secure (encrypted) connection with Transport Layer Security (TLS), depending on if the client negotiates to use TLS for the connection. If clients were issued certificates, Directory Server can use TLS to confirm that the client has the right to access the server. In addition, TLS is used to perform other security activities, such as message integrity checks, digital signatures, and mutual authentication between servers.

The directory tree, also known as a directory information tree (DIT), mirrors the tree model used by most file systems. During installation, Directory Server creates a default directory tree.

After an installation, the directory contains the following root suffix and subtrees:

You can extend the default directory tree by adding any data relevant to the directory installation. For more information about directory trees, see Designing the directory tree.

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

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

For example, an entry can have organizationalPerson object class indicating that the entry represents a person in an organization. This object class supports the givenName and telephoneNumber attributes. The values assigned to these attributes define the name and phone number of the person the entry presents.

Directory Server also uses read-only operational attributes that the server calculates. Administrators can manually set these operational attributes for access control and other server functions.

By default, an LDAP search does not return all entries and excludes administrative entries that have the ldapsubentry object class. Administrative entries can be used to define a role or a class of service. To include these entries in the search response, client applications need to additionally search for entries with the ldapsubentry object class.

If you store parts of the directory tree in a separate database, the directory can process client requests in parallel improving performance. You can even store databases on different machines for further performance improvement. To connect part of the directory, Directory Server uses database links and chaining. For more information about database links and chaining, see Using referrals in Directory Server.

You can add to an entry useful information about a person or asset as an attribute. For example:

Using the Directory Server for purposes beyond server administration requires planning what other types of information to store in the directory. For example, you may include the following information types:

Red Hat Directory Server manages well large data volumes that client applications read and occasionally update, but Directory Server is not designed for handling large, unstructured objects, such as images or other media. You should maintain these objects in a file system. However, the directory can store pointers to these types of applications by using FTP, HTTPs, and other URL types.

The applications that access the directory and the data needs of these applications guide the planning of the directory contents. The various common applications using the directory include:

When assessing the applications that will use the directory, consider the types of information each application uses. The following table gives an example of applications and the information that the application uses:

Table 2.1. Example Application Data Needs

When you identify the applications and information that each application uses, you will understand which types of data are used by more than one application. This step in planning can prevent data redundancy in the directory, and show clearly what data directory-dependent applications require.

The following factors affect the final decision about the types of data maintained in the directory and when you migrate the information to the directory:

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

During the survey, develop a matrix that identifies all the information sources in the enterprise as in the table below:

Table 2.2. Information sources example

Characterize the data you want to include in the directory in the following ways:

Find common characteristics in the data you want to include in the directory. This helps save time during the schema design stage described Designing the directory schema.

Consider the table below that characterizes the directory data:

Table 2.3. Directory data characteristics

The service level you provide depends on the expectations of the people who rely on directory-enabled applications. To determine the service level that each application requires, determine how and when the application is used.

As the directory evolves, the directory may need to support various service levels, from production to mission-critical level. Raising the service level after the directory deployment is difficult, so ensure the initial design meets the future needs.

For example, to eliminate the risk of total failure, use a multi-supplier configuration, where several suppliers handles the same data.

A data supplier is a server that supplies the data. Storing the same information in multiple locations degrades the data integrity. A data supplier ensures that all information stored in multiple locations is consistent and accurate. The following scenarios require a data supplier:

With multi-supplier replication, Directory Server can contain the main copy of information on multiple servers. Multiple suppliers keep changelogs and safely resolve conflicts. You can configure a limited number of supplier servers that can accept changes and replicate the data to replica or consumer servers ^[1]. Several data supplier servers provide safe failover if a server goes off-line. See TBA[Designing the replication process] for more information about multi-supplier replication.

Using synchronization, you can integrate Directory Server users, groups, attributes, and passwords with Microsoft Active Directory users, groups, attributes, and passwords. If you have two directory services, decide whether they will manage the same information, what amount of that information will be shared, and which service will supply data. Preferably, select one application to manage the data and let the synchronization process to add, update, or delete the entries on the other service.

Consider the supplier source of the data if you use applications that communicate indirectly with the directory. Keep the data changing processes as simple as possible. After deciding on the place for managing a piece of data, use the same place to manage all of the other data contained there. A single place simplifies troubleshooting when databases lose synchronization across the enterprise.

You can implement the following ways to supply data supplying:

How you maintain the main copies of data depends on the specific directory needs. However, always keep the maintenance simple and consistent. For example, do not attempt to manage data in multiple places and then automatically exchange data between competing applications. Doing so leads to an update loss and increases the administrative overhead.

For example, the directory manages an employee home telephone number that is stored in both the LDAP directory and a human resources database. The human resources application is LDAP-enabled and can automatically transfer data from the LDAP directory to the human resources database, and vice versa.

If you try to manage changes to that employee telephone number in both the LDAP directory and the human resources database then the last place where the telephone number was changed overwrites the information in the other database. This is only acceptable if the last application that wrote the data had the correct information.

If that information is outdated (for example, because the human resources data were restored from a backup), then the correct telephone number in the LDAP directory will be deleted.

Data ownership refers to the person or organization responsible for making sure the data is up-to-date. During the data design phase, decide who can write data to the directory. Here are some common strategies for deciding data ownership:

Multiple individuals might require write access to the same information. For example, an information systems or directory management group may require write access to employee passwords. Also employees require the write access to their own passwords. While multiple people can have access to the same information, try to keep this group small and identifiable to ensure data integrity.

After determining data ownership, decide who gets access to read each piece of data. For example, employees home phone numbers can be stored in the directory. This data may be useful for a number of users, including the employee manager and human resources department. Employees should be able to read this information for verification purposes. However, home contact information can be considered sensitive.

Consider the following for every information stored in the directory:

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

Data protection laws in most countries govern how enterprises maintain and access personal information. For example, the laws may prohibit anonymous access to information or require users to have the ability to view and edit information in entries that represent them. Check with the organization legal department to ensure that the directory deployment complies with data protection laws in countries where the enterprise operates.

The creation of a security policy and the way it is implemented is described in detail in Designing a secure directory.

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

The schema format of Directory Server is built on version 3 of the LDAP protocol. This protocol requires Directory Server to publish their schema through LDAP itself allowing directory client applications to retrieve the schema programmatically and adapt their behavior. You can find the global set of schema for Directory Server in the cn=schema entry.

The Directory Server schema is different from the LDAPv3 schema, because it uses its proprietary object classes and attributes. Additionally, it uses a private field in the schema entries called X-ORIGIN 389 Directory Server which describes where the schema entry was defined originally.

When you define a schema entry in the standard LDAPv3 schema, the X-ORIGIN 389 Directory Server field refers to RFC 2252. If the entry is defined by Red Hat for the Directory Server’s use, the X-ORIGIN 389 Directory Server field contains the value 389 Directory Server. For example, the standard person object class appears in the schema:

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

This schema entry states:

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

For example, the directory can store a piece of data, such as a person’s name, in a pair with the standard attribute. An entry for a person named Babs Jensen has the attribute-data pair cn: Babs Jensen.

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

dn: uid=bjensen,ou=people,dc=example,dc=com
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
cn: Babs Jensen
sn: Jensen
givenName: Babs
givenName: Barbara
mail: bjensen@example.com

Each attribute definition in the schema contains the following information:

The cn attribute definition appears in the schema as follows:

attributetypes: ( 2.5.4.3 NAME 'cn' DESC 'commonName Standard Attribute'
     SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

Using the attribute’s syntax, you can define the format of the values that can be stored in the attribute. The Directory Server supports all standard attribute syntaxes.

An object class represents a real object, such as a person or a fax machine. It is used to group related information. You must identify an object class and its attributes in the schema before you use the object classes. The directory recognizes a standard list of object classes by default.

Each directory entry belongs to at least one object classes. When you place an object class identified in the schema on an entry, it informs the Directory Server that the entry can have a specific set of attribute values and must have another smaller set of required attribute values.

The following information is available in object class definitions:

The standard person object class in the schema:

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' )

You can map the data identified in the site survey to the existing directory schema. This process involves the following steps:

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.

You must assign a unique name and object identifier (OID) for each LDAP object class or attribute. When you define a schema,the elements require a base OID unique to your organization. Add another level of hierarchy to create new branches for attributes and object classes. Getting and assigning OIDs in schema involves the following steps:

You can create new object classes in the following two ways:

You can mix the two methods. For example, you want to create the attributes exampleDateOfBirth, examplePreferredOS, exampleBuildingFloor, and exampleVicePresident. A simple solution is to create several object classes that allow some subset of these attributes.

The new object classes appear in LDAPv3 schema format as follows:

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) )

Alternatively, you can create a single object class that allows all of these attributes and use it with any entry that needs them. The single object class appears as follows:

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) )

The new exampleEntry object class is marked AUXILIARY which means that it can be used with any entry regardless of its structural object class.

You can organize new object class depending on the organization environment. Consider the following when you decide on the implementation of the new object classes:

You must use standard attributes for both application compatibility and long-term maintenance. You must search the attributes already existing in the default directory schema and use them with a new object class or check the Directory Server schema guide. However, if the standard schema does not contain all the necessary information, add new attributes and new object classes.

For example, a person entry may need more attributes than the person, organizationalPerson, or inetOrgPerson object classes support by default. No attribute exists within the standard Directory Server schema to store birth dates. You can create and set a new attribute, dateOfBirth 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')

You cannot delete the schema elements included by default in Directory Server. Unused schema elements represent no operational or administrative overhead. Deleting parts of the standard LDAP schema it can cause compatibility problems with future installations of Directory Server and other directory-enabled applications.

You can, however, delete the unused custom schema elements. Before removing the object class definitions from the schema, modify each entry using the object class. Removing the definition first might prevent the entries that use the object class from being modified later. The schema checks on modified entries also fails unless the unknown object class values are removed from the entry.

You can create custom schema files for the Directory Server to use it in addition to the 99user.ldif file provided with Directory Server. These schema files have new, custom attributes and object classes specific to the organization. The new schema files are located in the schema directory, /etc/dirsrv/slapd-instance_name/schema/. All standard attributes and object classes are loaded only after custom schema elements have been loaded.

After you create the custom schema files, the schema changes can be distributed among all servers in the following way:

When you do not copy these custom schema files to all of the servers, the schema information is only replicated to the consumer server when changes are made to the schema on the supplier server. When the schema definitions are replicated to a consumer server where they do not already exist, they are stored in the 99user.ldif file.

Following suggestions help you to define a compatible and manageable custom schema.

When naming custom schema files, use the following naming format: [00-99]yourName.ldif.

If the custom schema elements are added directly to the 99user.ldif manually, use 'user defined' as the value of X-ORIGIN. If a different X-ORIGIN value is set, the server simply may overwrites it.

Using an X-ORIGIN of value 'user defined' prevents removing schema definitions in the 99user.ldif file by the Directory Server.

For example:

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')

After the Directory Server loads the schema entry, it appears as follows:

attributetypes: ( exampleContact-oid NAME 'exampleContact'
DESC 'Example Corporate contact'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
X-ORIGIN ('Example defined' 'user defined') )

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

When schema checking is enabled, you must pay attention to required and allowed attributes as defined by the object classes. The Directory Server can return an object class violation message when you add an attribute to an entry that is neither required nor allowed according to the entry’s object class definition.

For example, if an entry is defined to use the organizationalPerson object class, then the common name (cn) and surname (sn) attributes are required for the entry. The 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.

Syntax validation means the Directory Server validates that the value of an attribute matches the required syntax for that attribute. For example, syntax validation can confirm that a new telephoneNumber attribute has a valid telephone number for its value. It is enabled by default.

You can optionally configure additional settings for syntax validation to log warning messages about syntax violations and then either reject the modification or allow the modification process to succeed.

Syntax validation checks the LDAP operations if a new attribute value is added. It does not process existing attributes or attributes added through database operations like replication. Existing attributes can be validated using the dsconf schema validate-syntax command.

This feature validates all attribute syntaxes except the binary syntaxes and non-standard syntaxes, which do not have a defined required format. The syntaxes are validated against RFC 4514, except for DNs, which are validated against the less strict RFC 1779 or RFC 2253.

You can place data with attribute value by using LDAP schema. However, it is important to store data consistently in the directory tree by selecting a format appropriate for the LDAP client applications and directory users.

You can represent data in the data formats specified in RFC 2252 by using the LDAP protocol and Directory Server. For example, the correct LDAP format for telephone numbers is defined in two ITU-T recommendations documents:

As another example, the postalAddress attribute has 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

The changes are recorded in the changelog when you edit the directory schema. During replication, the changelog is scanned for changes and if any changes are being replicated. Maintaining consistency in replicated schema allows replication to continue without any error.

Consider the following points for maintaining consistent schema in a replicated environment:

A suffix is the name of the entry at the root of the directory tree, and the directory data is stored beneath it. The directory can contain more than one suffix. You can use multiple suffixes if there are two or more directory trees of information that do not have a natural common root. By default, the standard Directory Server deployment contains multiple suffixes, one for storing data and the others for data required by internal directory operations, such as configuration information and the directory schema.

In a single enterprise environment, you can choose a directory suffix that aligns with a DNS name or Internet domain name of the enterprise. For example, if the enterprise owns the domain name of example.com, then the directory suffix is dc=example,dc=com. The dc attribute represents the suffix by breaking the domain name into its component parts. Normally, you can use any attribute to name the root suffix. However, for a hosting organization, you must limit the root suffix to the following attributes:

These attributes provide interoperability with subscriber applications. For example, a hosting organization can use these attributes to create a root suffix o=example_a, st=Washington,c=US for one of its clients example_a.

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

For example, you can create separate suffixes for example_a and example_b and store them in separate databases.

You can store databases on a single server or multiple servers depending on resources limits.

Decide whether to use a flat or a hierarchical tree structure. Try to make the directory tree as flat as possible. However, a certain amount of hierarchy can be important later when information is partitioned across multiple databases, when preparing replication, or when setting access controls.

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

You need to decide which attributes to use when naming the entries within the structure after designing the hierarchy of the directory tree. When you choose one or several attribute values, you form a relative distinguished name (RDN). The RDN is the left-most part of a DN, and the attribute you choose for that part is the naming attribute. The naming attribute sets a unique name for the entry. For example, the DN uid=bjensen,ou=people,dc=example,dc=com has the RDN uid=bjensen.

The attributes you choose depend on the type of entry you are naming.

Consider the following when naming entries:

When you create entries, define the RDN within the entry. With the defined RDN within the entry, the entry can be located more easily. This is because searches look for entries based on attribute values stored in the entry itself and not based on the actual DN.

Attribute names have a meaning, so try to use the attribute name that matches the type of entry it represents. For example, do not use l (location) to represent an organization, or c (country) to represent an organizational unit.

The entry names define the directory tree structure. Each branch point creates a new link in the hierarchy.

                                                                  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

When you change the naming attribute of an entry, the entry RDN, you perform a modrdn operation. This modifying operation moves the entry within the directory tree. For leaf entries (entries with no children), modrdn operations change only an RDN part, the parent entries stay the same.

For subtree entries, the modrdn operation renames the subtree entry itself and also changes the DN components of all of the children entries under the subtree.

A similar action to renaming a subtree is moving an entry from one subtree to another. This expanded type of modrdn operation simultaneously renames the entry, even if it is the same name, and sets a newsuperior attribute that moves the entry from one parent to another.

Directory Server uses entryrdn.db index to perform new superior and subtree rename operations. Directory Server identifies each entry by a self link, parent link, and any children links. The entryrdn.db index presents parents and children as attributes to an entry and describes every entry by a unique ID and its RDN, rather than the full DN.

The entryrdn.db index has the following format:

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

For example, the ou=people subtree has the dc=example,dc=com parent and the uid=jsmith child entries. The entryrdn.db index has the following content:

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"

Consider the following when you perform rename operations:

A group is a collection of users. Directory Server has several group types that reflect the type of memberships allowed, such as certificate groups, URL groups, and unique groups that have only unique members. You define each type of group by an object class, such as groupOfUniqueNames, and a corresponding member attribute, such as uniqueMember.

The type of group identifies the type of members. The group configuration depends on how Directory Server adds members to the group. Directory Server has two group types:

Groups do not perform any operation on entries, however LDAP clients can manage groups to perform operations.

4.3.1.2. Adding automatically new entries to groups

Copy link

You can apply password policies, access control lists, and other rules based on group membership. With groups, you can apply policies consistently and reliably across the directory.

Automatically assigning new entries to groups when a new entry is created ensures that Directory Server immediately applies appropriate policies and functionality to those entries without administrator actions.

With the Automembership plug-in, a static group can act like a dynamic group. The Automembership plug-in uses a set of rules based on entry attributes, directory location, and regular expressions to assign a user automatically to a specified group.

There can be instances where the entries that match the LDAP search filter should be added to different groups depending on the value of other attributes. For example, you need to add machines to different groups depending on their IP address or physical location. Or you need to place users to different groups depending on their employee ID number.

Automember definitions are a set of nested entries, with the Auto Membership plug-in container, then the automember definition, and then any regular expression conditions for that definition.

Note

Directory Server assigns entries to a group automatically only when entries are newly added to Directory Server. For existing entries or entries that you modified to meet an automember rule, run the fix-up task to assign the proper group membership.

Roles behave as both a static and a dynamic group. With a group, Directory Server adds entries to a group entry as members. With a role, Directory Server adds the role attribute to an entry and then uses that attribute to identify members in the role entry automatically.

With roles, you can organize users in the following ways:

Managed roles can do everything that you can do with static groups. You can filter the role members by using filtered roles, similar to the filtering with dynamic groups. Roles are easier to use than groups because they are more flexible in their implementation and reduce client complexity.

You can specify members explicitly or dynamically by using role types. Directory Server supports the following types of roles:

You can activate or inactivate entire groups of entries in just one operation. You can temporarily disable the members of a role by inactivating the role to which they belong.

When you inactivate a role, a user still can bind to the server by using a role entry. However, the user cannot bind to the server by using any of the entries that belong to this role. Entries that belong to an inactivated role have the nsAccountLock attribute set to true.

When you inactivate a nested role, a user cannot bind to the server if it is a member of any role within the nested role. All entries that belong to a role that are direct or indirect members of the nested role have nsAccountLock set to true. Inactivating a nested role at any point in the nesting inactivates all roles and users under it.

Roles and groups can accomplish the same goals. Managed roles can do everything that static groups can do, while filtered roles can filter and identify members the same way as dynamic groups. Both roles and groups have advantages and disadvantages. Deciding whether to use roles, or groups, or a mix depends on balancing your requirements and server resources.

Roles reduce client-side complexity. With roles, the client application can check role membership by searching the nsRole operational attribute in 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.

However, roles require increased server complexity. Evaluating roles is more resource-intensive for the Directory Server than evaluating groups because the server does the work for the client application.

Groups require smarter and more complex clients to use them effectively. For example, dynamic groups, from an application point of view, offer no support from the server to provide a list of group members. Instead, the application retrieves the group definitions and then runs the filter. User entries contain group membership information only if you configure the appropriate plug-ins.

The LDIF entries below show a virtual view hierarchy that is based on location. Any entry that resides below 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

A subtree search based at ou=Location Views,dc=example,dc=com returns all entries below dc=example,dc=com which match the filters (l=Sunnyvale), (l=Santa Clara), or (l=Cupertino). However, a one-level search returns no entries other than the child view entries because all qualifying entries reside in the three descendant views.

The ou=Location Views,dc=example,dc=com view entry itself does not contain a filter. This feature facilitates hierarchical organization without the requirement to further restrict the entries contained in the view. Any view may omit the filter.

Although the example filters are very simple, the filters you use can be as complex as necessary. You can limit the type of entry that the view should contain. For example, to limit this hierarchy to contain only people entries, add an nsfilter attribute to ou=Location Views,dc=example,dc=com with the filter value (objectclass=organizationalperson).

Each view with a filter restricts the content of all descendant views, while descendant views with filters also restrict their ancestor contents. For example, creating the top view 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 emulate the behavior of traditional DITs.

Although virtual DIT views emulate the behavior of traditional DITs, views can do something that traditional DITs cannot: entries can appear in more than one location. For example, to associate Entry B with both Mountain View and Sunnyvale, add the Sunnyvale value to the location attribute, and the entry appears in both views.

Directory Server stores data in LDAP Database Manager (LDBM). Each database consists of a set of large files that contain all the data assigned to it.

You can store different portions of the directory trees in different databases. For example, your directory tree can appear in the following way:

Figure 5.1. Example directory tree

The directory in the example consist of following three sub-suffixes:

You can store the data of the three sub-suffixes in three separate databases in the following way:

Figure 5.2. Storing suffix data in separate databases

When you divide the directory tree among several databases, you can distribute these databases across multiple servers to reduce the workload on each server. For example, you can store three databases (DB1, DB2, and DB3) on two servers (Server A and Server B).

Figure 5.3. Dividing suffix databases between separate servers

Server A contains DB1 and DB2, and Server B contains DB3.

Directory Server supports adding databases dynamically, without stopping the entire directory service.

A database contains the data for a specific suffix (a portion of the directory tree). In Directory Server, you can create a root suffix or sub-suffix.

For example, ExampleCom creates suffixes to represent the distribution of its directory data in the following way:

Figure 5.4. Directory tree for ExampleCom

ExampleCom spreads its directory tree across four different databases in the following way:

Figure 5.5. Directory tree spread across multiple databases

The four databases contain the data for the following suffixes:

Figure 5.6. Directory tree with multiple root suffixes

The ISP creates the following root suffixes:

Directory Server returns all referrals in the format of an LDAP URL. The LDAP URL contains the following information:

For example, a client application searches though dc=example,dc=com branch for entries with the surname Jensen. However, a part of the directory tree is stored on the European server. A referral returns the following LDAP URL to the client application:

ldap://europe.example.com:389/ou=people,l=europe,dc=example,dc=com

This referral instructs the client application to contact the host europe.example.com on port 389 and submit a new search though the European branch ou=people,l=europe,dc=example,dc=com.

The LDAP client application you use determines how a referral is handled. Some client applications automatically retry the operation on the server to which they have been referred. Other client applications return the referral information to the user. Most LDAP client applications that Red Hat Directory Server provides, such as the command-line utilities, automatically follow the referral. Directory Server uses the same bind credentials supplied on the initial directory request to access the server.

Most client applications follow a limited number of referrals, or hops. The limit on the number of referrals reduces the time a client application spends trying to complete a directory lookup request and helps to eliminate hung processes caused by circular referral patterns.

Directory Server returns a default referral to clients when the server or database that was contacted does not contain the requested data.

For example, a client requests the following directory entry: uid=bjensen,ou=people,dc=example,dc=com.

However, the server only manages entries stored under the dc=europe,dc=example,dc=com suffix. The directory returns a referral to the client with information 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.

You can configure default referrals at the server and suffix levels:

In addition to default referrals, Directory Server supports smart referrals that associate a directory entry or directory tree with a specific LDAP URL. Therefore, Directory Server can forward client requests to any of the following:

Unlike default referrals, Directory Server stores smart referrals within the directory, and not in the configuration file.

For example, the directory for the American office of the ExampleCom contains the ou=people,dc=example,dc=com directory branch point.

To redirect requests on this branch to the ou=people branch of the European office of ExampleCom you can specify a smart referral on the ou=people entry itself. The smart referral has the following value:

ldap://europe.example.com:389/ou=people,dc=example,dc=com

The requests to the ou=people branch of the American directory are redirected to the European directory in the following way:

Figure 5.7. Using smart referrals to redirect requests

You can use the same mechanism to redirect queries to a different server that uses a different namespace. For example, an employee working in the Italian office of ExampleCom makes a request to the European directory service for the phone number of an ExampleCom employee in America. Directory Server returns the following referral:

ldap://america.example.com:389/ou=people,dc=example,dc=com

The following diagram shows how a referral to a different namespace works:

Figure 5.8. Redirecting a query to a different server and namespace

Finally, when serving multiple suffixes on the same server, you can redirect queries from one namespace to another served on the same server. For example, to redirect all queries for o=example,c=us on the local server to dc=example,dc=com, set the smart referral ldap:///dc=example,dc=com on the o=example,c=us entry. The third slash in the LDAP URL indicates that the URL points to the same server.

Consider the following points before using smart referrals:

Figure 5.9. A circular referral pattern

Chaining evaluates access controls differently from referrals. With referrals, a client entry (bind DN) must exist on all of the target servers. With chaining, the client entry does not need to be on all of the target servers.

5.6.1.1. Performing search requests using referrals

Copy link

The following diagram shows a client request to a server using referrals:

Figure 5.11. Sending a client request to a server using referrals

A search request occurs in the following way:

1. The client application first binds with Server A.
2. Server A contains an entry for the client that provides a user name and password, so it returns a bind acceptance message. In order for the referral to work, the client entry must be present on Server A.
3. The client application sends the operation request to Server A.
4. 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.
5. 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.
6. The bind is successful, and the client application can now resubmit its search operation to Server B.

This approach requires Server B to have a replicated copy of the client entry from Server A.

5.6.1.2. Performing search requests using chaining

Copy link

You can resolve the problem of replicating client entries across servers through chaining.

Figure 5.12. Sending a client request to a server using chaining

A search request occurs in the following way:

1. The client application binds with Server A, and Server A tries to confirm that the user name and password are correct.
2. Server A does not contain an entry corresponding to the client application. Instead, it contains a database link to Server B that contains the actual entry of the client. Server A sends a bind request to Server B.
3. Server B sends an acceptance response to Server A.
4. Server A then processes the client application request using the database link. The database link contacts a remote data store located on Server B to process the search operation.

In a chained system, the entry corresponding to the client application does not need to be located on the same server as the data the client requests. The following diagrams shoes how two chained servers can be used to complete a client search request.

Figure 5.13. Authenticating a client and retrieving data using two different servers

A search request occurs in the following way:

1. The client application binds with Server A, and Server A confirms that the user name and password are correct.
2. Server A does not contain an entry corresponding to the client application. Instead, it contains a database link to Server B that contains the actual entry of the client. Server A sends a bind request to Server B.
3. Server B sends an acceptance response to Server A.
4. Server A then processes the client request using another database link. The database link contacts a remote data store located on Server C to process the search operation.

Directory Server supports the following index types:

Consider the following points when using indexes to improve search performance:

When you consider implementing replication, answer the following fundamental questions:

Learn about the concepts that provide understanding of how Directory Server implements replication:

Data consistency refers to how closely the contents of replicated databases match each other at a given time. A supplier determines when consumers must be updated, and initiates replication. Replication can start only after consumers have been initialized.

Directory Server can always keep replicas synchronized or schedule updates for a particular time of day or day in a week.

Use constantly synchronized replicas when:

Use scheduled updates when:

The main reasons for the loose consistency are the following:

In the single-supplier replication scenario, a supplier server maintains the main copy of the directory data (read-write replica) and sends updates of this data to one or more consumer servers. All directory modifications occur on the read-write replica on the supplier server, and the consumer servers contain read-only replicas of the data.

The supplier server maintains a changelog that records all the changes made to the supplier replica.

The following diagram shows the single-supplier replication scenario:

Figure 6.1. Single-supplier replication

The total number of consumer servers that a single supplier server can manage depends on the speed of the networks and the total number of entries that are modified on a daily basis.

In a multi-supplier replication environment, main copies of the same information can exist on multiple servers, and the directory data can be updated simultaneously in different locations. The changes that occur on each server are replicated to the other servers meaning that each server functions as both a supplier and a consumer.

When the same data is modified on multiple servers, replication conflicts occur. Using a conflict resolution procedure, Directory Server uses the most recent change as the valid one.

In a multi-supplier environment, each supplier needs to have replication agreements that point to consumers and other suppliers. For example, you configure replication with two suppliers, Supplier A and Supplier B, and two consumers, Consumer C and Consumer D. In addition, you decide that one supplier updates only one consumer. On Supplier A, you create a replication agreement that points to Supplier B and Consumer C. On Supplier B, you create a replication agreement that points to Supplier A and Consumer D. The following diagram illustrates the replication agreements:

Figure 6.2. Multi-supplier replication with two suppliers

Using many suppliers requires creating a range of replication agreements. In addition, each supplier can be configured in different topologies meaning that your Directory Server environment can have 20 different directory trees and even schema differences. Many other variables may have a direct impact on the topology selection.

Suppliers can send updates to all other suppliers or to some subset of suppliers. When updates are sent to all suppliers, changes are propagated faster and the overall scenario has better failure tolerance. However, it increases the complexity of supplier configuration and introduces high network and high server demand. Sending updates to a subset of suppliers is much simpler to configure and reduces the network and server loads, but increases the risk of data loss if multiple server failures occur.

If you have 20 suppliers, then you need to create 380 replication agreements in total (20 suppliers with 19 agreements each).

If the possibility of two or more servers failing at the same time is small or connection between certain suppliers is better, consider using a partly connected topology.

In a cascading replication scenario, a hub server receives updates from a supplier server and sends those updates to consumer servers. The hub server is a hybrid, because it holds a read-only replica, like a typical consumer server, and it also maintains a changelog like a typical supplier server.

Hub server forward the supplier data to consumers and refer update requests from directory clients to suppliers.

The following diagram shows the cascading replication scenario:

Figure 6.3. Cascading replication scenario

The following diagram shows how replicas are configured on each server (read-write or read-only) and which servers maintain the changelog.

Figure 6.4. Replication traffic and changelogs in cascading replication

Cascading replication is useful in the following cases:

Any of the replication scenarios can be combined to suit the needs of the network and directory environment. One common combination is to use a multi-supplier configuration with a cascading configuration.

The following diagram shows an example topology for a mixed scenario:

Figure 6.5. Combined multi-supplier and cascading replication

Gather information about the network quality and usage to help define the replication strategy:

Replication requires resources. Consider the following resource requirements when defining the replication strategy:

In multi-supplier topologies, suppliers maintain additional logs required for replication, including the changelog of the directory edits, state information for updated entries, and tombstone entries for deleted entries. Because these log files can become very large, you must periodically clean up these files to avoid unnecessary usage of the disk space.

On each server, you can use the following attributes to configure the replication logs maintenance in a replicated environment:

Use replication to prevent directory unavailability when a single server fails. At a minimum, replicate the local directory tree to at least one backup server. How often you replicate for fault tolerance depends on your requirements. However, base this decision on the quality of the hardware and networks used by your directory. Unreliable hardware requires more backup servers.

You can choose the following strategies to prevent directory unavailability:

LDAP client applications are usually configured to search only one LDAP server. If you do not have a custom client application to rotate through LDAP servers located at different DNS hostnames, you can only configure your LDAP client application to look at a single DNS hostname for Directory Server. Therefore, you may need to use either DNS round-robins or network sorts to provide failover to your backup Directory Server.

You may need to use replication for local availability depending on the quality of your network and if your data is mission-critical.

Use replication for local availability for the following reasons:

One of the main reasons to replicate directory data is to balance the workload of your network and to improve the directory performance.

As directory entries are usually 1 KB in size, every directory search adds approximately 1 KB to your network load. If your directory users perform ten directory searches per day, then the increased network load for every directory user is around 10 KB per day. If you have a slow, heavily loaded, or unreliable WAN, you may need to replicate your directory tree to a local server.

However, determine if locally available data is worth the cost of the increased network load caused by replication. If you replicate an entire directory tree to a remote site, you potentially add a larger load on your network in comparison to the traffic that results from users' searches. This is especially true if your directory changes frequently, yet you have only a few users at the remote site who perform a few directory searches per day.

The following table compares the load impact of replicating a directory with one million entries, where 100,000 of the entries undergo daily change, with the load impact of having a small remote site of 100 employees that perform 10 searches per day each.

A compromise between making data available to local sites without overloading the network is to use scheduled replication. For more information on data consistency and replication schedules, see Data consistency.

6.3.6.1. Example of network load balancing

Copy link

This example describes an enterprise that has offices in New York (NY) and Los Angeles (LA), and each office manages a separate sub-tree.

The following diagram show how the enterprise manages the sub-trees:

Figure 6.6. The enterprise NY and LA sub-trees

Each office contains a high-speed network, but the connection between the two cities is unreliable. To balance the network load, use the following strategy:

• Select one server in each office to be the supplier server for the locally managed data.

  Replicate locally managed data from that supplier to the corresponding supplier server in the remote office. When you have main copy of the data in each location, users do not perform update and search operations over the unreliable connection. As a result, performance is optimized.

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

• Configure cascading replication in each location with an increased number of consumers dedicated to search on the local data to provide further load balancing.

  The NY office generates more NY specific searches than LA specific searches. The example shows the NY office with three NY data consumers and one LA consumer. The LA office has three LA data consumers and one NY data consumer.

Figure 6.7. Example of load balancing for the enterprise

With fractional replication, you can choose a set of attributes that Directory Server does not replicate from a supplier to a consumer or another supplier. Therefore, a database can be replicated without replicating all the information that the database contains.

Fractional replication is enabled and configured per replication agreement. Directory Server applies the exclusion of attributes equally to all entries. The excluded attributes always have no value on consumers. Therefore, a client performing a search against the consumer server never sees the excluded attributes, even if search filters explicitly specify these attributes.

Use fractional replication in the following situations:

For more details, see Managing attributes within fractional replication.

Wide area networks (WAN) typically have higher latency, a higher bandwidth-delay product, and lower speeds than local area networks. Directory Server supports efficient replication when a supplier and consumer are connected using a wide-area network.

Previously, the replication protocols that Directory Server used were highly latency-sensitive, because the supplier sent only one update operation and then waited for a response from the consumer. This led to reduced throughput with higher latencies.

Currently, a supplier sends many updates and entries to the consumer without waiting for a response, and the replication throughput is similar to throughput of a local area network.

Consider the following performance and security issues when using a WAN:

The directory stores access control instructions (ACIs) as attributes of entries and Directory Server replicates these ACIs together with other directory content. For example, to restrict access to the directory from a certain host, use only host-specific settings in the ACI. Otherwise, when the ACI is replicated to other servers, the access to the directory will be denied on all servers because Directory Server evaluates ACIs locally.

For more information about designing access control for the directory, see Designing access control.

Replication works with most of the plugins delivered with Directory Server. However, the following plugins have limitations and exceptions in multi-supplier environments.

When you use chaining to distribute entries across the directory, the server containing the database link refers to a remote server that contains the actual data. In this environment, you cannot replicate the database link. However, you might replicate the database that contains the actual data on the remote server.

In a replicated environment, the schema must be consistent across all of the servers that participate in replication. To ensure schema consistency, make schema modifications only on a single supplier server.

If you configured replication between servers, schema replication occurs by default.

Directory Server replicates changes to the schema made by using dsconf command, the web console, LDAP modify operations, or made directly to the 99user.ldif file.

If you make schema modifications on two supplier servers, consumers receive the data from the two suppliers, each with a different schema. The consumer applies the modifications of the supplier that has the more recent schema version. In this situation, the schema of the consumers always differs from one of the suppliers. To avoid this, always make sure you make schema modifications on one supplier only.

You do not need to create special replication agreements to replicate a schema. However, the same Directory Server can hold supplier and consumer replicas. Therefore, always identify the server that functions as a supplier for the schema, and then set up replication agreements between this supplier and all other servers in the replication environment that will function as consumers for the schema information.

For more information on standard schema files, see Standard schema.

If you use other custom files, you must copy these files to all servers in your topology manually after making changes on the supplier.

Protecting the directory from unauthorized access may seem straightforward, however implementing a secure solution may be more complex than it first appears. The directory information delivery path has a number of potential access points where an unauthorized client may gain access to data.

The following scenarios describe just a few examples of how an unauthorized client might access the directory data:

The authentication methods, password policies, and access control mechanisms provided by the Directory Server offer efficient ways of preventing unauthorized access.

If intruders gain access to the directory or intercept communications between Directory Server and a client application, they have the potential to modify or tamper with the directory data. The directory service is useless if clients do not trust the data or if the directory itself can not trust the modifications and queries it receives from clients.

For example, if the directory can not detect tampering, an attacker can change a client request to the server, or not forward it, and change the server response to the client. TLS and similar technologies can solve this problem by signing information at either end of the connection.

In a denial of service attack, the attacker goal is to prevent the directory from providing service to its clients. For example, an attacker might use all of the system resources, therefore preventing anyone else from using these resources. Directory Server can prevent denial of service attacks by setting limits on the resources allocated to a particular bind DN. For more information about setting resource limits based on the user bind DN, see the User management and authentication guide.

The data analysis identifies what information users, groups, partners, customers, and applications need to access the directory service. Access rights can be granted in one of two ways:

Regardless of the method used to determine access rights, create a simple table that lists the categories of users in the organization and the access rights granted to each. Consider creating a table that lists the sensitive data held in the directory and, for each piece of data, the steps taken to protect it.

When using the directory to support exchanges with business partners over an extranet or to support e-commerce applications with customers on the Internet, ensure the privacy and the integrity of the exchanged data.

Use the following ways to ensure data privacy and integrity:

As an extra security measure, conduct regular audits to verify the efficiency of the overall security policy by examining the log files and the information that SNMP agents record.

The examples show how the imaginary ISP company example.com analyzes its security needs. The example.com offers web hosting and Internet access. Part of example.com activity is to host the directories of client companies. It also provides Internet access to a number of individual subscribers. Therefore, example.com has three main categories of information in its directory:

The example.com needs the following access controls:

Anonymous access provides the easiest form of access to the directory. With anonymous access, anyone who connects to the directory can access the data.

When you configure anonymous access, you cannot track who performs what kinds of searches, only that someone performs searches. You may attempt to block a specific user or group of users from accessing some kinds of directory data, but, if anonymous access is allowed to that data, those users can still access the data simply by binding to the directory anonymously.

You can limit anonymous access. Usually, directory administrators only allow anonymous access for read, search, and compare privileges, not for write, add, delete, or self-write privileges. Often, administrators limit access to a subset of attributes that contain general information, such as names, telephone numbers, and email addresses. You should never allow anonymous access to more sensitive data, such as government identification numbers, for example, Social Security Numbers in the US, home telephone numbers and addresses, and salary information.

You can disable anonymous access entirely if you need to tighten rules on who accesses the directory data.

An unauthenticated bind is when a user attempts to bind with a user name but without a user password attribute. For example:

ldapsearch -x -D "cn=jsmith,ou=people,dc=example,dc=com" -b "dc=example,dc=com" "(cn=joe)"

Directory Server grants anonymous access if the user does not attempt to provide a password. An unauthenticated bind does not require that the bind DN be an existing entry.

As with anonymous binds, you can disable unauthenticated binds to increase security by limiting access to the database. In addition, you can disable unauthenticated binds to prevent silent bind failures for clients. Some applications may believe that it authenticated successfully to the directory because it received a bind success message when, in reality, it failed to pass a password and simply connected with an unauthenticated bind.

If anonymous access is not allowed, users must authenticate to the directory before they can access the directory contents. With simple password authentication, a client authenticates to the server by sending a reusable password.

For example, a client authenticates to the directory using a bind operation, which provides a distinguished name and a set of credentials. The server locates the entry in the directory that corresponds to the client DN and checks whether the password given by the client matches the value stored with the entry. If it does, the server authenticates the client. If it does not, the authentication operation fails, and the client receives an error message.

The bind DN often corresponds to the entry of a person. However, some directory administrators prefer to bind as an organizational entry rather than as a person. The directory requires the entry used to bind to have an object class that allows the userPassword attribute. This ensures that the directory recognizes the bind DN and password.

Most LDAP clients hide the bind DN from the user because users may find the long strings of DN characters hard to remember. When a client attempts to hide the bind DN from the user, it uses the following bind algorithm:

Simple password authentication offers an easy way to authenticate users, however it requires extra security methods. Consider restricting its use to the organization intranet. To use with connections between business partners over an extranet or for transmissions with customers on the Internet, it may be best to require a secure (encrypted) connection.

Use the nsslapd-require-secure-binds configuration attribute to turn on a secure connection by using TLS or the Start TLS. The SASL authentication or certificate-based authentication are also possible. When Directory Server and a client application establish a secure connection with each other, the client performs a simple bind with an extra level of protection by not transmitting the password in plaintext.

An alternative form of directory authentication involves using digital certificates to bind to the directory. The directory prompts users for a password when they first access it. However, rather than matching a password stored in the directory, the password opens the user certificate database.

If the user supplies the correct password, the directory client application obtains authentication information from the certificate database. The client application and the directory then use this information to identify the user by mapping the user certificate to a directory DN. The directory allows or denies access based on the directory DN identified during this authentication process.

Proxy authentication is a special form of authentication because the user requesting access to the directory does not bind with its own DN but with a proxy DN.

The proxy DN is an entity that has appropriate permissions to perform the operation the user requests. When a person or an application receives proxy permissions, they can specify any DN as a proxy DN, with the exception of the Directory Manager DN.

One of the main advantages of proxy permissions is that an LDAP application can use a single thread with a single bind to service multiple users making requests against Directory Server. Instead of having to bind and authenticate for each user, the client application binds to the Directory Server using a proxy DN.

The proxy DN is specified in the LDAP operation the client application submits. For example:

ldapmodify -D "cn=Directory Manager" -W -H ldap://server.example.com -X "dn:cn=joe,dc=example,dc=com" -f mods.ldif

With this command, the manager entry cn=Directory Manager receives permissions of a user cn=joe to apply the modifications to the mods.ldif file. The manager does not need to provide the user password to make this change.

Pass-through authentication (PTA) is when Directory Server forwards any authentication request from one server to another server.

For example, when Directory Server stores all configuration information for an instance in another directory instance, Directory Server uses pass-through authentication for the User Directory Server to connect to the Configuration Directory Server. PTA plug-in handles Directory Server-to-Directory Server pass-through authentication.

Many systems already have authentication mechanisms for Unix and Linux users, such as Pluggable Authentication Modules (PAM). You can configure a PAM module to tell Directory Server to use an existing authentication store for LDAP clients. Directory Server interacts with the PAM service to authenticate LDAP clients by using PAM Pass-through Authentication plug-in.

With PAM pass-through authentication, when a user attempts to bind to Directory Server, Directory Server forwards the credentials to the PAM service. If the credentials match the information in the PAM service, then the user can successfully bind to the Directory Server, with all of the Directory Server access control restrictions and account settings.

You can configure the PAM service by using the System Security Services Daemon (SSSD). Simply point the PAM Pass-through Authentication plug-in to the PAM file that SSSD uses, such as /etc/pam.d/system-auth by default. SSSD can use a variety of different identity providers, including Active Directory, Red Hat Directory Server, or other directories like OpenLDAP, or local system settings.

An authentication attempt first evaluates if the user account can authenticate. The account must fall under the following criteria:

Sometimes a client application needs to perform the authentication of a user account when the user should not or cannot bind to Directory Server for real. For example, a system may be using PAM to manage system accounts, and you configured PAM to use the LDAP directory as its identity store. However, the system uses passwordless credentials, such as SSH keys or RSA tokens, and those credentials cannot be passed to authenticate to the Directory Server.

Red Hat Directory Server supports the Account Usability Extension Control extension for LDAP searches. This extension returns an extra line for each returned entry that gives the account status and some information about the password policy for that account. A client or application can then use that status to evaluate authentication attempts made outside Directory Server for that user account. Basically, this control signals whether a user should be allowed to authenticate without having to perform an authentication operation.

In addition, you can use this extension with system-level services like PAM to allow passwordless logins which still use Directory Server to store identities and even control account status.

Directory Server supports fine-grained password policies, which means Directory Server defines a password policy at any point in the directory tree. Directory Server defines password policies at the following levels:

By default, Directory Server includes entries and attributes that are relevant to the global password policy, meaning the same policy is applied to all users. To set up a password policy for a subtree or user, add additional entries at the subtree or user level and enable the nsslapd-pwpolicy-local attribute of the cn=config entry. This attribute acts as a switch turning fine-grained password policy on and off.

You can change password policies by using the command line or the web console. In the command line, the dsconf pwpolicy command changes global policies and the dsconf localpwp command changes local policies. You can find the procedures for setting password policies in the Configuring password policies section.

When a user attempts to bind to the directory, Directory Server determines whether a local policy has been defined and enabled for the user entry. Directory Server checks policy settings in the following order:

In addition to bind requests, password policy checking also occurs during add and modify operations if the userPassword attribute is present in the request.

Modifying the value of userPassword checks two password policy settings:

Both adding and modifying the value of userPassword checks password policies set for the password syntax:

Learn about the attributes that you can use to create a password policy for the server. Directory Server stores password policy attributes in the cn=config entry, and you can change these settings by using dsconf utility.

Directory Server has two ways to count login attempts and lock an account when login attempts reach the limit:

For example, if the failure limit is three attempts, the account can be locked at the third failed attempt (n) or at the fourth failed attempt (n+1). The n+1 behavior is the historical behavior for LDAP servers, so it is considered as legacy behavior. Newer LDAP clients expect a stricter hard limit. By default, Directory Server uses the strict limit (n), but you can change the legacy behavior in the passwordLegacyPolicy configuration parameter.

If you configure this setting for the password policy, users are required to change their password even if user-defined passwords are disabled. If the password policy does not require or does not allow the password change by a user, administrator-assigned passwords should not follow any obvious convention and should be difficult to discover.

The default configuration does not require that users change their password after it has been reset.

Setting passwords by administrators for users has the following disadvantages:

By default, user-defined passwords are allowed.

By default, user passwords never expire.

Directory Server displays the warning when a user binds to the server. If password expiration is enabled, by default, Directory Server sends a warning to a user, by using an LDAP message, one day before the user password expires. The user client application should support this feature.

The valid range for a password expiration warning is from one to 24,855 days.

By default, Directory Server does not permit grace logins.

The default password syntax requires a minimum password length of eight characters and that no trivial words are used in the password. A trivial word is any value stored in the uid, cn, sn, givenName, ou, or mailattributes of the user entry.

Additionally, you can use other forms of password syntax enforcement, providing different optional categories for the password syntax:

The more categories of syntax required, the stronger the password.

By default, password syntax checking is disabled.

By default, the server does not have a minimum password length.

The valid range of values for the passwordMinAge attribute is from zero to 24 855 days. A value of zero (0) indicates that the user can change the password immediately.

The passwords remain in history even if the password history is off. If the password history is turned back on, users cannot reuse the passwords that were in the history before you disabled the password history.

The server does not maintain a password history by default.

By default, the server does not store the password last change time.

Directory Server enforces password and account lockout policies in a replicated environment as follows:

Directory Server replicates password policy information in the directory, such as password age, the account lockout counter, and the expiration warning counter. However, Directory Server does not replicate the configuration information, such as the password syntax and the history of password modifications. Directory Server stores this information locally.

When configuring a password policy in a replicated environment, consider the following points:

When designing the security policy, you need to understand how ACIs are represented in the directory, and what permissions you can set.

Directory ACIs use the following general form:

target permission bind_rule

The ACI variables have the following description:

Therefore, for the directory object target, ACIs allow or deny permission if a bind rule is true.

Permission and a bind rule are set as a pair, and every target can have multiple permission-bind rule pairs. You can set multiple access controls for any given target effectively. For example:

target (permission bind_rule)(permission bind_rule) ...

By default, Directory Server denies access of any kind to all users, with the exception of the Directory Manager. Consequently, you must set ACIs for users to be able to access the directory.

Get effective rights (GER) is an extended ldapsearch command which returns the access control permissions set on each attribute within an entry. With this search, an LDAP client can determine what operations the server access control configuration allows a user to perform.

The access control information is divided into two groups of access: entry rights and attribute rights. Entry rights are the rights, such as modify or delete, that are limited to that specific entry. Attribute rights are the access rights to every instance of that attribute throughout the directory.

Such a detailed access control may be necessary in the following situations:

The following tips can help to lower the administrative burden of managing the directory security model and improve the directory performance characteristics:

Normally, access control rules do not apply to the Directory Manager user. The Directory Manager is defined in the dse.ldif file, not in the regular user database, and ACI targets do not include that user.

The Directory Manager requires a high level of access in order to perform maintenance tasks and to respond to incidents. However, you can grant a certain level of access control to the Directory Manager to prevent unauthorized access or attacks from being performed as the root user.

Use the RootDN Access Control plug-in to sets certain access control rules specific to the Directory Manager user:

You can set only one access control rule for the Directory Manager. It is in the plug-in entry, and it applies to the entire directory.

To decide which type of data the directory will store, ExampleCom creates a deployment team that performs a site survey. The deployment team determines the following key points:

Applications that the ExampleCom directory supports require the userCertificate and uid (userID) attributes. Therefore, the ExampleCom deployment team decides to use the inetOrgPerson object class to represent the entries in the directory because it allows both attributes.

In addition, ExampleCom wants to customize the default directory schema by creating the examplePerson object class to represent employees. This object class is derived from the inetOrgPerson object class. examplePerson allows one exampleID attribute. This attribute contains the special employee number assigned to each employee. In the future, ExampleCom can add new attributes to the examplePerson object class.

Based on the prepared data and schema design, the ExampleCom creates the following directory tree:

Figure 8.1. Directory tree of ExampleCom

The ExampleCom deployment team starts to design the directory database and server topologies.

ExamleCom designs the following database topology:

Figure 8.2. Local enterprise database topology

ExamleCom designs the following server topology:

Figure 8.3. Local enterprise server topology

ExampleCom decides to have the server topology with two supplier servers and three consumer servers. Each of the two suppliers updates all three consumers in the deployment of Directory Server.

The consumers supply data to one messaging server and the other servers. 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 that is responsible for the main copy of the data being modified.

ExampleCom decides to use a multi-supplier replication design to ensure the high availability of its directory data. For more information about multi-supplier replication, see Multi-supplier replication.

Figure 8.4. ExampleCom multi-supplier architecture

Figure 8.5. ExampleCom supplier-consumer architecture

Both supplier servers update the three consumer servers. This ensures that the consumers will not be affected if one of the supplier servers fails.

To protect the directory data, ExampleCom creates the following access control instructions (ACIs):

In addition, ExampleCom decides on the following security measures:

The company makes the following decisions regarding the day-to-day operation of its directory:

ExampleCom International creates a deployment team to perform a site survey. The deployment team determines the following key points from the site survey:

In addition, the data design of the extranet must ensure that the following conditions are fulfilled:

ExampleCom International uses its original schema design and adds two new object classes to support the extranet:

For information about customizing the default directory schema, see Customization of schema.

ExampleCom International creates the following directory tree:

Figure 8.6. Basic directory tree of ExampleCom International

The dc=com suffix is the root of the directory tree. Under this suffix, the company creates the following branches:

The directory tree for the intranet under dc=exampleCom,dc=com has three main branches. Each branch corresponds to one of the regions where ExampleCom International has offices. These branches are identified by using the l (locality) attribute.

Under the dc=exampleNet,dc=com branch, ExampleCom International creates the following branches:

8.2.3.1. Intranet design of ExampleCom International

Copy link

Each branch under dc=exampleCom,dc=com repeats the original directory tree design of ExampleCom from the Directory tree design of the local enterprise example.

Figure 8.7. Directory tree example for intranet

Under each locality, ExampleCom International creates the following branch points:

• ou=people
• ou=groups
• ou=roles
• ou=resources

The entry for the l=Asia locality appears in LDIF as follows:

dn: l=Asia,dc=exampleCom,dc=com
objectclass: top
objectclass: locality
l: Asia
description: includes all sites in Asia

8.2.3.2. Extranet design of ExampleCom International

Copy link

The following diagram shows the directory tree for ExampleCom extranet:

Figure 8.8. Directory tree example for extranet

The ExampleCom International deployment team starts to design the directory database and server topologies.

8.2.4.1. Database topology for ExampleCom International

Copy link

ExampleCom International uses the same topology design for all its localities. However, the Europe locality stores the main copies of the data for the following branches:

• The dc=com root entry
• The intranet under dc=exampleCom,dc=com
• The extranet under dc=exampleNet,dc=com

The following diagram shows the database topology for locality Europe:

Figure 8.9. Database topology for ExampleCom Europe

The l=Europe database stores the main copy of the dc=exampleCom,dc=com and dc=com entries.

Database link 1 and Database link 2 point to databases stored locally in each country. For example, operation requests that ExampleCom Europe server receives for the data under the l=USA branch are chained by a database link to a database on a server in the USA. For more information about database links and chaining, see Using chaining.

The Europe servers contain the main copy of the data for the extranet. The extranet data is stored in three databases the following way:

• Database 1 stores the main copy of the o=suppliers branch.
• Database 2 stores the main copy of the o=partners branch.
• Database 3 stores the main copy of the ou=groups branch.

The following diagram shows the database topology for the extranet:

Figure 8.10. Database topology for ExampleCom International Extranet

8.2.4.2. Server topology for ExampleCom International

Copy link

ExampleCom International develops the following types of server topologies:

• A topology for the corporate intranet. ExampleCom decides to have three data centers, one for each major locality: Europe, the USA, and Asia. Each data center contains the following servers:

  • two supplier servers.
  • two hub servers.
  • three consumer servers.
• A topology for the partner extranet.

The following diagram shows architecture of ExampleCom Europe data center:

Figure 8.11. Server topology for ExampleCom Europe

The Europe data center contains the main copy of the ExampleCom extranet. This data is replicated to two consumer servers in the USA data center and two consumer servers in the Asia data center. Overall, ExampleCom requires ten servers to support the extranet.

The following diagram shows the server architecture of ExampleCom extranet in the Europe data center:

Figure 8.12. Server topology for ExampleCom International extranet

The hub servers replicate the data to two consumer servers of each data center: Europe, the USA, and Asia.

ExampleCom International considers the following points when designing replication for its directory:

The hub servers are located near important directory-enabled applications, such as a mail server or a web server.

To let supplier servers focus on write operations, only hub servers perform replication.

In the future, when ExampleCom expands and needs to add more consumer servers, the additional consumers do not affect the performance of the supplier servers.

For the main copy of its data, each locality uses a multi-supplier replication architecture.

The following diagram shows the multi-supplier architecture for the locality Europe that includes the dc=exampleCom,dc=com and dc=com branches:

Figure 8.13. Multi-supplier architecture for ExampleCom Europe

Each locality contains two suppliers that share main copies of the data for that site. Each locality is responsible for the main copy of its data.

Using a multi-supplier architecture ensures the availability of the data and helps to balance the workload managed by each supplier server.

To reduce the risk of total failure, ExampleCom uses multiple read-write supplier Directory Servers at each site.

The following diagram shows the interaction between two supplier servers in Europe and two supplier servers in the USA:

Figure 8.14. Multi-supplier architecture for ExampleCom Europe and ExampleCom USA

The same relationship exists between ExampleCom USA and ExampleCom Asia and between ExampleCom Europe and ExampleCom Asia.

ExampleCom International uses its previous security design adding the following access controls to support its new multinational intranet:

For more information about macro ACIs, see Using macro access control instructions.

ExampleCom adds the following access controls to support its extranet: