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.
