Cause: A failed SASL bind operation, and Account Lockout enabled
Consequence: The Root DSE entry gets incorrectly updated with passwordRetryCount
Fix: Do not update the Account Lockout settings when the failed bind is a SASL bind
Result: The root DSE entry is not modified when a SASL bind fails.
This bug is created as a clone of upstream ticket:
When a SASL bind fails, the target DN is not set. If password policy account lockout is configured, it attempts to update the password retry count on the dn ("") - which is the Root DSE entry, not a user entry.
This also confuses the COS plugin, and it incorrectly triggers a COS cache rebuild after the failed login.
 Setup DS
 Enable Account lockout
 Attempt a SASL BInd (this is expected to fail)
ldapsearch -h <host> -p <port> -b "dc=example,dc=com" -v -LLL -Y GSSAPI "uid=*" dn
 Check the root DSE entry for passwordRetryCount:
ldapsearch -b "" -s base -xLLL passwordRetryCount=* passwordRetryCount
 If the entry is NOT returned, the fix is verified
Executed ticket47970 ticket from lib389 and the test passed. Hence, marking the bug as Verified.
[root@cloud-qe-14 dirsrvtests]# rpm -qa |grep -i 389-ds-base
Few lines from Py.test...
DEBUG:lib389:Retrieving entry with [('cn=config,cn=ldbm database,cn=plugins,cn=config',)]
INFO:lib389:Retrieved entry [dn: cn=config,cn=ldbm database,cn=plugins,cn=config
INFO:ticket47970_test:Testing Ticket 47970 - Testing that a failed SASL bind does not trigger account lockout
INFO:ticket47970_test:account lockout enabled.
INFO:ticket47970_test:SASL Bind failed as expected
INFO:ticket47970_test:Root DSE was correctly not updated
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory, and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.