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
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:
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:
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?