Chapter 7. Updated Packages

download PDF

7.1. 389-ds-base

Updated 389-ds-base packages that fix one security issue, a number of bugs, and add various enhancements are now available for Red Hat Enterprise Linux 6.
The Red Hat Security Response Team has rated this update as having moderate security impact. Common Vulnerability Scoring System (CVSS) base scores, which give detailed severity ratings, are available for each vulnerability from the CVE link(s) associated with each description below.
The 389-ds-base packages provide 389 Directory Server, which is an LDAPv3 compliant server. The base packages include the Lightweight Directory Access Protocol (LDAP) server and command-line utilities for server administration.


The 389-ds-base packages have been upgraded to upstream version 1.2.11, which provides a number of bug fixes and enhancements over the previous version. (BZ#800051)

Security Fixes

A flaw was found in the way 389 Directory Server enforced ACLs after performing an LDAP modify relative distinguished name (modrdn) operation. After modrdn was used to move part of a tree, the ACLs defined on the moved (Distinguished Name) were not properly enforced until the server was restarted. This could allow LDAP users to access information that should be restricted by the defined ACLs.
This issue was discovered by Noriko Hosoi of Red Hat.

Bug Fixes

Previously, 389 Directory Server did not support the Simple Authentication and Security Layer (SASL) PLAIN mechanism. This mechanism has been added to the list of supported SASL mechanisms.
Due to certain changes under the cn=config suffix, when an attribute value was deleted and then added back in the same modify operation, error 53 was returned. Consequently, the configuration could not be reset. This update allows delete operations to succeed if the attribute is added back in the same modify operation and reset the configuration file as expected.
Previously, the script used a connection number equal to 0 (conn=0) as a restart point, which caused the script to return incorrect restart statistics. The underlying source code has been modified and 389 Directory Server is now configured to use connection number equal to 1 (conn=1) as the restart point.
The Windows Sync feature uses the name in a search filter to perform an internal search to find an entry. Parentheses, ( and ) are special characters in the LDAP protocol and therefore must be escaped. However, an attempt to synchronize an entry containing parentheses in the name from an Active Directory (AD) server failed with an error. With this update, 389 Directory Server properly escapes the parentheses and synchronization now proceeds correctly as expected.
When having an entry in a directory server (DS) with the same user name, group name, or both as an entry in AD and simultaneously the entry in AD was out of scope of the Windows Sync feature, the DS entry was deleted. This update adds the new winSyncMoveAction DS attribute for the Windows Sync agreement entry, which allows the user to specify the behavior of out-of-scope AD entries. The value could be set to:
  • none, which means that an out-of-scope AD entry does nothing to the corresponding DS entry;
  • delete, which means that an out-of-scope AD entry deletes the corresponding DS entry;
  • unsync, which means that an out-of-scope AD entry is unsynchronized with the corresponding DS entry and changes made to either entry are not synchronized.
By default, the value is set to none, which fixes this bug.
Due to an incorrect interpretation of an error code, a directory server considered an invalid chaining configuration setting as the disk full error and shut down unexpectedly. This bug has been fixed by using the correct error code and a directory server now no longer terminates due to an invalid chaining of a configuration setting.
Previously, restoring an ldif file from a replica, which had older changes that other servers did not see yet, could lead to these updates not being replicated to other replicas. With this update, 389 Directory Server checks the Change Sequence Numbers (CSNs) and allows the older updates to be replicated. As a result, all replicas remain synchronized.
When a directory server was under a heavy read and write load, and an update request was processed, the following error message or other similar DB_LOCK_DEADLOCK error messages appeared in the error log:
entryrdn-index - _entryrdn_put_data: Adding the parent link (XXX) failed: DB_LOCK_DEADLOCK: Locker killed to resolve a deadlock (-30994)
These errors are common under these circumstances and there is no need to report them in the error log. With this update, 389 Directory Server ensures that these errors are handled properly and no longer logs these messages in the error log.
When a directory server was configured to use multi-master replication and the Entry USN plug-in, the delete operation was not replicated to the other masters. This update modifies the Entry USN plug-in to prevent it from changing the delete operation into a delete tombstone operation, and from removing the operation before it logs into the change log to replay to other servers. As a result, the delete operation is replicated to all servers as expected.
Previously, 389 Directory Server did not refresh its Kerberos cache. Consequently, if a new Kerberos ticket was issued for a host that had already authenticated against a directory server, it would be rejected by this server until it was restarted. With this update, the Kerberos cache is flushed after an authentication failure and 389 Directory Server works as expected in the described scenario.
Using the Managed Entry plug-in in conjunction with other plug-ins, such as Distributed Numeric Assignment (DNA), Member of, and Auto Member, led to problems with delete operations on entries that managed the Managed Entry plug-in. The manager entry was deleted, but the managed entry was not. The deadlock retry handling has been improved so that both entries are deleted during the same database operation.
Previously, replication errors logged in the error log could contain incorrect information. With this update, the replication errors have been modified to be more useful in diagnosing and fixing problems.
When audit logging in a directory server was enabled, LDAP ADD operations were ignored and were not logged. This update removes a regression in the audit log code that caused the ADD operation to be ignored, and LDAP ADD operations are now logged to the audit log as expected.
389 Directory Server with a large number of replication agreements took a considerable amount of time to shut down due to a long sleep interval coded in the replication stop code. This sleep interval has been reduced to speed up the system termination.
Previously, in a SASL map definition, using a compound search filter that included the & character failed because the & character was escaped. The underlying source code has been modified and searching with a filter that includes the & character works as expected.
When 389 Directory Server used the Managed Entry plug-in or the DNA plug-in, the valgrind tool reported memory errors and leaks. With this update, a patch has been applied to prevent these problems, and memory is now used and deleted correctly.
When replication was configured and a conflict occurred, under certain circumstances, an error check did not reveal this conflict, because a to-be-deleted attribute was already deleted by another master. Consequently, the conflict terminated the server. This update improves error checks to prevent replication conflicts from crashing the server.
Previously, internal entries that were in the cache were freed when retrying failed transactions due to a deadlock. This behavior caused problems in a directory server and this server could terminate under a heavy update load. With this update, the cached internal entries are no longer freed and directory servers do not crash in the described scenario.
Due to improper deadlock handling, the database reported an error instead of retrying the transaction. Consequently, under a heavy load, the directory server got deadlock errors when attempting to write to the database. The deadlock handling has been fixed and 389 Directory Server works as expected in such a case.
Internal access control prohibited deleting newly added or modified passwords. This update allows the user to delete any password if they have the modify rights.
Certain operations, other than LDAP Modify operations, can cause the 389 Directory Server to modify internal attributes. For example, a BIND operation can cause updates to password failure counters. In these cases, 389 Directory Server was updating attributes that could only be updated during an explicit LDAP Modify operation, such as the modifyTimestamp attribute. This update adds a new internal flag to skip the update of these attributes on other than Modify operations.
Due to an invalid configuration setup in the Auto Memmber plug-in, the directory server became unresponsive under certain circumstances. With this update, the configuration file is validated, invalid configurations are not allowed, and the server no longer hangs.
When using SNMP monitoring, 389 Directory Server terminated at startup due to multiple ldap servers listed in the ldap-agent.conf file. With this update, the buffer between ldap servers no longer resets and 389 Directory Server starts up regardless of the number of ldap servers listed in the configuration file.
Previously, the dnaNextValue counter was incremented in the pre-operation stage. Consequently, if the operation failed, the counter was still incremented. This bug has been fixed and the dnaNextValue counter is not incremented if the operation fails.
When a replication agreement was added without the LDAP BIND credentials, the replication process failed with a number of errors. With this update, 389 Directory Server validates the replication configuration and ensures that all needed credentials are supplied. As a result, 389 Directory Server rejects invalid replication configuration before attempting to replicate with invalid credentials.
Previously, the script did not grab the correct search base, and as a consequence, the searching statistics were invalid. A new hash has been created to store connections and operation numbers from search operations. As a result, now grabs the correct search base and no longer produces incorrect statistics.
When using the Referential Integrity plug-in, renaming a user DN did not rename the user's DN in the user's groups, unless that case matched exactly. With this update, case-insensitive comparisons or DN normalizations are performed, so that the member attributes are updated when the user is renamed.
Previously, the Attribute Uniqueness plug-in did comparisons of un-normalized values. Consequently, using this plug-in and performing the LDAP RENAME operation on an entry containing one of the attributes which were tested for uniqueness by this plug-in caused the LDAP RENAME operation to fail with the following error:
Constraint Violation - Another entry with the same attribute value already exists.
With this update, Attribute Uniqueness ensures that comparisons are performed between values which were normalized the same way, and LDAP RENAME works as expected in this situation.
When the Referential Integrity plug-in was used with a delay time greater than 0, and the LDAP RENAME operation was performed on a user entry with DN specified by one or more group entries under the scope of the Referential Integrity plug-in, the user entry DN in the group entries did not change. The underlying source code has been modified and LDAP RENAME operations work as expected in the described scenario.
Previously, the DNA plug-in could leak memory in certain cases for certain MODIFY operations. This update applies a patch to fix this bug and the modifications are freed as expected with no memory leaks.
To improve the performance, the entry cache size is supposed to be larger then the primary database size if possible. Previously, 389 Directory Server did not alert the user that the size of the entry cache was too small. Consequently, the user could not notice that the size of the entry cache was too small and that they should enlarge it. With this update, the configured entry cache size and the primary database size are examined, and if the entry cache is too small, a warning is logged in the error log.
Previously, the Memberof plug-in code executed redundant DN normalizations and therefore slowed down the system. The underlying source code has been modified to eliminate redundant DN normalizations.
Previously, the directory server could disallow changes that were made to the nsds5ReplicaStripAttrs attribute using the ldapmodify operation. Consequently, the attribute could only be set manually in the dse.ldif file when the server was shut down. With this update, the user is now able to set the nsds5ReplicaStripAttrs attribute using the ldapmodify operation.
Previously, 389 Directory Server did not check attribute values for the nsds5ReplicaEnabled feature which caused this feature to be disabled. With this update, 389 Directory Server checks if the attribute value for nsds5ReplicaEnabled is valid and reports an error if it is not.
When multi-master replication or database chaining was used with the TLS/SSL protocol, a server using client certificate-based authentication was unable to connect and connection errors appeared in the error log. With this update, the internal TLS/SSL and certificate setup is performed correctly and communication between servers works as expected.
Previously, there was a race condition in the replication code. When two or more suppliers were attempting to update a heavily loaded consumer at the same time, the consumer could, under certain circumstances, switch to total update mode, erase the database, and abort replication with an error. The underlying source code has been modified to prevent the race condition. As a result, the connection is now protected against access from multiple threads and multiple suppliers.
Due to the use of an uninitialized variable, a heavily loaded server processing multiple simultaneous delete operations could terminate unexpectedly under certain circumstances. This update provides a patch that initializes the variable properly and the directory server no longer crashes under these circumstances.
Due to an incorrect attempt to send the cleanallruv task to the Windows WinSync replication agreements, the task became unresponsive. With this update, the WinSync replication agreements are ignored and the cleanallruv task no longer hangs in the described scenario.
Previously, the dirsrv init script always returned 0, even when one or all the defined instances failed to start. This update applies a patch that improves the underlying source code and dirsrv no longer returns 0 if any of the defined instances failed.
The schema reload task reloads schema files in the schema directory. Simultaneously, Directory server has several internal schemas which are not stored in the schema directory. These schemas were lost after the schema reload task was executed. Consequently, adding a posixAccount class failed. With this update, the internal schemas are stashed in a hash table and reloaded with external schemas. As result, adding a posixAccount is successful.
When abandoning a Simple Paged Result request, 389 Directory Server tried to acquire a connection lock twice, and because the connection lock is not self reentrant, 389 Directory Server was waiting for the lock forever and stopped the server. This update provides a patch that eliminates the second lock and 389 Directory Server works as expected in the described scenario.
Previously, Anonymous Resource Limits applied to the Directory Manager. However, the Directory Manager should never have any limits. With this update, Anonymous Resource Limits no longer apply to Directory Manager.
Even if an entry in AD did not contain all the required attributes for the POSIX account entry, the entry was synchronized to the DS as a POSIX entry. Consequently, the synchronization failed due to a missing attribute error. With this update, if an entry does not have all the required attributes, the POSIX account related attributes are dropped and the entry is synchronized as an ordinary entry. As a result, the synchronization is successful.
When enabling replication level logging, the Windows Sync feature prints out what version of Windows or AD it detects. Previously, if the feature detected Windows Server 2003 or later, it printed out the following message:
detected win2k3 peer
This message could be confusing for users who had a later version of Windows, such as Windows Server 2008. This update modifies the message and now the following message is printed out:
detected win2k3 or later peer
When a directory server was under a heavy load, deleting entries using the Entry USN feature caused tombstone entry indexes to be processed incorrectly. Consequently, the server could become unresponsive. This update fixes 389 Directory Server to process tombstone indexes correctly, so that the server no longer hangs in this situation.
Previously, the abandon request checked if the operation to abandon existed. When a search operation was already finished and an operation object had been released, a Simple Page Results request could fail due to this check. This update modifies 389 Directory Server to skip operation existence checking, so that Simple Paged Results requests are always successfully aborted.
Previously, the DNA plug-in attempted to dereference a NULL pointer value for the dnaMagicRegen attribute. Consequently, if DNA was enabled with no dnamagicregen value specified in its configuration and an entry with an attribute that triggered the DNA value generation was added, the server could terminate unexpectedly. This update improves the 389 Directory Server to check for an empty dnamagicregen value before it attempts to dereference this value. As a result, 389 Directory Server no longer crashes if no dnamagicregen attribute is specified.
Previously, the code to check if a new superior entry existed, returned the No such object error only when the operation was requested by the directory manager. Consequently, if an ordinary non-root user attempted to use the modrdn operation to move an entry to a non-existing parent, the server terminated unexpectedly. This update provides a patch that removes the operator condition so that the check returns the No such object error even if the requester is an ordinary user, and the modrdn operation performed to the non-existing parent successfully fails for any user.
aIf a filter contained a range search, the search retrieved one ID per one idl_fetch attribute and merged it to the ID list using the idl_union() function. This process is slow, especially when the range search result size is large. With this update, 389 Directory Server switches to ALLID mode by using the nsslapd-rangelookthroughlimit switch instead of creating a complete ID list. As a result, the range search takes less time.
Previously, if an entry was added or created without plug-in interference, the nsslapd-plugin-track-binddn feature filled the value of the internalModifiersname and internalCreatorsname attributes with the original bind DN instead of the name of the actual plug-in that modified or added the entry. This behavior is undesired; thus the nsslapd-plugin-track-binddn has been modified to always show the name of the actual plug-in that performed these operations.
In previous versions of the 389-ds-base packages, an attempt to add a new entry to the DNA plug-in when the range of values was depleted caused the following error message to be returned:
ipa: ERROR: Operations error: Allocation of a new value for range cn=posix
ids,cn=distributed numeric assignment plugin,cn=plugins,cn=config failed!
Unable to proceed.
This message was missing all additional information in recent versions of the 389-ds-base packages. With this update, a patch is applied to provide the returned error message with additional information.
Previously, an upgrade of the 389-ds-base packages affected configuration files. Consequently, custom configuration files were reverted to by default. This update provides a patch to ensure that custom changes in configuration files are preserved during the upgrade process.


This update allows the PAM Pass-through plug-in to pass through the authentication process to different PAM stacks, based on domain membership or some property of the user entry, or both. Users now can login to Red Hat Directory Server using the credentials and account data from the correct AD server.
This enhancement improves the automember plug-in to check existing entries and writes out the changes which occur if these entries are added.
Previously, certain BINDs could cause only entries with the modifiersname or modifystimestamp attribute to be updated. This behavior led to unnecessary replication traffic. This enhancement introduces the new replication feature to decrease replication traffic caused by BINDs.
This enhancement adds the new Disk Monitoring plug-in. When disk partitions fill up, Disk Monitoring returns a warning.
Previously, two tasks were needed to be performed to clean an entire replication environment, the clean task and the release task. With this update, these tasks are incorporated in the Cleanallruv feature.
Previously, the Paged Results search was allowed to perform only one request per connection. If the user used one connection, multiple Paged Results requests were not supported. This update adds support for multiple Paged Results requests.
With this enhancement, obsolete elements in the Database Replica Update Vector (RUV) can be removed with the CLEANRUV operation, which removes them on a single supplier or master.
This enhancement improves the memberOf plug-in to work across multiple back ends or suffixes.
With this update, the Directory Server schema has been updated with the nsTLS1 attribute to make TLS/SSL configuration easier.
With this update, the Directory Server schema has been updated to include the DNA plug-in attributes.
This enhancement improves the Access Control feature to control the Directory Manager account.
This enhancement adds the ability to execute internal modification operations without changing the operational modifiersname attribute.
With this update, the script has been enhanced with the getopts() function.
Previously, the password lockout process was triggered not when maximum the number of tries was reached, but the time after. This behavior was not consistent with other vendors' LDAP servers. This enhancement adds the new option which allows users to specify the behavior of password lockout.
Previously, DS did not include the SO_KEEPALIVE settings and connections could not be closed properly. This enhancement implements the SO_KEEPALIVE settings to the DS connections.
With this update, the new passwordTrackUpdateTime attribute has been added. This attribute records a timestamp when the password was last changed.
This enhancement adds the new nsds5ReplicaEnabled attribute to the replication agreement. If the replication agreement is disabled, it appears to be removed, but can be easily re-enabled and resumed.
Previously, the Windows Sync plug-in did not support the RFC 2307 and 2307bis types of POSIX schema which supports Windows Active Directory (AD). Under these circumstances, users had to synchronize data between AD and DS manually which could return errors. This enhancement changes the POSIX attributes to prevent these consequences.


Note, that for the initial release, when adding new user and group entries to the DS, the POSIX attributes are not synchronized with AD. Adding new user and group entries to AD synchronizes to DS, and modifying attributes synchronizes both ways.
This enhancement improves the Directory Server schema to allow setting up an access control for the nsslapd-readonly attribute.
All users of 389-ds-base are advised to upgrade to these updated packages, which correct this issue and provide numerous bug fixes and enhancements. After installing this update, the 389 server service will be restarted automatically.
Updated 389-ds-base packages that fix one security issue are now available for Red Hat Enterprise Linux 6.
The Red Hat Security Response Team has rated this update as having important security impact. A Common Vulnerability Scoring System (CVSS) base score, which gives a detailed severity rating, is available from the CVE link associated with the description below.
The 389 Directory Server is an LDAPv3 compliant server. The base packages include the Lightweight Directory Access Protocol (LDAP) server and command-line utilities for server administration.

Security Fix

It was discovered that the 389 Directory Server did not properly handle the receipt of certain MOD operations with a bogus Distinguished Name (DN). A remote, unauthenticated attacker could use this flaw to cause the 389 Directory Server to crash.
All 389-ds-base users are advised to upgrade to these updated packages, which contain a backported patch to correct this issue. After installing this update, the 389 server service will be restarted automatically.
Red Hat logoGithubRedditYoutubeTwitter


Try, buy, & sell


About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

© 2024 Red Hat, Inc.