2. New in Red Hat Directory Server 9.0

Directory Server 9.0 has introduced many features to make managing the directory service and its data easier.

2.1. New: Renaming Subtrees and Moving to a New Parent

Every distinguished name is comprised of a series of name elements that indicate the place of the entry within the directory tree. The far left element, the relative DN or RDN, is the entry's own name. The other elements identify the ancestors of the entry.
In previous releases of Directory Server, it was possible to rename leaf or terminal entries; that is, entries without children. This is a modrdn operation. However, it was not possible to rename a parent entry, which would subsequently end up "moving" all its children in the directory tree. Directory Server 9.0 introduces subtree rename operations. This allows parent entries to be renamed through a modrdn operation, and all their children are subsequently updated to maintain the directory structure. Subtree renames can also be disabled to prevent changing the directory tree.
Additionally, Directory Server now supports moving a leaf entry to a new parent, a moddn operation with a new superior.
With the combination of subtree rename and moddn with a new superior, Directory Server provides full support of the modify DN operations specified in RFC 4511.
For more information on subtree rename operations, see the 9.0 Administrator's Guide.

2.2. New: Introducing the Managed Entries Plug-in to Create Pairs of Entries

There are situations when one entry is created and there should automatically be a corresponding second entry with related attribute values. For example, when a Posix user is created, a corresponding Posix group entry should also be created.
The Managed Entries Plug-in identifies an origin entry target. When an entry is created in that scope, matching the given attributes, it automatically generates a new, managed entry.
For more information on the Managed Entries Plug-in, see the 9.0 Administrator's Guide.

2.3. New: Introducing the Account Policy Plug-in to Define Time-Based Account Inactivation

Account policies can already be set based on failed password attempts or by an administrator manually. The new Account Policy Plug-in in Directory Server 9.0 allows administrators to set time-based account lockout policies.
The Account Policy Plug-in can configure natural timeout periods for accounts based on activity (assessed by the last login time) or by the account age (based on the account creation time).
For more information on the Account Policy Plug-in, see the 9.0 Administrator's Guide.

2.4. Enhanced: 20-Way Multi-Master Replication

In previous versions of Red Hat Directory Server, multi-master replication was supported with up to four masters in a single replication topology. In 9.0, it is possible to have up to 20 masters in a replication topology.

2.5. Enhancement: Separate Resource Limits for Simple Paged Results

Resource limits set limits on searches, based on things like the number of results returned, the time of searches, and the number of entries checked. Resource limits can be applied to a user or to the entire directory.
Beginning in Directory Server 8.2, Directory Server supports simple paged searches, which returns paged results (chunks of the search results at a time, rather than altogether). Because the performance is better with paged searches, Directory Server 9.0 introduces new attributes to set different resource limits for paged searches and standard searches. This allows administrators to set higher resource limits for paged searches (improving user experience) while keeping the lower resource limits for regular searches (maintaining performance).
For more information on resource limits and paged searches, see the 9.0 Administrator's Guide.

2.6. New: Attributes for Samba Interoperability with the Retro Changelog

Two new attributes, isreplicate and nsslapd-attribute, have been added to the Retro Changelog Plug-in to better integrate Directory Server with other applications, like Samba. The nsslapd-attribute attribute explicitly includes Directory Server attributes in the retro changelog entries; this enables operational attributes (normally excluded from replication) to be included in changelog entries and available to other servers.

2.7. Enhanced: Added Global Entry USN Count

Beginning in Directory Server 8.2, changes to entries were tracked on the local database using a local update sequence number. Whenever a change was made anywhere in the database, the counter was incremented up and the entryusn attribute on the entry was updated.
In Directory Server 9.0, USNs can be maintained not only on the local database, but across all databases in the directory if the USN Plug-in is set to global mode.

2.8. Enhanced: DNA Plug-in Handles Multiple Attributes in Same Range

The Distributed Numeric Assignment (DNA) Plug-in assigns unique numbers, from within a given range, automatically to given entries. In 8.2, the DNA Plug-in assigned those numbers to a single attribute type; starting in 9.0, the DNA Plug-in can assign numbers from the same range to multiple attribute types.
This allows the same number to be assigned to different attributes. For example, the DNA Plug-in can assign the same value to the uidNumber and gidNumber attributes

2.9. Enhanced: Added Option to Have Separate Fractional Replication List for Total Updates

Fractional replication allows specific attributes to be excluded from replication updates.
Directory Server 9.0 introduces a new attribute, nsDS5ReplicatedAttributeListTotal, which sets a second list of attributes to exclude from replication, specifically from a total update. This allows different attributes to be excluded from a regular, incremental update than a total update. Very large attributes — like certificates or binary attributes — can be excluded from a regular update, but included in total updates when data consistency is more important than performance.


Using different fractional replication lists for incremental and total updates is strongly recommended if you use the memberof plug-in. memberOf fixup tasks are run after every replication update, and this causes negatively affects server performance.
Limiting the memberof attribute to being replicated only for total updates improves the performance of replica initialization and replication.
For more information on incremental updates, total updates, and fractional replication, see the 9.0 Administrator's Guide.

2.10. Enhanced: New Options and Procedures to Set up Secure Connections

Directory Server allows secure connections to be set between servers and between servers and clients using SSL, TLS, Start TLS, or SASL. Directory Server 9.0 introduces some new options to refine what kinds of secure connections are allowed and to administer secure connections more easily:
  • Procedures have been added to allow administrators how to disable selected SASL mechanisms.
  • Procedures have been added to disable SSLv3 and require TLS connections only.
  • A new attribute has been added to allow the Directory Server to be restarted with an expired certificate. This means that the server can still run and operate until the expired certificate is replaced.

2.11. New: Added Support for the CoS merge-schemes Qualifier

A class of service adds and updates an attribute in an entry based on changes in an identified template entry. Normally, when a change is made to the CoS attribute, the new value overwrites any previous attribute in the entry. The new merge-schemes qualifier for CoS definitions tells the CoS to add attributes and allow multiple values, rather than replacing attributes when the CoS changes.

2.12. New: Added SELinux Policies

SELinux is a security function in Linux that categorizes files, directories, ports, processes, users, and other objects on the server. New policies have been written for Directory Server files, directories, and ports. In 9.0, Directory Server can run with SELinux set to enforcing mode and operate normally.
The 9.0 Administrator's Guide has information on the default Directory Server policies and simple procedures for changing and updating these policies. More detail about SELinux and Red Hat Enterprise Linux is covered in the SELinux Guide.

2.13. New: Replication Session Hooks

Client applications can have some control over replication operations by using custom plug-ins that define replication session hooks. Suppliers and consumers can send each other some limited information. If both servers meet the required session settings in the plug-in (like using the same Directory Server version), then replication proceeds; if not, it fails.
The new replication callbacks are detailed in the Plug-in Programmer's Guide.