An admin account is allowed to write userPassword attributes, and is assigned the password-reset privilege via a collective attribute subentry. (See the attached LDIF file for details) The admin account's password policy is set to update the entry's last-login-time-attribute, set up by following the admin guide.
Run one modrate to change a bunch of userPasswords randomly:
Note 20 connections are being used.
After a while, start an identical modrate in another shell. The connections in the first modrate immediately start to fail:
The second modrate's connections continue working fine. After killing the second modrate, the first modrate's connections continue to fail.
I suspect this may be caused by the org.opends.server.core.AuthenticatedUsers.postResponse(ModifyOperation) method, which is getting called on the first modrate's connections when the second modrate's connections bind and update the admin account's entry. This method iterates through all the client connections authenticated as the admin account, and calls conn.updateAuthenticationInfo(oldEntry, newEntry) on each one.
The postResponse()/updateAuthenticationInfo() methods do not have access to the entry's virtual attributes, so are effectively dropping all the privileges.