I didn't see any replies to this, but for the archives, after doing some testing, evidentally there's no way to deploy the password policy module without shutting down everything, updating the configuration, and then bringing it back online.
Even without any active policies defined, the ppolicy overlay starts generating and replicating pwdFailureTime entries, and any replication consumer without the module also loaded breaks and stops replicating. I'm not sure what use it is to maintain pwdFailureTime entries for objects with no actual password policy in place, other than I suppose to retroactively apply a policy that might be added in the future based on historical authentication failures.
On Wed, Apr 23, 2014 at 05:23:28PM -0700, Paul B. Henson wrote:
We are planning to deploy the password policy module to satisfy our security groups requirement for account lockouts (a.k.a., intentionally provided DoS attack vectors <sigh>). I had a couple of questions regarding the deployment I was hoping someone might be kind enough to answer.
Does the password policy module need to be loaded on all of the servers simultaneously, even if there are no password policies defined? We typically stage configuration changes, pulling servers out of the load balancer, updating them, testing them, and then putting them back, such that at no time is service unavailable. The password policy module extends the schema though, and I don't want a server with it loaded potentially trying to replicate unknown attributes to one without it loaded. It's not clear whether simply loading the module would potentially cause this, or if password policy attributes would only be replicated if the module was actually configured with a default policy or if a user had a specifically defined policy. So, would it be safe to stage the initial configuration change loading the module as long as no policies are in place or used (until all of the servers have been updated), or is it required to shut down all of the servers simultaneously to make the change?
We are only planning to avail of account lockouts, not any of the other functionality of the module. As such, unless I misunderstand, the following policy should enable lockouts but not apply any of the other restrictions:
dn: cn=default,ou=policies,dc=example,dc=com cn: default objectClass: pwdPolicy pwdAttribute: userPassword pwdLockout: TRUE pwdLockoutDuration: 1800 pwdMaxFailure: 100 pwdFailureCountInterval: 300
This would be the default policy. We also have some number of service accounts which we would not want subject to lockouts, if I understand correctly, configuring those accounts with an explicit password policy pwdPolicySubentry like this:
dn: cn=serviceaccount,ou=policies,dc=example,dc=com cn: default objectClass: pwdPolicy pwdAttribute: userPassword
Should leave them with no restrictions?
Finally, there is a requirement for the helpdesk to be able to manually unlock a locked out account. For an account that is currently locked out, would deleting the pwdAccountLockedTime and pwdFailureTime attributes reset it to a normal state?
Thanks much.