I've never configured this kind of architecture, but as far as I know the ppolicy, I think my first thought configuring this would have been to not rebind as user because the attribute modified is an operational one which need the manage right (not sure about that)

So I should have configured this with the replication user with manage right and without rebinding as a user when chaining to the master.

Hope this help

On Thu, Mar 20, 2014 at 6:14 PM, Brad dameron serpent6877@hotmail.comwrote:

I understand what you are saying. But this is what the ppolicy_forward_updates says:

ppolicy_forward_updates Specify that policy state changes that result from Bind operations (such as recording failures, lockout, etc.) on a consumer should be forwarded to a master instead of being written directly into the consumer’s local database. This setting is only use‐ ful on a replication consumer, and also requires the updateref setting and chain overlay to be appropriately configured.

So when a password failure occurs "pwdFailureTime" it relays it to the master as the user doing a MOD from what I have seen in my logs. And thus the user doesn't have access to modify this attribute.

Brad

---

Date: Thu, 20 Mar 2014 12:13:02 +0100 Subject: Re: Slave not able to update master pwdFailureTime via chain. From: esteban.pereira@gepsit.fr To: serpent6877@hotmail.com CC: openldap-technical@openldap.org

Hi Brad,

pwdFailureTime is an operational attribute, I don't think any user can modify it on any instance. May be you should try to modify it on the master to see if it comes from this assumption.

Esteban

On Thu, Mar 20, 2014 at 11:33 AM, Brad dameron serpent6877@hotmail.comwrote:

OpenLDAP 2.4.23-26 on CentOS 5. I am trying to get the pwdFailureTime updated on the master when the slave recieves a password failure. Here is my config. It's pretty simple and basic. No TLS.

Master:

access to attrs=userPassword by group.exact="cn=ldapadmins,ou=Groups,dc=test,dc=net" write by dn.exact="cn=replication,dc=test,dc=net" read by self write by anonymous auth by * none access to * by group.exact="cn=ldapadmins,ou=Groups,dc=test,dc=net" write by dn.exact="cn=replication,dc=test,dc=net" write by self write by users read by anonymous read by * none

Slave:

overlay chain chain-uri ldap://172.16.0.84:389 chain-rebind-as-user TRUE chain-idassert-bind bindmethod=simple binddn="cn=replication,dc=test,dc=net" credentials="MyPasswd" mode="self" chain-return-error TRUE

# Password Policy overlay ppolicy ppolicy_default "cn=default,ou=Policies,dc=test,dc=net ppolicy_use_lockout ppolicy_forward_updates

# Slave Replication syncrepl rid=101 provider=ldap://172.16.0.84:389 type=refreshAndPersist interval=00:00:01:00 retry="60 10 300 +" searchbase="dc=test,dc=net" schemachecking=off bindmethod=simple binddn="cn=replication,dc=test,dc=net" credentials="MyPasswd" updateref "ldap://172.16.0.84:389"

I see the connection on the master but it gives a permission error:

Mar 20 09:47:46 LDAP-RADIUS-1 slapd[14288]: conn=1124 op=3 MOD dn="cn=testuser,ou=People,dc=test,dc=net" Mar 20 09:47:46 LDAP-RADIUS-1 slapd[14288]: conn=1124 op=3 MOD attr=pwdFailureTime Mar 20 09:47:46 LDAP-RADIUS-1 slapd[14288]: conn=1124 op=3 RESULT tag=103 err=50 text=

I read that you maybe need authzTo added to the binddn for the chain? Or is this only for TLS?

I tried adding this ldif:

dn: cn=replication,dc=test,dc=net changetype: modify add: authzTo authzTo: *

And even set the:

chain-idassert-authzFrom "*"

in the chain. But it always gives me the error code 50 not enough permissions. I believe it is supposed to give access to the user to MOD the pwdFailureTime tribute knowing it is coming from a relay. But I can't find very specific docs on this or see what is wrong. Any help apreciated.

Thanks, Brad