Being able to assign new entries to groups, automatically, at the time that an account is created ensures that the appropriate policies and functionality are immediately applied to those entries — without requiring administrator intervention.

The Auto Membership Plug-in uses an LDAP search to identify new members for a given static group, and then automatically adds those new entries as members as soon as they are created.

Automembership essentially allows a static group to act similar a dynamic group, at least for adding new members. This can allow administrators to add users to specific user groups, to create special groups for Windows users as part of Windows integration, or to create host groups.

The Auto Membership Plug-in allows sub-filters on results. So, for example, host entries within one IP range could be added to a web servers group while host entries within another IP range could be added to a desktop group, and servers outside either range could be added to a fallback group.

Three tasks allow the Auto Membership Plug-in to run against existing users and update their group memberships:

This can ease group administration as desired membership policies are created or modified.

A new server configuration attribute, nsslapd-minssf-exclude-rootdse, allows security strength factor (SSF) settings to be ignored for queries against the root DSE. This allows clients to access root DSE information which may be required for operations without having to use a secure connection.

The logconv.pl script parses the access log for a Directory Server instance and provides a summary of connections, binds, operations (by type), and error or return codes.

The logconv.pl could return summaries for the entire log or only within a specified time range. New options have been added that show per-minute (-M) or per-second (-m) statistics, in addition to the summary, for the entire log or for the given time range. These per-minute or per-second statistics are exported to a CSV file, which can be imported into other programs for further analysis.

Additionally, summary statistics have been added for three more operation types:

The access log information for some operations types has been enhanced:

The Managed Entries Plug-in uses child configuration entries to define instance-specific managed entries rules. Previously, these configuration entries could not be deleted, which meant that the only way that a managed entries configuration could be disabled was to set the scope to a null setting.

Now, Managed Entries Plug-in configuration entries can be deleted.

PAM pass-through authentication allows a user authenticating to the Directory Server to be authenticated against the system credentials defined in a PAM module. (The authentication request is passed-through to the other identity provider.)

Previously, PAM pass-through authentication was enabled for and defined for the entire directory. Starting in Red Hat Directory Server 9.1, PAM pass-through authentication can be defined for entries within a suffix of the directory, rather than the entire directory.

The entries to which PAM pass-through applies are identified with the pamFilter plug-in attribute in the PAM Pass-Through Authentication Plug-in configuration entry. This allos a search filter which can target a specific user, specific attribute and value, or a suffix in the tree.

Because of the new flexibility in where to apply PAM pass-through authentication rules, the PAM Pass-Through Authentication Plug-in has been enhanced to allow multiple configuration entries. This allows there to be multiple directory filters, mapping methods, and other settings, depending on specific needs within the directory.

Access control instructions are set at different points in the directory tree, at the root suffix, subsuffixes, or even user (leaf) levels. ACIs can also be set on configuration suffixes, such as cn=config. However, with that structure for ACI targets, it was not possible to set any ACI on the Directory Manager user because that is a special user which exists outside the directory tree.

Beginning with this update, there is a new plug-in, RootDN Access Control Plug-in, which defines some access control rules for the root user (Directory Manager) account. This allows restrictions based on time of day and host or IP address of the source machine, for enhanced security.

In previous versions of Directory Server there was no explicit way to disable a replication agreement. The only methods to suspend replication were to change the schedule or to delete the agreement entirely.

The nsds5ReplicaEnabled attribute is introduced in this update, which works as a switch to enable or disable a replication agreement. This allows a master server to be removed from the topology for maintenance or updates without having to completely dismantle the replication configuration for that server.

When a server is removed from the replication topology, the metadata for that server and its update operations (the RUV) still remain on the other servers. Retaining that server and RUV information can create unstable behavior with other master servers in certain situations.

Two new tasks have been introduced for cleaning out lingering RUVs:

These tasks can be initiated by creating a task entry in cn=tasks. Alternatively, the task to remove a dead replica from the RUV of another replica can be initiated by adding an attribute for the task to the second replica entry:

dn: cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config
...
nsds5task: CLEANALLRUVreplicaID

This update to Directory Server introduced a new ldapsearch control which allows credential-less bind attempts to return authentication information about an account.

Most of the time, for the Directory Server to return authentication information about a user account, a client actually binds (or attempts to bind) as that user. And a bind attempt requires some sort of user credentials, usually a password or a certificate. While the Directory Server allows unauthenticated binds and anonymous binds, neither of those binds returns any user account information.

There are some situations where a client requires information about a user account — specifically whether an account should be allowed to authenticate — in order to perform some other operation, but the client either does not have or does use any credentials for the user account in Directory Server. Essentially, the client needs to perform a credential-less yet authenticated bind operation to retrieve the user account information (including password expiration information, if the account has a password).

This can be done through an ldapsearch by passing the Account Usability Extension Control. This control acts as if it performs an authenticated bind operation for a given user and returns the account status for that user, but without actually binding to the server. This allows a client to determine whether that account can be used to log in and then to pass that account information to another application, like PAM.

Previously, any change to an entry updated the modifyTimeStamp operational attribute.

Starting with this update, a new operational attribute, pwdUpdateTime, is used specifically for the last modify time of passwords, separate from the overall entry modify time. This gives password and lockout policies another attribute to evaluate for account inactivity or password expiration.

Tracking the last password change time is enabled in the passwordTrackUpdateTime configuration attribute.

Simple paged results break search results into smaller chunks, with a certain number of results per page, to make it easier to read and browse search results.

This update allows simple paged results (an ldapsearch control) to be combined with server-side sorting on results (another ldapsearch control).

In previous versions of Directory Server, whenever an entry was created or modified, there was an operational attribute added to the entry with the modifying entry's name. However, the creatorsName and modifiersName attributes only showed whatever entry directly edited the entry. If an entry was edited through a plug-in — such as the MemberOf Plug-in updating a user entry when a group entry is edited — then the modifiersName attribute showed the plug-in name — but not the identity of whatever user triggered the plug-in operation.

The new internalModifiersName operational attribute shows the name of whatever Directory Server plug-in performed an operation, while the modifiersName attribute now reflects whatever bound user initiated the operation.

dn: uid=bjensen,ou=people,dc=example,dc=com
...
modifiersname: uid=jsmith,ou=people,dc=example,dc=com
internalModifiersname: cn=memberof plugin,cn=plugins,cn=config

Tracking the bind DN is enabled by setting the nsslapd-plugin-binddn-tracking configuration attribute.

On Linux systems, system users and groups are identified as Posix entries, and LDAP Posix attributes contain that required information. When Windows users are synced over, they have ntUser and ntGroup attributes automatically added which identify them as Windows accounts. However, by default, no Posix attributes are synced over (even if they exist on the Active Directory entry) and no Posix attributes are added on the Directory Server side.

The new Posix Winsync API Plug-in synchronizes Posix attributes set on Active Directory over to the corresponding Directory Server entry.

Initial support for IPv6 addresses was added in Red Hat Directory Server 9.0, but not all directory operations could be performed over IPv6. This update extends IPv6 support to the remaining directory tasks, including replication, installation, chaining databases, and access control instructions.

If the disk space on the system where the Directory Server is running reaches a critical point, the slapd process can crash and, potentially, corrupt the directory database and lose information.

These updates to Directory Server introduce the ability to monitor disk space in the partition or mount point where the slapd process is running. If the disk space reaches an administrator-defined threshold, then the slapd process shuts down gracefully — preserving the database and directory data.

A new set of configuration options, nsslapd-disk-monitoring*, set whether disk monitoring is enabled for the slapd process and the disk space thresholds, grace periods for disk space warnings, and whether to lower logging levels and disable logging before shutting down the server.

There are different ways of interpreting when the maximum password failure (passwordMaxFailure) has been reached. It depends on how the server counts the last failed attempt in the overall failure count.

The traditional behavior for LDAP clients is to assume that the failure occurs after the limit has been reached. So, if the failure limit is set to three, then the lockout happens at the fourth failed attempt. This also means that if the fourth attempt is successful, then the user can authenticate successfully, even though the user technically hit the failure limit. This is basically n+1 on the count.

LDAP clients increasingly expect the maximum failure limit to look at the last failed attempt in the count as the final attempt. So, if the failure limit is set to three, then at the third failure, the account is locked. A fourth attempt, even with the correct credentials, fails. This is n on the count.

A new attribute, passwordLegacyPolicy, is available in Red Hat Directory Server to disable the legacy password policy behavior and allow newer LDAP clients to interact properly with password policies in Directory Server.

Support has been added for the PLAIN mechanism with SASL authentication. While not recommended for most situations, SASL/PLAIN can be useful for anonymous connections or for times when a UID, rather than a DN, is used for authentication.

Previously, the Distributed Number Assignment (DNA) Plug-in was configured in a plug-in entry with the extensibleObject object class. The schema has been enhanced so that there is a new, plug-in specific object class called dnaPluginConfig.

Changes to some attributes may not represent real changes to an entry — such as an automatic change to the modify timestamp attribute from a plug-in, when no other attributes were modified.

To reduce replication load and to improve the performance of some applications, it is beneficial to ignore changes to those attributes when replicating entries. A list of attributes can be configured which can be ignored when the server evaluates entries to enter into the changelog and trigger replication. This list is defined in the nsds5ReplicaStripAttrs attribute on the replication agreement entry.

Previously, both SSL encryption and TLS encryption were set together and defined with the same (SSL-specific) attributes. A new attribute, nsTLS1, has been introduced which enables TLS connections, independently of SSL connections. This allows the stronger TLS protocol to be used and SSL to be disabled.

Previously, the MemberOf Plug-in evaluated group membership based solely on groups and users defined within the local backend. For distributed deployments, this meant that group membership was incompletely evaluated because there could well be identities in a different subsuffix than a group it belongs to.

A new plug-in attribute has been added, memberOfAllBackends, which sets whether the MemberOf Plug-in should evaluate the local suffix only or all subsuffixes for membership information. When set to on, the plug-in evaluates every suffix and backend.

Previously, the nssldap-readonly configuration attribute was not part of the external schema. The read-only setting is used by replication to signal whether the given server can accept modify operations from users (supplier) or whether it can only receive updates from a master server (consumer).

Because the nsslapd-readonly attribute was not public, it could not be used in access control configuration, which meant that it was not possible to grant certain users the appropriate rights to manage replication without making them server administrators.

The nsslapd-readonly attribute has been added to the external schema, so it can now be used to create ACIs.