[Date Prev][Date Next] [Chronological] [Thread] [Top]
Re: (ITS#6540) test022-ppolicy is flawed, masks serious stability issue

To: openldap-its@OpenLDAP.org
Subject: Re: (ITS#6540) test022-ppolicy is flawed, masks serious stability issue
From: masarati@aero.polimi.it
Date: Fri, 8 Oct 2010 21:10:13 GMT
Auto-submitted: auto-generated (OpenLDAP-ITS)
> 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).

What the case description and the logs suggest is that the referral is
chased anonymously because the protocol/host/port portion of the URI in
the referral does not match the one configured in the chain-uri directive.
 In this case, slapo-chain defaults to anonymous.

What slapo-chain does is take the referral string, pass it to URL parsing
routines, isolate protocol, host and port, pass it back to URL unparsing,
and compare the resulting string with the one configured in chain-uri
(which had to go through the same "normalization" when configured).

Perhaps if you try with a more detailed log level you'll be able to see
the two strings and figure out if and how they differ.  Hope this helps.

p.


>
> 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
>
>
>
Prev by Date: Re: (ITS#6664) Server control forwarding in back_meta and back_ldap
Next by Date: (ITS#6668) MemberOf Overlay
Index(es):
- Chronological
- Thread