Re: deploying password policy module

["Paul B. Henson" <henson@acm.org>]

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.
> 
>