openldap-bugs June 2011

openldap-bugs@openldap.org

35 participants
131 discussions

Re: (ITS#6887) authz-regexp: backslash escaping/normalization
by daniel＠pluta.biz 09 Jun '11

09 Jun '11

Please also have a look into the might be related patch, submitted in ITS#6912 which addresses normalization of auth(c|z)Id of the form "u:xxx" in general. Thank you very much.

1 0

Re: (ITS#6966) admin guide references "Start TLS" instead of StartTLS
by quanah＠zimbra.com 09 Jun '11

09 Jun '11

--On Thursday, June 09, 2011 10:19 PM +0000 quanah(a)OpenLDAP.org wrote: > Full_Name: Quanah Gibson-Mount > Version: NA > OS: NA > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (75.111.45.108) > > > The admin guide refers to "Start TLS" in multiple locations instead of > "StartTLS", which leads to confusion among end users, and makes searching > for the startTLS pieces a pain. I will fix shortly. > I will mark this as invalid, as this is how it is described in all the RFCs as well (Start TLS). --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6688) OpenLDAP 2.4.23 doesn't enforce ACLs on back-perl subordinate database
by hyc＠symas.com 09 Jun '11

09 Jun '11

mark.cave-ayland(a)siriusit.co.uk wrote: > Full_Name: Mark Cave-Ayland > Version: 2.4.23 > OS: Linux/Debian > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (81.187.123.11) > > > Hi all, > > We have an issue on one of our production systems whereby openldap is not > enforcing the ACLs on a back-perl subordinate database. Keep in mind, this is back-perl's documented behavior. >>> ACCESS CONTROL The perl backend does not honor any of the access control semantics described in slapd.access(5); all access control is delegated to the underlying PERL scripting. Only read (=r) access to the entry pseudo- attribute and to the other attribute values of the entries returned by the search operation is honored, which is performed by the frontend. <<< Treating this as an enhancement request. > In this particular system, the membership of certain groups stored within LDAP > is determined by some customised logic in a Perl module which dynamically > generates LDAP objects with posixGroup/groupOfNames entries conditionally based > upon the values of existing LDAP attributes within the tree. However, since > these internal LDAP attribute lookups can be quite slow, we wish to hide them > from all but a small minority of bind DNs. Unfortunately what we are finding is > that the back-perl module is not respecting the ACLs in slapd.conf. > > The following files can be used to reproduce this issue with openldap 2.4.23: > > http://pastebin.siriusit.co.uk/perlacl/slapd.conf > http://pastebin.siriusit.co.uk/perlacl/perlacl.ldif > http://pastebin.siriusit.co.uk/perlacl/PerlACL.pm > > The password for both the "cn=admin,dc=my-domain,dc=com" and the > "cn=restricted,dc=my-domain,dc=com" DNs is secret. > > The ACLs in the above slapd.conf look like this: > > access to dn.subtree="ou=perl,dc=my-domain,dc=com" > by dn="cn=admin,dc=my-domain,dc=com" read > by dn="cn=restricted,dc=my-domain,dc=com" none > > access to dn.subtree="ou=hidden,dc=my-domain,dc=com" > by dn="cn=admin,dc=my-domain,dc=com" read > by dn="cn=restricted,dc=my-domain,dc=com" none > > access to * > by dn="cn=admin,dc=my-domain,dc=com" write > by dn="cn=restricted,dc=my-domain,dc=com" read > by * auth > > Using these ACLs, I would expect that cn=admin should be able to read the whole > directory, whereas cn=restricted should not be able to see either the > "ou=hidden,dc=my-domain,dc=com" DN subtree nor the "ou=perl,dc=my-domain,dc=com" > DN subtree. > > However, performing an LDAP search binding as cn=restricted gives the following > output: > > build@zeno:~$ ldapsearch -LLL -H ldap://localhost:10389 -D > 'cn=restricted,dc=my-domain,dc=com' -b 'dc=my-domain,dc=com' -xW > Enter LDAP Password: > dn: dc=my-domain,dc=com > objectClass: top > objectClass: dcObject > objectClass: organization > o:: bXlkb21haW4uY29tIA== > dc: my-domain > > dn: ou=real,dc=my-domain,dc=com > objectClass: organizationalUnit > objectClass: top > ou: real > > dn: ou=realtest1,ou=real,dc=my-domain,dc=com > objectClass: organizationalUnit > objectClass: top > ou: realtest1 > > dn: ou=realtest2,ou=real,dc=my-domain,dc=com > objectClass: organizationalUnit > objectClass: top > ou: realtest2 > > dn: ou=realtest3,ou=real,dc=my-domain,dc=com > objectClass: organizationalUnit > objectClass: top > ou: realtest3 > > dn: ou=realtest4,ou=real,dc=my-domain,dc=com > objectClass: organizationalUnit > objectClass: top > ou: realtest4 > > dn: ou=realtest5,ou=real,dc=my-domain,dc=com > objectClass: organizationalUnit > objectClass: top > ou: realtest5 > > dn: cn=restricted,dc=my-domain,dc=com > objectClass: simpleSecurityObject > objectClass: organizationalRole > cn: restricted > description: restricted user > userPassword:: e1NIQX01ZW42RzZNZXpScm9UM1hLcWtkUE9tWS9CZlE9 > > dn: cn=admin,dc=my-domain,dc=com > objectClass: simpleSecurityObject > objectClass: organizationalRole > cn:: YWRtaW4g > description: admin user > userPassword:: e1NIQX01ZW42RzZNZXpScm9UM1hLcWtkUE9tWS9CZlE9 > > dn: ou=perltest5,ou=perl,dc=my-domain,dc=com > objectClass: organizationalUnit > objectClass: top > ou: perltest5 > > dn: ou=perltest4,ou=perl,dc=my-domain,dc=com > objectClass: organizationalUnit > objectClass: top > ou: perltest4 > > dn: ou=perltest3,ou=perl,dc=my-domain,dc=com > objectClass: organizationalUnit > objectClass: top > ou: perltest3 > > dn: ou=perltest2,ou=perl,dc=my-domain,dc=com > objectClass: organizationalUnit > objectClass: top > ou: perltest2 > > dn: ou=perltest1,ou=perl,dc=my-domain,dc=com > objectClass: organizationalUnit > objectClass: top > ou: perltest1 > > > In other words, the "ou=hidden,dc=my-domain,dc=com" subtree is correctly hidden > from the cn=restricted user, whereas the "ou=perl,dc=my-domain,dc=com" subtree > is not. > > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#6966) admin guide references "Start TLS" instead of StartTLS
by quanah＠OpenLDAP.org 09 Jun '11

09 Jun '11

Full_Name: Quanah Gibson-Mount Version: NA OS: NA URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.45.108) The admin guide refers to "Start TLS" in multiple locations instead of "StartTLS", which leads to confusion among end users, and makes searching for the startTLS pieces a pain. I will fix shortly.

1 0

Re: (ITS#6688) OpenLDAP 2.4.23 doesn't enforce ACLs on back-perl subordinate database
by hyc＠symas.com 09 Jun '11

09 Jun '11

mark.cave-ayland(a)siriusit.co.uk wrote: > On 09/06/11 00:21, Quanah Gibson-Mount wrote: > >>> An update on this bug report: with a modified slapd.conf and a small >>> patch to the back-perl module, I can use the ACL mask to ensure that the >>> perl search function doesn't get invoked if disallowed by the ACLs. >>> >>> The patch works by creating a "fake" empty entry whose DN is the base of >>> the search, and then passing this entry into access_allowed() using code >>> borrowed from one of the other backends to either deny or allow access. >>> >>> http://pastebin.siriusit.co.uk/perlacl/slapd2.conf >>> http://pastebin.siriusit.co.uk/perlacl/openldap-backperl-acls.patch >> >> These are not accessible. > > Hi Quanah, > > Ah yes indeed - that server was decommissioned last month. I've since > reinstated the files from a backup onto a new server and updated DNS to > point to it. Can you verify that you can now download them? Thanks, got it now. The patch leaks memory. I'll commit a fixed version of it shortly. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#6688) OpenLDAP 2.4.23 doesn't enforce ACLs on back-perl subordinate database
by mark.cave-ayland＠siriusit.co.uk 09 Jun '11

09 Jun '11

On 09/06/11 00:21, Quanah Gibson-Mount wrote: >> An update on this bug report: with a modified slapd.conf and a small >> patch to the back-perl module, I can use the ACL mask to ensure that the >> perl search function doesn't get invoked if disallowed by the ACLs. >> >> The patch works by creating a "fake" empty entry whose DN is the base of >> the search, and then passing this entry into access_allowed() using code >> borrowed from one of the other backends to either deny or allow access. >> >> http://pastebin.siriusit.co.uk/perlacl/slapd2.conf >> http://pastebin.siriusit.co.uk/perlacl/openldap-backperl-acls.patch > > These are not accessible. Hi Quanah, Ah yes indeed - that server was decommissioned last month. I've since reinstated the files from a backup onto a new server and updated DNS to point to it. Can you verify that you can now download them? Many thanks, Mark. -- Mark Cave-Ayland - Senior Technical Architect PostgreSQL - PostGIS Sirius Corporation plc - control through freedom http://www.siriusit.co.uk t: +44 870 608 0063 Sirius Labs: http://www.siriusit.co.uk/labs

1 0

(ITS#6965) Ldap ld210_en for Mdaemon ver 11.0.1-urgent
by elena.morozova＠softline.ru 09 Jun '11

09 Jun '11

Full_Name: Elena Morozova Version: - OS: - URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (62.141.102.2) Hello, Earlier our client used Ldap ld210_en for Mdaemon ver 11.0.1. What can you advise to use instead of Ldap ld210_en for Mdaemon ver 11.0.1? Thank you.

1 0

Re: (ITS#6830) slapo-ppolicy.5 has incorrect schema fragments
by hyc＠symas.com 09 Jun '11

09 Jun '11

Andrew Findlay wrote: > On Tue, Feb 15, 2011 at 05:02:52AM -0800, Howard Chu wrote: > >>> slapo-ppolicy.5 incorrectly includes the NO-USER-MODIFICATION flag in the schema >>> fragments for pwdPolicySubentry and pwdAccountLockedTime. >> >> That's how they were defined in the IETF Draft. The schema fragments >> in the manpage were copied directly from the spec. The fact that the >> current implementation deviates from the spec is just out of >> necessity to make things work at all in our present code base. > > Certainly the use of pwdPolicySubentry differs from the > intention of the draft (which I believe was intending to use > real X.500-style subentries). > > The case of pwdAccountLockedTime is arguable. > draft-behera-ldap-password-policy-xx.txt says: > > This attribute holds the time that the user's account was locked. A > locked account means that the password may no longer be used to > authenticate. A 000001010000Z value means that the account has been > locked permanently, and that only a password administrator can unlock > the account. > > Unfortunately it says nothing about *how* a password > administrator should do that when the attribute is marked > NO-USER-MODIFICATION. I would argue that this is a > deficiency in the draft, and that the current OpenLDAP > behaviour is more useful. > >> Things will not always work this way... > > Indeed, but I would prefer the manpages to reflect the > reality of the current release! I note that in ppolicy.c we have: { "( 1.3.6.1.4.1.42.2.27.8.1.17 " "NAME ( 'pwdAccountLockedTime' ) " "DESC 'The time an user account was locked' " "EQUALITY generalizedTimeMatch " "ORDERING generalizedTimeOrderingMatch " "SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 " "SINGLE-VALUE " #if 0 /* Not until Relax control is released */ "NO-USER-MODIFICATION " #endif "USAGE directoryOperation )", We have in fact released support for the Relax control, so it's probably time to unifdef these bits and go back to the documented behavior. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: [PATCH] More for ITS#6872
by hyc＠symas.com 09 Jun '11

09 Jun '11

cmikk(a)qwest.net wrote: > [Note: The previous patch did not fix the problem when > the consumer's access was restricted to the replicated > subtree. This patch fixes that.] Both applied to git master, thanks. > > Perform the internal FIND_CSN search based at the backend's suffix with the > privileges of the backend's root DN. > --- > servers/slapd/overlays/syncprov.c | 2 ++ > 1 files changed, 2 insertions(+), 0 deletions(-) > > diff --git a/servers/slapd/overlays/syncprov.c b/servers/slapd/overlays/syncprov.c > index 0c148f9..a058e19 100644 > --- a/servers/slapd/overlays/syncprov.c > +++ b/servers/slapd/overlays/syncprov.c > @@ -661,6 +661,8 @@ again: > if ( BER_BVISEMPTY(&cf.f_av_value )) { > cf.f_av_value = *csn; > } > + fop.o_dn = op->o_bd->be_rootdn; > + fop.o_ndn = op->o_bd->be_rootndn; > fop.o_req_dn = op->o_bd->be_suffix[0]; > fop.o_req_ndn = op->o_bd->be_nsuffix[0]; > /* Look for exact match the first time */ -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#6671) multi-master replication fails to delete objects from consumer
by hyc＠symas.com 08 Jun '11

08 Jun '11

hyc(a)symas.com wrote: > bcolston(a)xtec.com wrote: >> Full_Name: Barry Colston >> Version: 2.4.23 >> OS: Fedora 10 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (209.255.208.200) > > I'm looking at your test case now. One thing to note, serverIDs must all be > non-zero in a multi-master configuration. serverID == 0 is only valid in > single-master replication. > >> When a "Refresh Present" phase is performed at a multi-master consumer, objects >> that were deleted at the provider >> while the consumer was down are not deleted from the multi-master consumer (if >> the provider is brought down and back up after the consumer is down). This >> problem can be duplicated as follows: >> 1. Start provider >> 2. Start consumer, which is configured as a multi-master server >> 3. Add 10 records to the provider and wait until the records are replicated to >> the multi-master consumer >> 4. Stop the consumer >> 5. Delete 3 of the records that were added to the provider >> 6. Stop the provider >> 7. Start the provider >> 8. Start the consumer >> 9. After giving the consumer time to perform the refresh present phase, the 3 >> records that were deleted at the provider while the consumer was down >> are still present on the consumer and were not deleted during the refresh >> present phase >> >> Note: the consumer database must have a contextCSN attribute value present for >> itself (e.g., there should be 2 contextCSN attribute values >> present in the consumer database, one for the provider (in my configuration, >> this is serverID 000), and one value for the consumer >> (in my configuration, this is serverID 001). An example of the contextCSN >> values follows: I see. This configuration is not supported. "Multi-Master" requires the servers to be full peers. In your configuration, you have a dedicated provider, it never pulls changes from the consumer, while your consumer is pulling from the provider and accepting local changes. Since the consumer has changes that the provider doesn't know about, the sync protocol is broken. The consumer cannot conclusively state that all entries the provider doesn't know about must be deleted, since some of those entries may have legitimately been created on the consumer, so it cannot execute the delete-nonpresent step. Closing this ITS. >> dn: dc=authentx >> objectClass: top >> entryUUID: 8eb6b259-ab66-49bd-b012-674c4f0fba8f >> contextCSN: 20101012154030.379053Z#000000#000#000000 >> contextCSN: 20101012141508.956053Z#000000#001#000000 >> >> OpenLDAP 2.4.23 is being used, along with Berkeley 4.6.21 (plus patches). >> >> Consumer log file from -d sync logging option: >> @(#) $OpenLDAP: slapd 2.4.23 (Oct 11 2010 18:00:59) $ >> Barry@XTecVisaAdmin:/usr/src/openldap-2.4.23/servers/slapd >> slapd starting >> do_syncrep2: rid=001 LDAP_RES_INTERMEDIATE - SYNC_ID_SET >> do_syncrep2: rid=001 LDAP_RES_INTERMEDIATE - SYNC_ID_SET >> do_syncrep2: rid=001 LDAP_RES_INTERMEDIATE - SYNC_ID_SET >> do_syncrep2: rid=001 LDAP_RES_INTERMEDIATE - SYNC_ID_SET >> do_syncrep2: rid=001 LDAP_RES_INTERMEDIATE - SYNC_ID_SET >> do_syncrep2: rid=001 LDAP_RES_INTERMEDIATE - SYNC_ID_SET >> do_syncrep2: rid=001 LDAP_RES_INTERMEDIATE - SYNC_ID_SET >> do_syncrep2: rid=001 LDAP_RES_INTERMEDIATE - SYNC_ID_SET >> do_syncrep2: rid=001 LDAP_RES_INTERMEDIATE - SYNC_ID_SET >> do_syncrep2: rid=001 LDAP_RES_INTERMEDIATE - SYNC_ID_SET >> do_syncrep2: rid=001 LDAP_RES_INTERMEDIATE - SYNC_ID_SET >> do_syncrep2: rid=001 LDAP_RES_INTERMEDIATE - SYNC_ID_SET >> do_syncrep2: rid=001 LDAP_RES_INTERMEDIATE - REFRESH_PRESENT >> do_syncrep2: rid=001 >> cookie=rid=001,csn=20101012180219.072053Z#000000#000#000000 >> slap_queue_csn: queing 0x1841a30 20101012180219.072053Z#000000#000#000000 >> slap_graduate_commit_csn: removing 0x1841b18 >> 20101012180219.072053Z#000000#000#000000 >> daemon: shutdown requested and initiated. >> slapd shutdown: waiting for 1 operations/tasks to finish >> slapd stopped. >> >> Provider slapd.conf file: >> # >> include /usr/local/etc/openldap/schema/core.schema >> include /usr/local/etc/openldap/schema/cosine.schema >> include /usr/local/etc/openldap/schema/inetorgperson.schema >> include /usr/local/etc/openldap/schema/nis.schema >> >> include /usr/local/etc/openldap/schema/authentx.schema >> >> pidfile /usr/local/var/slapd.sync1.pid >> argsfile /usr/local/var/slapd.sync1.args >> >> allow bind_v2 >> >> threads 32 >> >> #loglevel 416 >> password-hash {SSHA} >> >> serverID 000 >> >> database bdb >> suffix "dc=authentx" >> rootdn "cn=xroot,dc=authentx" >> rootpw SECRET >> directory /authentx/db/ldap/authentx-sync1 >> >> overlay syncprov >> syncprov-checkpoint 100 15 >> syncprov-sessionlog 150000 >> >> # checkpoint<kbytes> <min> >> checkpoint 128 20 >> >> #index for the objectclass >> index objectClass eq,pres >> index cid,eid,pid eq,pres >> index gcoid eq,pres >> index sysid,certid eq,pres >> index imageid,bioid eq,pres >> index addrid,emplid eq,pres >> index acid,apid,aeid eq,pres >> index acpid,agpid eq,pres >> index deviceid eq,pres >> index qid eq,pres >> index scid eq,pres >> index docid eq,pres >> index procid eq,pres >> index prochandlerid eq,pres >> index ounit eq,pres >> index credentials eq,pres >> index entities eq,pres >> index permissions eq,pres >> index region eq,pres >> index aliasedObjectName eq,pres >> index proctype eq,pres >> index procname eq,pres >> index status eq,pres >> index upi,ediident eq,pres >> index xsync eq,pres >> index role,xrole eq,pres >> index eroid eq,pres >> index esfunction eq,pres >> index nippsector eq,pres >> index ercog,ercoop eq,pres >> index eropron eq,pres >> index xsyncid eq,pres >> index stockid eq,pres >> index stocktypecode eq,pres >> index lotserialin eq,pres >> index lotserialout eq,pres >> index entryCSN,entryUUID eq >> index incl eq,pres >> >> cachesize 10000 >> dncachesize 20000 >> idlcachesize 1000 >> >> sizelimit 500000 >> timelimit 36000 >> include /usr/local/etc/openldap/acl.authentx >> >> database monitor >> >> Consumer slapd.conf file: >> # >> include /usr/local/etc/openldap/schema/core.schema >> include /usr/local/etc/openldap/schema/cosine.schema >> include /usr/local/etc/openldap/schema/inetorgperson.schema >> include /usr/local/etc/openldap/schema/nis.schema >> >> include /usr/local/etc/openldap/schema/authentx.schema >> >> pidfile /usr/local/var/slapd.sync2.pid >> argsfile /usr/local/var/slapd.sync2.args >> >> allow bind_v2 >> >> threads 32 >> >> #loglevel 416 >> password-hash {SSHA} >> >> serverID 001 >> >> database bdb >> suffix "dc=authentx" >> rootdn "cn=xroot,dc=authentx" >> rootpw SECRET >> directory /authentx/db/ldap/authentx-sync2 >> >> overlay syncprov >> syncprov-checkpoint 100 15 >> syncprov-sessionlog 5000 >> >> # SLAVE server replication section >> syncrepl rid=001 >> provider=ldap://localhost:3891 >> type=refreshAndPersist >> retry="30 60 60 +" >> searchbase="dc=authentx" >> scope=sub >> schemachecking=off >> bindmethod=simple >> binddn="cn=xroot,dc=authentx" >> credentials="SECRET" >> >> mirrormode on >> >> # checkpoint<kbytes> <min> >> checkpoint 128 20 >> >> #index for the objectclass >> index objectClass eq,pres >> index cid,eid,pid eq,pres >> index gcoid eq,pres >> index sysid,certid eq,pres >> index imageid,bioid eq,pres >> index addrid,emplid eq,pres >> index acid,apid,aeid eq,pres >> index acpid,agpid eq,pres >> index deviceid eq,pres >> index qid eq,pres >> index scid eq,pres >> index docid eq,pres >> index procid eq,pres >> index prochandlerid eq,pres >> index ounit eq,pres >> index credentials eq,pres >> index entities eq,pres >> index permissions eq,pres >> index region eq,pres >> index aliasedObjectName eq,pres >> index proctype eq,pres >> index procname eq,pres >> index status eq,pres >> index upi,ediident eq,pres >> index xsync eq,pres >> index role,xrole eq,pres >> index eroid eq,pres >> index esfunction eq,pres >> index nippsector eq,pres >> index ercog,ercoop eq,pres >> index eropron eq,pres >> index xsyncid eq,pres >> index stockid eq,pres >> index stocktypecode eq,pres >> index lotserialin eq,pres >> index lotserialout eq,pres >> index entryCSN,entryUUID eq >> index incl eq,pres >> >> cachesize 10000 >> dncachesize 20000 >> idlcachesize 1000 >> >> sizelimit 100000 >> timelimit 36000 >> # the authentx database access control directives >> include /usr/local/etc/openldap/acl.authentx >> >> database monitor >> >> > > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

← Newer
1
...
5
6
7
8
9
10
11
...
14
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs June 2011