openldap-bugs

openldap-bugs@openldap.org

1 participants
20960 discussions

(ITS#6548) Many "connection_read(): no connection!" warnings when using ldapi:/// and a bind DN (no external authentication)
by online＠mark.ziesemer.com 11 May '10

11 May '10

Full_Name: Mark A. Ziesemer Version: 2.4.21 OS: Ubuntu Linux 10.04 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2001:470:1f11:3ae:4d6d:3d3e:faa6:ee3d) Many "connection_read(): no connection!" warnings are written to /var/log/debug and /var/log/syslog by slapd. As stated at http://www.openldap.org/lists/openldap-software/200811/msg00079.html , this is apparently not a problem with slapd, but a client that is disconnecting without first unbinding. This appears to be an issue with the libldap client library provided by OpenLDAP itself (2.4.21), and not the slapd daemon. Issue is reproducible even by just using "ldapsearch -H ldapi:///", but only if a bind DN is specified (-D) and external authentication is not used. Running slapd with logging enabled (-d 8) shows the following 3 sequences - ldapsearch command followed by the slapd logs. Note that the "connection_read(): no connection!" is only visible on the middle pair. $ ldapsearch -LLL -Y EXTERNAL -H ldapi:/// -b "" SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 No such object (32) slap_listener_activate(9): >>> slap_listener(ldapi:///) connection_get(14): got connid=1000 connection_read(14): checking for input on id=1000 ber_get_next ber_get_next: tag 0x30 len 24 contents: op tag 0x60, time 1273546410 ber_get_next conn=1000 op=0 do_bind ber_scanf fmt ({imt) ber: ber_scanf fmt ({m) ber: ber_scanf fmt (m) ber: ber_scanf fmt (}}) ber: >>> dnPrettyNormal: <> <<< dnPrettyNormal: <>, <> do_bind: dn () SASL mech EXTERNAL ==>slap_sasl2dn: converting SASL name gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth to a DN <==slap_sasl2dn: Converted SASL name to <nothing> SASL Authorize [conn=1000]: proxy authorization allowed authzDN="" send_ldap_sasl: err=0 len=-1 do_bind: SASL/EXTERNAL bind: dn="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" sasl_ssf=0 send_ldap_response: msgid=1 tag=97 err=0 ber_flush2: 14 bytes to sd 14 <== slap_sasl_bind: rc=0 connection_get(14): got connid=1000 connection_read(14): checking for input on id=1000 ber_get_next ber_get_next: tag 0x30 len 37 contents: op tag 0x63, time 1273546410 ber_get_next conn=1000 op=1 do_search ber_scanf fmt ({miiiib) ber: >>> dnPrettyNormal: <> <<< dnPrettyNormal: <>, <> ber_scanf fmt (m) ber: ber_scanf fmt ({M}}) ber: send_ldap_result: conn=1000 op=1 p=3 send_ldap_response: msgid=2 tag=101 err=32 ber_flush2: 14 bytes to sd 14 connection_get(14): got connid=1000 connection_read(14): checking for input on id=1000 ber_get_next ber_get_next: tag 0x30 len 5 contents: op tag 0x42, time 1273546410 ber_get_next conn=1000 op=2 do_unbind connection_close: conn=1000 sd=14 $ ldapsearch -H ldapi:/// -D "cn=admin,dc=example,dc=com" -b "" -W Enter LDAP Password: ldap_bind: Invalid credentials (49) slap_listener_activate(9): >>> slap_listener(ldapi:///) connection_get(14): got connid=1001 connection_read(14): checking for input on id=1001 ber_get_next ber_get_next: tag 0x30 len 44 contents: op tag 0x60, time 1273546420 ber_get_next conn=1001 op=0 do_bind ber_scanf fmt ({imt) ber: ber_scanf fmt (m}) ber: >>> dnPrettyNormal: <cn=admin,dc=example,dc=com> <<< dnPrettyNormal: <cn=admin,dc=example,dc=com>, <cn=admin,dc=example,dc=com> do_bind: version=3 dn="cn=admin,dc=example,dc=com" method=128 send_ldap_result: conn=1001 op=0 p=3 send_ldap_response: msgid=1 tag=97 err=49 ber_flush2: 14 bytes to sd 14 connection_get(14): got connid=1001 connection_read(14): checking for input on id=1001 ber_get_next ber_get_next on fd 14 failed errno=0 (Success) connection_close: conn=1001 sd=14 connection_read(14): no connection! connection_read(14): no connection! $ ldapsearch -H ldap:/// -D "cn=admin,dc=example,dc=com" -b "" -W Enter LDAP Password: ldap_bind: Invalid credentials (49) slap_listener_activate(8): >>> slap_listener(ldap:///) connection_get(14): got connid=1002 connection_read(14): checking for input on id=1002 ber_get_next ber_get_next: tag 0x30 len 44 contents: op tag 0x60, time 1273546425 ber_get_next conn=1002 op=0 do_bind ber_scanf fmt ({imt) ber: ber_scanf fmt (m}) ber: >>> dnPrettyNormal: <cn=admin,dc=example,dc=com> <<< dnPrettyNormal: <cn=admin,dc=example,dc=com>, <cn=admin,dc=example,dc=com> do_bind: version=3 dn="cn=admin,dc=example,dc=com" method=128 send_ldap_result: conn=1002 op=0 p=3 send_ldap_response: msgid=1 tag=97 err=49 ber_flush2: 14 bytes to sd 14 connection_get(14): got connid=1002 connection_read(14): checking for input on id=1002 ber_get_next ber_get_next on fd 14 failed errno=0 (Success) connection_close: conn=1002 sd=14

1 0

(ITS#6247)
by daniel＠pluta.biz 09 May '10

09 May '10

An updated version of the patch can be downloaded from here: ftp://ftp.openldap.org/incoming/daniel-pluta-100509.patch

1 0

(ITS#6547) config.guess needs updating
by panth13＠gmail.com 07 May '10

07 May '10

Full_Name: Bryan Stopp Version: 2.4.21 OS: AIX6.1 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (65.197.28.158) The latest version of the config.guess that is bundled with the source is about 5 years out of date. It doesn't pick up new operating systems (specifically AIX6.? in my case). Can someone grab the latest from GNU? (http://cvs.savannah.gnu.org/viewvc/config/config/config.guess) -B

1 0

(ITS#6546) Default olcRootDN of "cn=config" should be documented
by bugs＠mark.ziesemer.com 07 May '10

07 May '10

Full_Name: Mark A. Ziesemer Version: 2.4.21 OS: Ubuntu Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2001:470:1f11:3ae:4d06:cdd1:50ce:9c64) While using the "cn=config" configuration, I found that "cn=config" is also the default olcRootDN. By just configuring a olcRootPW , login to the config database is possible using "cn=config" and the configured olcRootPW. This default should be documented in the admin guide, etc. IRC user hyc on #openldap mentioned "it's been the default since 2005", but "I can't find the reference either, perhaps we lost it."

1 0

Re: (ITS#6545) delta-syncrepl rejects modification master accepted
by Frank.Swasey＠uvm.edu 07 May '10

07 May '10

On 5/6/10 3:18 PM, Quanah Gibson-Mount wrote: > Can you please show the contents of the accesslog databsae for this > change? dn: reqStart=20100506114012.000002Z,cn=accesslog objectClass: auditModify structuralObjectClass: auditModify reqStart: 20100506114012.000002Z reqEnd: 20100506114012.000003Z reqType: modify reqSession: 1006 reqAuthzID: cn=manager,dc=uvm,dc=edu reqDN: uid=fcswasey,ou=People,dc=uvm,dc=edu reqResult: 0 reqMod: sn:= Swasey reqMod: sn:= Swasey reqMod: entryCSN:= 20100506114012.200297Z#000000#000#000000 reqMod: modifiersName:= cn=manager,dc=uvm,dc=edu reqMod: modifyTimestamp:= 20100506114012Z entryUUID: 7ba18504-6f3b-450a-8420-a101ba6b76c5 creatorsName: cn=accesslog createTimestamp: 20100506114012Z entryCSN: 20100506114012.200297Z#000000#000#000000 modifiersName: cn=accesslog modifyTimestamp: 20100506114012Z entryDN: reqStart=20100506114012.000002Z,cn=accesslog subschemaSubentry: cn=Subschema hasSubordinates: FALSE -- Frank Swasey | http://www.uvm.edu/~fcs Sr Systems Administrator | Always remember: You are UNIQUE, University of Vermont | just like everyone else. "I am not young enough to know everything." - Oscar Wilde (1854-1900)

1 0

Re: (ITS#6545) delta-syncrepl rejects modification master accepted
by quanah＠zimbra.com 06 May '10

06 May '10

--On Wednesday, May 05, 2010 5:37 PM +0000 Frank.Swasey(a)uvm.edu wrote: > Full_Name: Francis Swasey > Version: 2.4.22 > OS: Red Hat Enterprise Linux 5 update 5 64-bit > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (132.198.107.64) > > > Platform: Red Hat Enterprise Linux 5, update 5, 64-bit > OpenLDAP: 2.4.22 (locally compiled), configured with delta-syncrepl. > > The following modify ldif successfully applies to the master: > > dn: uid=fcswasey,ou=People,dc=uvm,dc=edu > changetype: modify > replace: sn > sn: Swasey > - > replace: sn > sn: Swasey > - > > syncrepl_message_to_op: rid=100 mods check (sn: value #0 provided more > than once) Can you please show the contents of the accesslog databsae for this change? Thanks, Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#6545) delta-syncrepl rejects modification master accepted
by Frank.Swasey＠uvm.edu 05 May '10

05 May '10

Full_Name: Francis Swasey Version: 2.4.22 OS: Red Hat Enterprise Linux 5 update 5 64-bit URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (132.198.107.64) Platform: Red Hat Enterprise Linux 5, update 5, 64-bit OpenLDAP: 2.4.22 (locally compiled), configured with delta-syncrepl. The following modify ldif successfully applies to the master: dn: uid=fcswasey,ou=People,dc=uvm,dc=edu changetype: modify replace: sn sn: Swasey - replace: sn sn: Swasey - In OpenLDAP 2.3 -- this modify ldif deck failed because the "sn" attribute is presented twice. In OpenLDAP 2.4 -- it works, but the delta-syncrepl replica pukes on it with this error: syncrepl_message_to_op: rid=100 mods check (sn: value #0 provided more than once)

1 0

Re: (ITS#6540) test022-ppolicy is flawed, masks serious stability issue
by ryans＠aweber.com 05 May '10

05 May '10

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

1 0

(ITS#6544) how to implement password policy
by dsbrar16＠yahoo.com 05 May '10

05 May '10

Full_Name: Devender Singh Version: openldap 2.4.16 OS: RHEL5.4 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (122.177.190.226) Hello Dear, Please let me know, how to implement ppolicy in openldap2.4.16. I am using RHEL5.4 I have followed below steps on installation time: ************************************************** Installing BerkeleyDB ************************************************** 1) Create build_unix directory in /opt directory 2) Copy db-4.7.25.tar.gz to /opt/build_unix directory 3) Goto /opt/build_unix directory 4) gzip -d db-4.7.25.tar.gz 5) tar xvf db-4.7.25.tar 6) db-4.7.25/dist/configure 7) make 8) make install 9) vi /root/.bash_profile 10) Add below lines in .bash_profile of root user export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/BerkeleyDB.4.7/lib export LD_RUN_PATH=$LD_RUN_PATH:/usr/local/BerkeleyDB.4.7/lib 11) Close existing PUTTY and start new PUTTY ************************************************** Before Installation check the below packages: #rpm qa|grep openssl* After the above command if you dont find the all openssl packages than install them via yum command ************************************************** Installing OpenLDAP ************************************************** 1) Copy openldap-stable-20090411.tgz to /opt directory 2) gunzip -c openldap-stable-20090411.tgz | tar xf - 3) cd openldap-2.4.16 4) CPPFLAGS="-I/usr/local/BerkeleyDB.4.7/include -I/usr/local/ssl/include/openssl" 5) export CPPFLAGS 6) LDFLAGS="-L/usr/local/lib -L/usr/local/BerkeleyDB.4.7/lib -L/usr/local/ssl/lib -R/usr/local/lib -R/usr/local/BerkeleyDB.4.7/lib -R/usr/local/ssl/lib" 7) export LDFLAGS 8) LD_LIBRARY_PATH="/usr/local/BerkeleyDB.4.7/lib" 9) export LD_LIBRARY_PATH 10) ./configure 11) make depend 12) make 13) make install 14) vi /root/.bash_profile 15) Add OpenLDAP sbin path in .bash_profile of root user (E.g. export PATH=$PATH:$HOME/bin:/usr/local/sbin) 16) Close existing PUTTY and start new PUTTY ************************************************** Thanks in Advance. Regards, Devender Singh (+919818107222)

1 0

Re: (ITS#6540) test022-ppolicy is flawed, masks serious stability issue
by ryans＠aweber.com 04 May '10

04 May '10

Ryan Steele wrote: > Actually, it would appear I'm hitting the same problem as the OP in this thread: > > http://markmail.org/message/fhfhzy5uehh6e4us#query:openldap chain "modifications require > authentication"+page:1+mid:fhfhzy5uehh6e4us+state:results > > > I say that because when I get prompted for authentication by the slave (instead of having the referral handled > server-side), I see this corresponding entry in the master's logs: > > May 4 12:22:43 ldap1 slapd[8794]: conn=226810 fd=50 ACCEPT from IP=10.x.x.x:45081 (IP=0.0.0.0:389) > May 4 12:22:43 ldap1 slapd[8794]: conn=226810 op=0 BIND dn="" method=128 > May 4 12:22:43 ldap1 slapd[8794]: conn=226810 op=0 RESULT tag=97 err=0 text= > May 4 12:22:43 ldap1 slapd[8794]: conn=226810 op=1 MOD dn="uid=ryans,ou=Users,dc=example,dc=com" > May 4 12:22:43 ldap1 slapd[8794]: conn=226810 op=1 MOD attr=displayColor > May 4 12:22:43 ldap1 slapd[8794]: conn=226810 op=1 RESULT tag=103 err=8 text=modifications require authentication > May 4 12:22:43 ldap1 slapd[8794]: conn=226810 op=2 UNBIND > May 4 12:22:43 ldap1 slapd[8794]: conn=226810 fd=50 closed > > > So, it looks like the DN is not being passed through for some reason. Still working on trying to track it down... > The same issue affects ldappasswd (it refuses to change the passwd because it thinks the user has not bound to the directory), so it's not just third party utilities. It really does appear as though the chain overlay is stripping the DN before sending the request out to the master, because the logs seem to indicate that the request makes it to the master and fails because there is no DN before a referral is presented to the client that initially sent the update to the slave. I added the 'ACL' loglevel to what I already use ('stats' and 'sync'), just to confirm that it is wasn't being denied by ACL's or anything like that. I do see references to the 'authzFrom' and 'authzTo' attributes in the admin guide's section on chaining, and on the FAQ (http://www.openldap.org/faq/data/cache/1425.html), but the example in test022-ppolicy does not use them, so I would not think that they are required or causing this problem. In any case, I did add olcDbIDAssertAuthzFrom: {0}"*" to the slaves (as the FAQ says) just to be absolutely sure, but it made no difference. I initially thought that the uncommenting of that check was responsible for this behavior, but the followup I sent just prior to this has a link to an OpenLDAP mailing list thread that was made in February, well before these changes that you made, Pierangelo. In either case, the behavior is broken. Exactly where, I'm still trying to figure out, but would definitely appreciate any input from more seasoned OpenLDAP developers.

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs