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

[ryans@aweber.com]

masarati@aero.polimi.it wrote:
>> Hey Pierangelo,
>>
>> I just noticed http://www.openldap.org/its/index.cgi?findid=6574 - this
>> looks like it fixes the issue I mentioned in
>> http://www.openldap.org/its/index.cgi?findid=6540?  Is that assertion
>> correct?
> 
> I couldn't specifically look at your issue (apart from the simple fix to
> allow cn=config to work).  ITS#6574 should have nothing to do with your
> issue, as it affects back-meta in a part that has no code commonality with
> back-ldap, and slapo-chain is built on top of back-ldap.


I apologize - it had occurred to me that since http://www.openldap.org/doc/admin24/backends.html#Metadirectory states
that back-meta and back-ldap share a subset of code, and since the issue described in ITS#6574 appears to be *exactly*
the same problem I'm seeing in ITS#6540, that they might have been one and the same.


> I'm sorry I went back through this thread and got somehow lost; what's the
> exact topic now?  I infer (from followup #14) that there seems to be an
> issue about chaining because slapo-chain seems not to rebind as expected. 


ITS#6540 had two parts:

 1. The test script failed to identify a specific set of conditions in which slapo-chain would cause slapcat to fail and
also prevent slapd from being restarted after slapo-chain was enabled.

 2. The problem that the test script failed to detect with slapo-chain is directly related to the current problem:
slapo-chain does not properly rebind as the appropriate user as set in the olcDbIDAssertBind attribute.  Instead, it
rebinds as 'anonymous' (an empty DN), which is of very little practical use, since unauthenticated anonymous users
should not be allowed to modify anything.  As a result, slapd kicks the referral back to the client instead of chasing
it automatically, which completely defeats the purpose of using slapo-chain.


> Could you isolate the problem in a minimal setup (slapd.conf or the
> corresponding back-config's LDIF, a database and a simple operation that
> can be performed with ldapmodify/ldappasswd or so) to clearly reproduce
> the issue?
> 
> Thanks, p.
> 

The configuration and test operations below should show exactly what's going on, but first, allow me to describe the
process in a nutshell:

1. The client binds to the slave and issues a modification request

2. The slave creates the referral and tries to chase it automatically on the client's behalf to the upstream master
using slapo-chain

3. The automatic referral chasing fails because the DN is not passed through and the slave erroneously rebinds to the
master as anonymous (an empty DN) instead of the identity it's configured to assert, as set by the olcDbIDAssertBind
attribute.

4. Because the automatic referral chasing fails, the slave kicks back the referral to the client, stating that the
client "is not logged in" to the master and that "modifications require authentication".

5. When the client provides credentials for the referral (manual referral chasing), the rest of the operation works as
expected (updates made on master, which then cascades to the slaves).

The following LDIFs and sample operations exemplify the problem; please let me know if this example suffices, or if you
need a more complete reference or further clarification:

#################################################
#                CONFIGURATION                  #
#################################################

### back-config base entry on slave (abbreviated)
dn: cn=config
objectClass: olcGlobal
cn: config
olcConfigDir: /etc/ldap/slapd.d
olcReadOnly: FALSE
olcReverseLookup: FALSE
olcTLSCACertificateFile: /etc/ldap/ssl/certs/cacert.pem
olcTLSCertificateFile: /etc/ldap/ssl/certs/openldap.cert.pem
olcTLSCertificateKeyFile: /etc/ldap/ssl/keys/openldap.key.pem
olcAuthzPolicy: none
olcLogLevel: stats sync
olcPasswordHash: {SSHA}SUPERSECRET
olcServerID: 1 ldap://master1.example.com
olcServerID: 2 ldap://slave1.example.com

### back-config modules entry
dn: 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}syncprov.la
olcModuleLoad: {3}back_ldap.la

### back-config chain overlay entry
dn: olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config
objectClass: olcOverlayConfig
objectClass: olcChainConfig
olcOverlay: {0}chain

### back-config chain database
dn: olcDatabase={0}ldap,olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config
objectClass: olcLDAPConfig
objectClass: olcChainDatabase
olcDatabase: {0}ldap
olcDbURI: ldap://master1.example.com
olcDbIDAssertBind: bindmethod=simple binddn="cn=admin,dc=example,dc=com"
credentials=SECRET mode=self


#################################################
#        SIMPLE OPERATIONAL EXAMPLE             #
#################################################

### NOTE: This example uses ldapvi, but results are identical to ldapmodify, etc.
### NOTE: The client binds initially to the slave as the admin here, but results are identical to scenarios in which the
client binds as a regular user

### Attempting to modify 'displayColor' attribute belonging to entry 'uid=ryans,ou=Users,dc=example,dc=com'
root@slave1:~# ldapvi -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://master1.example.com/uid=ryans,ou=Users,dc=example,dc=com.
You are not logged in to ldap://master1.example.com:389 yet.
Type '!' or 'y' to do so.
Rebind? [y!nB*qQ?] y

--- Login
Type M-h for help on key bindings.

Filter or DN: cn=admin,dc=example,dc=com
    Password: ***********
Bound as cn=admin,dc=example,dc=com.
Done.

#################################################
#        LOGS FOR OPERATIONAL EXAMPLE           #
#################################################

### Logs on slave showing referral was correctly generated (err=10)
Oct  5 10:27:04 slave1 slapd[30408]: conn=44 fd=41 ACCEPT from IP=127.0.0.1:34118 (IP=0.0.0.0:389)
Oct  5 10:27:04 slave1 slapd[30408]: conn=44 op=0 EXT oid=1.3.6.1.4.1.1466.20037
Oct  5 10:27:04 slave1 slapd[30408]: conn=44 op=0 STARTTLS
Oct  5 10:27:04 slave1 slapd[30408]: conn=44 op=0 RESULT oid= err=0 text=
Oct  5 10:27:04 slave1 slapd[30408]: conn=44 fd=41 TLS established tls_ssf=128 ssf=128
Oct  5 10:27:04 slave1 slapd[30408]: conn=44 op=1 BIND dn="cn=admin,dc=example,dc=com" method=128
Oct  5 10:27:04 slave1 slapd[30408]: conn=44 op=1 BIND dn="cn=admin,dc=example,dc=com" mech=SIMPLE ssf=0
Oct  5 10:27:04 slave1 slapd[30408]: conn=44 op=1 RESULT tag=97 err=0 text=
Oct  5 10:27:04 slave1 slapd[30408]: conn=44 op=2 SRCH base="" scope=0 deref=0 filter="(objectClass=*)"
Oct  5 10:27:04 slave1 slapd[30408]: conn=44 op=2 SRCH attr=+ *
Oct  5 10:27:04 slave1 slapd[30408]: conn=44 op=2 ENTRY dn=""
Oct  5 10:27:04 slave1 slapd[30408]: conn=44 op=2 SEARCH RESULT tag=101 err=0 nentries=1 text=
Oct  5 10:27:04 slave1 slapd[30408]: conn=44 op=3 SRCH base="dc=example,dc=com" scope=2 deref=0 filter="(objectClass=*)"
Oct  5 10:27:04 slave1 slapd[30408]: conn=44 op=3 ENTRY dn="dc=example,dc=com"
Oct  5 10:27:04 slave1 slapd[30408]: conn=44 op=3 ENTRY dn="cn=admin,dc=example,dc=com"
Oct  5 10:27:04 slave1 slapd[30408]: conn=44 op=3 ENTRY dn="ou=users,dc=example,dc=com"
Oct  5 10:27:04 slave1 slapd[30408]: conn=44 op=3 ENTRY dn="ou=groups,dc=example,dc=com"
Oct  5 10:27:04 slave1 slapd[30408]: conn=44 op=3 ENTRY dn="uid=ryans,ou=users,dc=example,dc=com"
Oct  5 10:27:04 slave1 slapd[30408]: conn=44 op=3 ENTRY dn="cn=ryans,ou=groups,dc=example,dc=com"
Oct  5 10:27:04 slave1 slapd[30408]: conn=44 op=3 SEARCH RESULT tag=101 err=0 nentries=159 text=
Oct  5 10:27:07 slave1 slapd[30408]: conn=44 op=4 MOD dn="uid=ryans,ou=Users,dc=example,dc=com"
Oct  5 10:27:07 slave1 slapd[30408]: conn=44 op=4 MOD attr=displayColor
Oct  5 10:27:07 slave1 slapd[30408]: conn=44 op=4 RESULT tag=103 err=10 text=


### Logs on master showing that when the slave tried to chase the referral, it erroneously bound as anonymous
### NOTE: slave1.example.com = 10.0.1.196
Oct  5 10:27:07 master1 slapd[8794]: conn=402475 fd=273 ACCEPT from IP=10.0.1.196:43376 (IP=0.0.0.0:389)
Oct  5 10:27:07 master1 slapd[8794]: conn=402475 op=0 BIND dn="" method=128
Oct  5 10:27:07 master1 slapd[8794]: conn=402475 op=0 RESULT tag=97 err=0 text=
Oct  5 10:27:07 master1 slapd[8794]: conn=402475 op=1 MOD dn="uid=ryans,ou=Users,dc=example,dc=com"
Oct  5 10:27:08 master1 slapd[8794]: conn=402475 op=1 MOD attr=displayColor
Oct  5 10:27:08 master1 slapd[8794]: conn=402475 op=1 RESULT tag=103 err=8 text=modifications require authentication
Oct  5 10:27:08 master1 slapd[8794]: conn=402475 op=2 UNBIND
Oct  5 10:27:08 master1 slapd[8794]: conn=402475 fd=273 closed
Oct  5 10:27:08 master1 slapd[8794]: conn=402476 fd=273 ACCEPT from IP=10.0.1.196:43377 (IP=0.0.0.0:389)


If there are any details not shown that you'd like, or any clarification you require, or if there's anything at all you
need to help facilitate the investigation, please let me know and I'll do my best to accommodate.  Thanks!

-Ryan