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