openldap-bugs

openldap-bugs@openldap.org

1 participants
20967 discussions

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

06 Oct '10

masarati(a)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

1 0

(ITS#6666) Feature Request: Triggers implementation
by nick＠eurobjects.com 06 Oct '10

06 Oct '10

Full_Name: Nick Milas Version: 2.3.43 OS: CentOS 5.5 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (94.65.0.240) Triggers in openldap is a much-desired feature. As mentioned in various places, openldap community suggests using the accesslog overlay to log changes and then use another process to listen to changes (e.g. back-perl) or back-sock (I saw the example in the source tree), feasibly back-shell or even write one's own overlay. The problem is that all those methods require low-level programming (not to mention various incompatibilities with system components), which makes them unusable by administrators, that is by those who mainly install and run openldap and directories. As a result, I would suggest to slightly enhance future versions by offering minimal trigger support over the accesslog overlay. So I would suggest to support in slapd.conf a statement like: "on log attr <attribute name> call <bash script>" (with obvious meaning). I consider this would allow the openldap average administrator to use particular attributes as triggers to start scripts which in turn offer the advantage of full access to script programming, which does not require low-level programming.

1 0

Re: FW: (ITS#5941) Problem when stacking rwm and translucent overlays together
by wdh＠vasco.com 06 Oct '10

06 Oct '10

--=-J3E4Om04oCzTAxqDTGlw Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit > In the meanwhile, you can try to use an instance of back-ldap as the > translucent local storage, and place slapo-rwm on the database of the > remote server that acts as local. I haven't tested it, so there might be > minor issues, but I don't expect anything like this one. Thanks for the input. This is also not an option because the remote server is in fact an Active Directory. Which in this case I can't alter. I will try to create 2 slapd process - One which will do the translucent proxy stuff, running on a non standard port - one which will have a back-ldap to this non standard port and doing there the rewrites. Thanks for helping me with this issue. --=-J3E4Om04oCzTAxqDTGlw Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN"> <HTML> <HEAD> <META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8"> <META NAME="GENERATOR" CONTENT="GtkHTML/3.28.3"> </HEAD> <BODY> <PRE> > In the meanwhile, you can try to use an instance of back-ldap as the > translucent local storage, and place slapo-rwm on the database of the > remote server that acts as local.  I haven't tested it, so there might be > minor issues, but I don't expect anything like this one. Thanks for the input. This is also not an option because the remote server is in fact an Active Directory. Which in this case I can't alter. I will try to create 2 slapd process - One which will do the translucent proxy stuff, running on a non standard port - one which will have a back-ldap to this non standard port and doing there the rewrites. Thanks for helping me with this issue. </PRE> </BODY> </HTML> --=-J3E4Om04oCzTAxqDTGlw--

1 0

Re: FW: (ITS#5941) Problem when stacking rwm and translucent overlays together
by masarati＠aero.polimi.it 06 Oct '10

06 Oct '10

> I installed the latest version currently available 2.4.23 > The same bug still exists in this version. > > So I can for sure say this is not related to ITS#6070 > > Since this is a major loss of functionality I would kindly ask someone to > h= > ave a deeper look at this. I confirm it is related to ITS#6070; only, that ITS could be fixed (read: worked around) differently. I don't think this qualifies as a "major loss of functionality" for the vast majority of the users of OpenLDAP. Solving this issue the right way (and few others) would require to advance OpenLDAP at least to 2.5 or 3.0, because a significant portion of the ABI would need to change, so do not expect to see it solved any soon. In the meanwhile, you can try to use an instance of back-ldap as the translucent local storage, and place slapo-rwm on the database of the remote server that acts as local. I haven't tested it, so there might be minor issues, but I don't expect anything like this one. p.

1 0

FW: (ITS#5941) Problem when stacking rwm and translucent overlays together
by wdh＠vasco.com 05 Oct '10

05 Oct '10

I installed the latest version currently available 2.4.23 The same bug still exists in this version. So I can for sure say this is not related to ITS#6070 Since this is a major loss of functionality I would kindly ask someone to h= ave a deeper look at this. Thanks Wouter=

1 0

Re: (ITS#5941) Problem when stacking rwm and translucent overlays together
by wdh＠vasco.com 05 Oct '10

05 Oct '10

--=-pjbfbkt+SDCV4FzF9Ohv Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit I'm hitting this bug also in Debian Lenny. Is this bug already fixed? It prevents me from implementing our OpenLDAP server. Thanks Wouter --=-pjbfbkt+SDCV4FzF9Ohv Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN"> <HTML> <HEAD> <META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8"> <META NAME="GENERATOR" CONTENT="GtkHTML/3.28.3"> </HEAD> <BODY> I'm hitting this bug also in Debian Lenny. Is this bug already fixed? It prevents me from implementing our OpenLDAP server. Thanks Wouter </BODY> </HTML> --=-pjbfbkt+SDCV4FzF9Ohv--

1 0

(ITS#6665) back_ldap and back_meta chasing referrals authentication
by jsceballos＠gmail.com 05 Oct '10

05 Oct '10

Full_Name: Javier Sanz Version: 2.4.17 OS: Debian Linux 5.0 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (80.38.203.12) back_ldap and back_meta should be able to do a non-anonymous bind to the referrals returned by the external LDAP servers. This is a regression since 2.3, because the old directives "pseudorootdn" and "pseudorootpw" allowed specifying the binddn and password that would be used to chase the referrals, but their 2.4 replacements "idassert-bind" and "idassert-authzFrom" do not allow that, so these binds are always done anonymously.

1 0

(ITS#6664) Server control forwarding in back_meta and back_ldap
by jsceballos＠gmail.com 05 Oct '10

05 Oct '10

Full_Name: Javier Sanz Version: 2.4.17 OS: Debian Linux 5.0 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (80.38.203.12) back_meta and back_ldap should forward server controls that clients use in their queries to the corresponding external LDAP servers. For example, the inhability to send controls to external servers currently causes that RFC2696 paged results control cannot be used, so it is impossible to retrieve more results for a query than the page size configured in the external server, which often is not a big number.

1 0

Re: (ITS#6647) Overlay sssvlv is always loaded
by clem.oudot＠gmail.com 05 Oct '10

05 Oct '10

--=-sj86jeXTHEFBrrKIl07g Content-Type: text/plain; charset=utf-8 Content-ID: <1286271588.1952.3.camel@Nokia-N900-51-1> Content-Transfer-Encoding: 8bit ----- Message d'origine ----- > > > Please try this (nearly blind) patch > > > > <ftp://ftp.openldap.org/incoming/pierangelo-masarati-2010-09-14-sssvlv.1.pat…> > > > > and report through the ITS. Thanks, p. > > I note that I have messed things up a bit in cleanup; however, this > should not affect the testing of the functionality, except if you delete > the overlay from the configuration using back-config. If the patch works > fine, I'll fix that part. > Hi, sorry for this late reply. I tried the patch on 2.4.23 source code, the second hunk was not working, so I deleted it to apply the patch. I am not using cn=config anyway. After recompiling with your patch and --enable-overlays, all works fine: a search with sss extention returns success (and fails if the control is critical). So I think you can commit the code! Thanks, Clément. --=-sj86jeXTHEFBrrKIl07g Content-Type: text/html; charset=utf-8 Content-ID: <1286271588.1952.5.camel@Nokia-N900-51-1> Content-Transfer-Encoding: 8bit <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> <html><head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> <meta name="generator" content="Osso Notes"> <title></title></head> <body> ----- Message d'origine ----- > > > Please try this (nearly blind) patch > > > > <<a href="ftp://ftp.openldap.org/incoming/pierangelo-masarati-2010-09-14-sssvlv.1.pat…">ftp://ftp.openldap.org/incoming/pierangelo-masarati-2010-09-14-sssvlv.1.pat…</a>; > > > > and report through the ITS.  Thanks, p. > > I note that I have messed things up a bit in cleanup; however, this > should not affect the testing of the functionality, except if you delete > the overlay from the configuration using back-config.  If the patch works > fine, I'll fix that part. > Hi, sorry for this late reply. I tried the patch on 2.4.23 source code, the second hunk was not working, so I deleted it to apply the patch. I am not using cn=config anyway. After recompiling with your patch and --enable-overlays, all works fine: a search with sss extention returns success (and fails if the control is critical). So I think you can commit the code! Thanks, Clément. </body> </html> --=-sj86jeXTHEFBrrKIl07g--

1 0

(ITS#6663) refint not altering last attribute on delete
by knewell＠math.arizona.edu 04 Oct '10

04 Oct '10

Full_Name: Karl Newell Version: 2.4.21 OS: Ubuntu 10.04 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (128.196.224.235) refint does not alter the value of an attribute to refint_nothing when the last "member" of a group is deleted. refint is working when the dn of a member is modified. slapd.conf: loglevel 16383 ... moduleload refint ... overlay refint refint_attributes member uniqueMember seeAlso refint_nothing cn=Manager,dc=math,dc=arizona,dc=edu ... ldap.log (what I believe to be the relevant entries): ... Oct 4 14:12:03 vm-ldap slapd[8744]: refint_search_cb <cn=LDAP Admins,ou=Groups,dc=math,dc=arizona,dc=edu> Oct 4 14:12:03 vm-ldap slapd[8744]: refint_search_cb: uniqueMember: uid=atb,ou=Users,dc=math,dc=arizona,dc=edu (#1) Oct 4 14:12:03 vm-ldap slapd[8744]: send_ldap_result: conn=-1 op=0 p=0 Oct 4 14:12:03 vm-ldap slapd[8744]: send_ldap_result: err=0 matched="" text="" Oct 4 14:12:03 vm-ldap slapd[8744]: refint_search_cb <NOTHING> Oct 4 14:12:03 vm-ldap slapd[8744]: hdb_modify: cn=LDAP Admins,ou=Groups,dc=math,dc=arizona,dc=edu Oct 4 14:12:03 vm-ldap slapd[8744]: bdb_dn2entry("cn=ldap admins,ou=groups,dc=math,dc=arizona,dc=edu") Oct 4 14:12:03 vm-ldap slapd[8744]: bdb_modify_internal: 0x00000008: cn=LDAP Admins,ou=Groups,dc=math,dc=arizona,dc=edu Oct 4 14:12:03 vm-ldap slapd[8744]: <= acl_access_allowed: granted to database root Oct 4 14:12:03 vm-ldap slapd[8744]: bdb_modify_internal: delete uniqueMember Oct 4 14:12:03 vm-ldap slapd[8744]: dnMatch 0#012#011"uid=atb,ou=users,dc=math,dc=arizona,dc=edu"#012#011"uid=atb,ou=users,dc=math,dc=arizona,dc=edu" Oct 4 14:12:03 vm-ldap slapd[8744]: bdb_modify_internal: replace modifiersName Oct 4 14:12:03 vm-ldap slapd[8744]: bdb_modify_internal: delete uniqueMember Oct 4 14:12:03 vm-ldap slapd[8744]: bdb_modify_internal: 16 modify/delete: uniqueMember: no such attribute Oct 4 14:12:03 vm-ldap slapd[8744]: hdb_modify: modify failed (16) Oct 4 14:12:03 vm-ldap slapd[8744]: send_ldap_result: conn=-1 op=0 p=0 Oct 4 14:12:03 vm-ldap slapd[8744]: send_ldap_result: err=16 matched="" text="modify/delete: uniqueMember: no such attribute" Oct 4 14:12:03 vm-ldap slapd[8744]: refint_repair: dependent modify failed: 16 ...

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