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 ryans@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 ryans@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