389 Directory Server is an LDAP version 3 (LDAPv3) compliant server. The base packages include the Lightweight Directory Access Protocol (LDAP) server and command-line utilities for server administration.
Security Fix(es):
* A flaw was found in the way 389-ds-base handled authentication attempts against locked accounts. A remote attacker could potentially use this flaw to continue password brute-forcing attacks against LDAP accounts, thereby bypassing the protection offered by the directory server's password lockout policy. (CVE-2017-7551)
Bug Fix(es):
* In a multi-replication environments, if operations in one back end triggered updates in another back end, the Replica Update Vector (RUV) of the back end was incorrect and replication failed. This fix enables Directory Server to handle Change Sequence Number (CSN) pending lists across multiple back ends. As a result, replication works correctly. (BZ#1476161)
* Due to a low default entry cache size value, the Directory Server database had to resolve many deadlocks during resource-intensive tasks. In certain situations, this could result in a "DB PANIC" error and the server no longer responded to requests. After the server was restarted, Directory Server started with a delay to recover the database. However, this recovery could fail, and the database could corrupt. This patch increases the default entry cache size in the nsslapd-cachememsize parameter to 200 MB. As a result, out-of-lock situations or "DB PANIC" errors no longer occur in the mentioned scenario. (BZ#1476162)
* Previously, if replication was enabled and a changelog file existed, performing a backup on this master server failed. This update sets the internal options for correctly copying a file. As a result, creating a backup now succeeds in the mentioned scenario. (BZ#1479755)
* In certain situations, if the server was previously abruptly shut down, the /etc/dirsrv/<instance_name>/dse.ldif configuration file became corrupted. As a consequence, Directory Server failed to start. With this patch, the server now calls the fsync() function before shutting down to force the file system to write any changes to the disk. As a result, the configuration no longer becomes corrupted, regardless how the server gets stopped. (BZ#1479757)
Create Date: 2017-09-05 Last Update Date: 2017-09-05