I made an important discovery this morning (with a fresh set of eyes...):
without Pierangelo's patch, chaining does
*NOT* work, as originally stated. So, the patch does fix the broken test that
started this ITS, making it both valid
and absolutely necessary, but alas, the functionality of the chaining
configuration is the same with both the patched
and unpatched package: the DN is not being passed through, so the automatic
chasing of the referral does not work.
Here is an example with ldapvi:
### Command issued on slave to change one attribute of user
uid=ryans,ou=Users,dc=example,dc=com
ry...@slave:~# ldapvi --ldap-conf --starttls -h localhost --bind=simple -D
cn=admin,dc=example,dc=com -w `cat
/etc/ldap.secret` --discover
159 entries read
add: 0, rename: 0, modify: 1, delete: 0
Action? [yYqQvVebB*rsf+?] y
Received referral to
ldap://ldapmaster.example.com/uid=ryans,ou=Users,dc=example,dc=com.
You are not logged in to ldap://ldapmaster.example.com:389 yet.
Type '!' or 'y' to do so.
Rebind? [y!nB*qQ?]
### Logs on slave generated by ldapvi command
May 5 10:27:04 slave slapd[30408]: conn=44 fd=41 ACCEPT from
IP=127.0.0.1:34118 (IP=0.0.0.0:389)
May 5 10:27:04 slave slapd[30408]: conn=44 op=0 EXT oid=1.3.6.1.4.1.1466.20037
May 5 10:27:04 slave slapd[30408]: conn=44 op=0 STARTTLS
May 5 10:27:04 slave slapd[30408]: conn=44 op=0 RESULT oid= err=0 text=
May 5 10:27:04 slave slapd[30408]: conn=44 fd=41 TLS established tls_ssf=128
ssf=128
May 5 10:27:04 slave slapd[30408]: conn=44 op=1 BIND
dn="cn=admin,dc=example,dc=com" method=128
May 5 10:27:04 slave slapd[30408]: conn=44 op=1 BIND
dn="cn=admin,dc=example,dc=com" mech=SIMPLE ssf=0
May 5 10:27:04 slave slapd[30408]: conn=44 op=1 RESULT tag=97 err=0 text=
May 5 10:27:04 slave slapd[30408]: conn=44 op=2 SRCH base="" scope=0 deref=0
filter="(objectClass=*)"
May 5 10:27:04 slave slapd[30408]: conn=44 op=2 SRCH attr=+ *
May 5 10:27:04 slave slapd[30408]: conn=44 op=2 ENTRY dn=""
May 5 10:27:04 slave slapd[30408]: conn=44 op=2 SEARCH RESULT tag=101 err=0
nentries=1 text=
May 5 10:27:04 slave slapd[30408]: conn=44 op=3 SRCH base="dc=example,dc=com"
scope=2 deref=0 filter="(objectClass=*)"
May 5 10:27:04 slave slapd[30408]: conn=44 op=3 ENTRY dn="dc=example,dc=com"
May 5 10:27:04 slave slapd[30408]: conn=44 op=3 ENTRY
dn="cn=admin,dc=example,dc=com"
May 5 10:27:04 slave slapd[30408]: conn=44 op=3 ENTRY
dn="ou=users,dc=example,dc=com"
May 5 10:27:04 slave slapd[30408]: conn=44 op=3 ENTRY
dn="ou=groups,dc=example,dc=com"
May 5 10:27:04 slave slapd[30408]: conn=44 op=3 ENTRY
dn="uid=xxxxx,ou=users,dc=example,dc=com"
May 5 10:27:04 slave slapd[30408]: conn=44 op=3 ENTRY
dn="uid=ryans,ou=users,dc=example,dc=com"
May 5 10:27:04 slave slapd[30408]: conn=44 op=3 ENTRY
dn="uid=xxxxx,ou=users,dc=example,dc=com"
May 5 10:27:04 slave slapd[30408]: conn=44 op=3 ENTRY
dn="cn=xxxxx,ou=groups,dc=example,dc=com"
May 5 10:27:04 slave slapd[30408]: conn=44 op=3 ENTRY
dn="cn=ryans,ou=groups,dc=example,dc=com"
May 5 10:27:04 slave slapd[30408]: conn=44 op=3 ENTRY
dn="cn=xxxxxx,ou=groups,dc=example,dc=com"
May 5 10:27:04 slave slapd[30408]: conn=44 op=3 SEARCH RESULT tag=101 err=0
nentries=159 text=
May 5 10:27:22 slave slapd[30408]: conn=44 op=4 MOD
dn="uid=ryans,ou=Users,dc=example,dc=com"
May 5 10:27:22 slave slapd[30408]: conn=44 op=4 MOD attr=displayColor
May 5 10:27:22 slave slapd[30408]: conn=44 op=4 RESULT tag=103 err=10 text=
The referral is generated (err=10), and sent to the master, and here's what the
logs there look like:
### Logs on master generated by referral
May 5 10:43:04 ldap1 slapd[8794]: conn=402475 fd=273 ACCEPT from
IP=10.0.1.196:43376 (IP=0.0.0.0:389)
May 5 10:43:04 ldap1 slapd[8794]: conn=402475 op=0 BIND dn="" method=128
May 5 10:43:04 ldap1 slapd[8794]: conn=402475 op=0 RESULT tag=97 err=0 text=
May 5 10:43:04 ldap1 slapd[8794]: conn=402475 op=1 MOD
dn="uid=ryans,ou=Users,dc=example,dc=com"
May 5 10:43:04 ldap1 slapd[8794]: conn=402475 op=1 MOD attr=displayColor
May 5 10:43:04 ldap1 slapd[8794]: conn=402475 op=1 RESULT tag=103 err=8
text=modifications require authentication
May 5 10:43:04 ldap1 slapd[8794]: conn=402475 op=2 UNBIND
May 5 10:43:04 ldap1 slapd[8794]: conn=402475 fd=273 closed
May 5 10:43:04 ldap1 slapd[8794]: conn=402476 fd=273 ACCEPT from
IP=10.0.1.196:43377 (IP=0.0.0.0:389)
As you can see, the DN is empty. It might be worth mentioning that I have
tried the olcDbURI with dotted-quads,
hostnames, and with and without quotes, and the value portions of the
attr=value pairs in the olcDbIDAssertBind
attribute with and without quotes, to no avail, though I did not expect it to.
I have also tried with and without TLS
(my configuration supports both) in the chaining configuration, and explicitly
with olcDbChaseReferrals set to TRUE,
though that should be the default. I've also tried with and without proxy
authz (authzTo/authzFrom) in a vain attempt
to get this working, as is mentioned above in this ITS (because it is
referenced in the Admin Guide section on
chaining), but that too failed.
However, most of this would seem unnecessary since test022-ppolicy does almost
none of them, although that test was
recently patched to detect the bug fixed by Pierangelo's patch so it may not be
an ironclad example. But since there's
no other officially documented example of setting up chaining with cn=config,
it's really all the community has to go
on. Again, for reference, the most recent configuration used is provided below:
1 cn=module{0},cn=config
objectClass: olcModuleList
cn: module{0}
olcModulePath: /usr/lib/ldap
olcModuleLoad: {0}back_hdb.la
olcModuleLoad: {1}autogroup.la
olcModuleLoad: {2}back_ldap.la
20 olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config
objectClass: olcOverlayConfig
objectClass: olcChainConfig
olcOverlay: {0}chain
21 olcDatabase={0}ldap,olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config
objectClass: olcLDAPConfig
objectClass: olcChainDatabase
olcDatabase: {0}ldap
olcDbURI: "ldap://10.1.1.164:389";
olcDbStartTLS: start
olcDbIDAssertBind: bindmethod="simple" binddn="cn=admin,dc=example,dc=com"
credentials="secret" mode="self"
olcDbChaseReferrals: TRUE
If you want an example using an officially distributed tool, or one that
doesn't handle referrals, here it is, using
ldappasswd:
### Command issued on slave
ry...@slave:~# ldappasswd -h localhost uid=ryans,ou=Users,dc=example,dc=com
New password:
Re-enter new password:
Enter LDAP Password:
Result: Strong(er) authentication required (8)
Additional info: only authenticated users may change passwords
### Slave side logs using ldappasswd
May 5 10:30:47 slave slapd[30408]: conn=47 fd=41 ACCEPT from
IP=127.0.0.1:32947 (IP=0.0.0.0:389)
May 5 10:30:47 slave slapd[30408]: conn=47 op=0 EXT oid=1.3.6.1.4.1.1466.20037
May 5 10:30:47 slave slapd[30408]: conn=47 op=0 STARTTLS
May 5 10:30:47 slave slapd[30408]: conn=47 op=0 RESULT oid= err=0 text=
May 5 10:30:47 slave slapd[30408]: conn=47 fd=41 TLS established tls_ssf=128
ssf=128
May 5 10:30:47 slave slapd[30408]: conn=47 op=1 BIND
dn="uid=ryans,ou=Users,dc=example,dc=com" method=128
May 5 10:30:47 slave slapd[30408]: conn=47 op=1 BIND
dn="uid=ryans,ou=Users,dc=example,dc=com" mech=SIMPLE ssf=0
May 5 10:30:47 slave slapd[30408]: conn=47 op=1 RESULT tag=97 err=0 text=
May 5 10:30:47 slave slapd[30408]: conn=47 op=2 EXT oid=1.3.6.1.4.1.4203.1.11.1
May 5 10:30:47 slave slapd[30408]: conn=47 op=2 PASSMOD
id="uid=ryans,ou=Users,dc=example,dc=com" new
May 5 10:30:47 slave slapd[30408]: conn=47 op=2 RESULT oid= err=8 text=only
authenticated users may change passwords
