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.

From: Michael Ströder Sent: Sunday, April 27, 2014 11:27 PM Sometimes it's handy to see when people had failed logins even if you

apply lockout policy.

You simply should not load slapo-ppolicy without also loading its schema.

From: Michael Ströder Sent: Monday, April 28, 2014 11:50 PM 1. If HA is important you surely have more than one replica and a decent fail-over mechanism.

2. Loading slapo-ppolicy and the schema file in one restart is trivial.

Sorry. I don't see the problem.

From: Michael Ströder Sent: Tuesday, April 29, 2014 12:50 PM AFAICS nothing prevents you from loading the schema first on all replicas. And after that load the overlay.

Paul B. Henson wrote: >> From: Michael Ströder >> Sent: Tuesday, April 29, 2014 12:50 PM >> >> AFAICS nothing prevents you from loading the schema first on all replicas. >> And after that load the overlay. > > The attribute in question is not defined in the external schema, in fact, it > is commented out: Ah, sorry. Missed that.

> From: Michael Ströder > Sent: Friday, May 02, 2014 4:21 AM > > If just add "moduleload ppolicy" to your slapd.conf (or similar action for [...] > In a second step you have to add "overlay ppolicy" to the database section Sweet, I never considered loading the module but not using it. Thanks much for the follow-up and suggestion, I think that will allow me to stage the deployment as I wanted without any downtime. > all replicas, also one after the other. The replication will catch up even > though some prior modifications might have failed in the past. Will there be any failures? After step one, all of the replicas should have the schema loaded. As you start migrating servers to step two, they will start generating and trying to replicate the attribute. As the other servers already know about the attribute, wouldn't the replication succeed, although at that point there would be nothing on that particular server paying any attention to it?

Paul B. Henson wrote: >> From: Michael Ströder >> Sent: Friday, May 02, 2014 4:21 AM >> >> If just add "moduleload ppolicy" to your slapd.conf (or similar action for > [...] >> In a second step you have to add "overlay ppolicy" to the database section > > Sweet, I never considered loading the module but not using it. Thanks much > for the follow-up and suggestion, I think that will allow me to stage the > deployment as I wanted without any downtime. > >> all replicas, also one after the other. The replication will catch up even >> though some prior modifications might have failed in the past. > > Will there be any failures? After step one, all of the replicas should have > the schema loaded. As you start migrating servers to step two, they will > start generating and trying to replicate the attribute. As the other servers > already know about the attribute, wouldn't the replication succeed, although > at that point there would be nothing on that particular server paying any > attention to it? In my test setup 1. provider has slapo-ppolicy fully configured in the database section but 2. provider does not have it. The attribute is replicated. BTW: AFAIK write operations to 'pwdFailureTime' are normally not replicated. But with normal syncrepl mode attribute 'pwdFailureTime' will get replicated if there's a change to another attribute. Maybe one could mitigate this by setting parameter 'attrs' to not include all operational attributes. But I would not recommend doing so.

> From: Michael Ströder > BTW: AFAIK write operations to 'pwdFailureTime' are normally not > replicated. Hmm, in my initial testing, it seemed to be.

Account lockout wouldn't be nearly as useful if the failures were not synchronized across all of the servers and the settings were applied separately on each one. (Well, arguably account lockout is not useful in general :),

but as a checkbox on an audit form it would be less useful if the failures weren't synchronized).