Re: ppolicy and sync replication

[Howard Chu <hyc@symas.com>]

Craig Squires wrote:
> This is a followup to a thread from a couple of months ago. The issue is
> interaction between ppolicy and syncrepl overlays. The message I want to
> start at is:

There is no "syncrepl overlay". (Possibly there should be, but that work 
got stalled.) The syncrepl consumer is intrinsic to slapd, not a 
separate overlay.

> http://www.openldap.org/lists/openldap-software/200701/msg00131.html
>
> which didn't get a direct reply. Here's a quote of the relevant context:
>
> > From: Sadique Puthen <xenguy@gmail.com>
> >
> > I did a bit more testing about this.
> >
> > I set up password policy as below. Only relevant part given.
> >
> > pwdLockout: TRUE
> > pwdMaxFailure: 3
> > pwdLockoutDuration: 90
> >
> > 1 - I did bind to the master server 3 times using wrong password. I
> > failed to bind using the right password after that and failed. 
> > Expected
> > 2- I did bind to the consumer server using the right password. 
> > Failed. Expected.
>
> I note that in my experience, for this to work the "overlay ppolicy"
> statement in the consumer's slapd.conf must precede the "overlay
> syncrepl" statement. Without that, the consumer doesn't seem to respect
> the account lock.

This statement makes no sense, since there is no syncrepl overlay for 
the consumer.

> > After 90 seconds everything works fine.
>
> At this point I'm having some further problems:
>
> 2a- I bind with the right password on the consumer after the lockout
> duration and the pwdFailureTime and pwdAccountLockedTime attributes
> are deleted on the consumer, as expected. However, related to Sadique's
> next step, those attributes still exist on the provider because
> obviously no info gets pushed back from the consumer. This isn't
> necessarily a problem for me, but the following is:
>
> 2b- I bind with the right password on the provider after the lockout
> duration and the attributes are now deleted there. But the consumer
> now crashes and is not recoverable. Oddly, if I bind incorrectly on
> the provider first and then bind correctly the crash does not occur.
> With the new incorrect bind after the lockout duration the
> pwdAccountLockedTime attribute is deleted while the old pwdFailureTime
> attributes are not. They are deleted with the following correct bind. So
> there's something specific about the LockedTime attr that's at issue.

> I'm running 2.3.34 on RHEL AS4 (both provider and consumer) using Buchan
> Milne's RPMs (thanks Buchan!!). The same issue existed in 2.3.31. I
> should also note that I'm doing delta syncrepl... and haven't tried this
> with regular syncrepl. I've noticed asides at a couple of places in the
> archives that suggest that at least some ppolicy related attrs aren't
> supposed to be replicated, yet there's some suggestion at others that
> they are. In particular, Pierangelo Masarati states, in a reply to the
> original message from Sadique, that: "In general, ppolicy related 
> state values are not replicated; each replica is on its own as far as 
> state-related attributes in enforcing password policy. [...]"

I think you're running into the same crash I found in ITS#4904, fixed 
yesterday. The fix will be in 2.3.35. Since it's only a one-line fix, 
you can easily patch your 2.3.34 source if you need it right away.

> [here's the rest of Sadique's message]
> > 3- I did bind to the consumer server using the wrong password three 
> > times. I failed to bind to the consumer using the right password 
> > after that. Failed. Expected
> > 4 - I did bind to the master server using the right password. 
> > Success. Not expected before elapsing 90 seconds.
> >
> > I know the consumer server is not supposed to update the master 
> > server database, but is there any work around? Does openldap support 
> > multi master replication? Is this a limitation. Does this mean a 
> > client locked on consumer server - as set by the policy - would be 
> > able to bind to the master server overriding the policy.

I guess it would be possible to arrange for the consumer to chain the 
ppolicy updates back to the master. I haven't tried that. OpenLDAP 2.4 
has multimaster support so that would be another possibility. We 
probably should have a config keyword to govern that behavior. In very 
widely distributed directories it doesn't make sense to replicate login 
events in one corner of the world to every other installation.

> Cheers, Craig

--
  -- Howard Chu
  Chief Architect, Symas Corp.  http://www.symas.com
  Director, Highland Sun        http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP     http://www.openldap.org/project/