Ryan Steele wrote:

Actually, it would appear I'm hitting the same problem as the OP in this thread:

http://markmail.org/message/fhfhzy5uehh6e4us#query:openldap chain "modifications require authentication"+page:1+mid:fhfhzy5uehh6e4us+state:results

I say that because when I get prompted for authentication by the slave (instead of having the referral handled server-side), I see this corresponding entry in the master's logs:

May 4 12:22:43 ldap1 slapd[8794]: conn=226810 fd=50 ACCEPT from IP=10.x.x.x:45081 (IP=0.0.0.0:389) May 4 12:22:43 ldap1 slapd[8794]: conn=226810 op=0 BIND dn="" method=128 May 4 12:22:43 ldap1 slapd[8794]: conn=226810 op=0 RESULT tag=97 err=0 text= May 4 12:22:43 ldap1 slapd[8794]: conn=226810 op=1 MOD dn="uid=ryans,ou=Users,dc=example,dc=com" May 4 12:22:43 ldap1 slapd[8794]: conn=226810 op=1 MOD attr=displayColor May 4 12:22:43 ldap1 slapd[8794]: conn=226810 op=1 RESULT tag=103 err=8 text=modifications require authentication May 4 12:22:43 ldap1 slapd[8794]: conn=226810 op=2 UNBIND May 4 12:22:43 ldap1 slapd[8794]: conn=226810 fd=50 closed

So, it looks like the DN is not being passed through for some reason. Still working on trying to track it down...

The same issue affects ldappasswd (it refuses to change the passwd because it thinks the user has not bound to the directory), so it's not just third party utilities. It really does appear as though the chain overlay is stripping the DN before sending the request out to the master, because the logs seem to indicate that the request makes it to the master and fails because there is no DN before a referral is presented to the client that initially sent the update to the slave. I added the 'ACL' loglevel to what I already use ('stats' and 'sync'), just to confirm that it is wasn't being denied by ACL's or anything like that.

I do see references to the 'authzFrom' and 'authzTo' attributes in the admin guide's section on chaining, and on the FAQ (http://www.openldap.org/faq/data/cache/1425.html), but the example in test022-ppolicy does not use them, so I would not think that they are required or causing this problem. In any case, I did add olcDbIDAssertAuthzFrom: {0}"*" to the slaves (as the FAQ says) just to be absolutely sure, but it made no difference.

I initially thought that the uncommenting of that check was responsible for this behavior, but the followup I sent just prior to this has a link to an OpenLDAP mailing list thread that was made in February, well before these changes that you made, Pierangelo. In either case, the behavior is broken. Exactly where, I'm still trying to figure out, but would definitely appreciate any input from more seasoned OpenLDAP developers.