Re: (ITS#6540) test022-ppolicy is flawed, masks serious stability issue

[ryans@aweber.com]

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