openldap-bugs August 2012

openldap-bugs@openldap.org

29 participants
100 discussions

Re: (ITS#7346) ACL processing: additive privs (using control continue)
by hyc＠symas.com 05 Aug '12

05 Aug '12

daniel(a)pluta.biz wrote: > Full_Name: Daniel Pluta > Version: MASTER > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (84.167.55.212) > > > For further explainations please vistit this technical-posting: > > http://www.openldap.org/lists/openldap-technical/201208/msg00025.html > > Testbed containing slapd.conf, data, ldapsearch-queries and 128-logs are given > below. As noted in the referenced email thread, this is working as designed. "continue" controls are only useful when a following clause matches the same subject and specifies incremental privileges. There are no following clauses that match the subject in this case, so the implicit "by * none" at the end of every ACL clause is applied. Closing this ITS. -- -- 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#7346) ACL processing: additive privs (using control continue)
by daniel＠pluta.biz 04 Aug '12

04 Aug '12

Full_Name: Daniel Pluta Version: MASTER OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (84.167.55.212) For further explainations please vistit this technical-posting: http://www.openldap.org/lists/openldap-technical/201208/msg00025.html Testbed containing slapd.conf, data, ldapsearch-queries and 128-logs are given below. Thanks a lot ------8<--------- slapd.conf --------8<--------- include /opt/openldap-HEAD/etc/openldap/schema/core.schema pidfile /opt/openldap-HEAD/var/run/slapd.pid argsfile /opt/openldap-HEAD/var/run/slapd.args access to * by self write by users read by anonymous auth database mdb suffix "o=test" rootdn "cn=Manager,o=test" rootpw secret directory /opt/openldap-HEAD/var/openldap-data/test index objectClass eq access to dn.subtree="o=test" attrs=sn by users =s continue by group/groupOfNames/member="cn=readers,ou=groups,o=test" +r ------8<--------- sample data --------8<--------- version: 1 dn: o=test objectClass: organization objectClass: top o: test dn: ou=groups,o=test objectClass: organizationalUnit objectClass: top ou: groups dn: ou=persons,o=test objectClass: organizationalUnit objectClass: top ou: persons dn: cn=PersonA,ou=persons,o=test objectClass: person objectClass: top cn: PersonA sn: PersonA userPassword:: UGVyc29uQQ== dn: cn=PersonB,ou=persons,o=test objectClass: person objectClass: top cn: PersonB sn: PersonB userPassword:: UGVyc29uQg== dn: cn=readers,ou=groups,o=test objectClass: groupOfNames objectClass: top cn: readers member: cn=PersonA,ou=persons,o=test ------8<---------Tests using ldapsearch--------8<--------- #Test 1 seem to work as intended: # bindDn "cn=PersonA,..." is member of group "cn=readers,..." # filter: sn=* # search succeeds (that's ok) # read succeeds (that's ok, too) deepee@test:~$ ldapsearch -x -H "ldap://localhost:1389/"; -D "cn=PersonA,ou=persons,o=test" -w PersonA -b "ou=persons,o=test" '(sn=*)' sn cn # extended LDIF # # LDAPv3 # base <ou=persons,o=test> with scope subtree # filter: (sn=*) # requesting: sn cn # # PersonA, persons, test dn: cn=PersonA,ou=persons,o=test sn: PersonA cn: PersonA # PersonB, persons, test dn: cn=PersonB,ou=persons,o=test cn: PersonB sn: PersonB # search result search: 2 result: 0 Success # numResponses: 3 # numEntries: 2 #slapd's log (level 128): 501be157 => access_allowed: result not in cache (userPassword) 501be157 => access_allowed: auth access to "cn=PersonA,ou=persons,o=test" "userPassword" requested 501be157 => dn: [1] o=test 501be157 => acl_get: [1] matched 501be157 => acl_get: [2] attr userPassword 501be157 => acl_mask: access to entry "cn=PersonA,ou=persons,o=test", attr "userPassword" requested 501be157 => acl_mask: to value by "", (=0) 501be157 <= check a_dn_pat: self 501be157 <= check a_dn_pat: users 501be157 <= check a_dn_pat: anonymous 501be157 <= acl_mask: [3] applying auth(=xd) (stop) 501be157 <= acl_mask: [3] mask: auth(=xd) 501be157 => slap_access_allowed: auth access granted by auth(=xd) 501be157 => access_allowed: auth access granted by auth(=xd) 501be157 => access_allowed: search access to "ou=persons,o=test" "entry" requested 501be157 => dn: [1] o=test 501be157 => acl_get: [1] matched 501be157 => acl_get: [2] attr entry 501be157 => acl_mask: access to entry "ou=persons,o=test", attr "entry" requested 501be157 => acl_mask: to all values by "cn=persona,ou=persons,o=test", (=0) 501be157 <= check a_dn_pat: self 501be157 <= check a_dn_pat: users 501be157 <= acl_mask: [2] applying read(=rscxd) (stop) 501be157 <= acl_mask: [2] mask: read(=rscxd) 501be157 => slap_access_allowed: search access granted by read(=rscxd) 501be157 => access_allowed: search access granted by read(=rscxd) 501be157 => access_allowed: search access to "ou=persons,o=test" "sn" requested 501be157 => dn: [1] o=test 501be157 => acl_get: [1] matched 501be157 => acl_get: [1] attr sn 501be157 => acl_mask: access to entry "ou=persons,o=test", attr "sn" requested 501be157 => acl_mask: to all values by "cn=persona,ou=persons,o=test", (=0) 501be157 <= check a_dn_pat: users 501be157 <= acl_mask: [1] applying =s (continue) 501be157 <= acl_mask: [1] mask: =s 501be157 <= check a_group_pat: cn=readers,ou=groups,o=test 501be157 => mdb_entry_get: found entry: "cn=readers,ou=groups,o=test" 501be157 <= acl_mask: [2] applying +r (stop) 501be157 <= acl_mask: [2] mask: =rs 501be157 => slap_access_allowed: search access granted by =rs 501be157 => access_allowed: search access granted by =rs 501be157 => access_allowed: search access to "cn=PersonA,ou=persons,o=test" "sn" requested 501be157 => dn: [1] o=test 501be157 => acl_get: [1] matched 501be157 => acl_get: [1] attr sn 501be157 => acl_mask: access to entry "cn=PersonA,ou=persons,o=test", attr "sn" requested 501be157 => acl_mask: to all values by "cn=persona,ou=persons,o=test", (=0) 501be157 <= check a_dn_pat: users 501be157 <= acl_mask: [1] applying =s (continue) 501be157 <= acl_mask: [1] mask: =s 501be157 <= check a_group_pat: cn=readers,ou=groups,o=test 501be157 <= acl_mask: [2] applying +r (stop) 501be157 <= acl_mask: [2] mask: =rs 501be157 => slap_access_allowed: search access granted by =rs 501be157 => access_allowed: search access granted by =rs 501be157 => access_allowed: read access to "cn=PersonA,ou=persons,o=test" "entry" requested 501be157 => dn: [1] o=test 501be157 => acl_get: [1] matched 501be157 => acl_get: [2] attr entry 501be157 => acl_mask: access to entry "cn=PersonA,ou=persons,o=test", attr "entry" requested 501be157 => acl_mask: to all values by "cn=persona,ou=persons,o=test", (=0) 501be157 <= check a_dn_pat: self 501be157 <= acl_mask: [1] applying write(=wrscxd) (stop) 501be157 <= acl_mask: [1] mask: write(=wrscxd) 501be157 => slap_access_allowed: read access granted by write(=wrscxd) 501be157 => access_allowed: read access granted by write(=wrscxd) 501be157 => access_allowed: result not in cache (sn) 501be157 => access_allowed: read access to "cn=PersonA,ou=persons,o=test" "sn" requested 501be157 => dn: [1] o=test 501be157 => acl_get: [1] matched 501be157 => acl_get: [1] attr sn 501be157 => acl_mask: access to entry "cn=PersonA,ou=persons,o=test", attr "sn" requested 501be157 => acl_mask: to value by "cn=persona,ou=persons,o=test", (=0) 501be157 <= check a_dn_pat: users 501be157 <= acl_mask: [1] applying =s (continue) 501be157 <= acl_mask: [1] mask: =s 501be157 <= check a_group_pat: cn=readers,ou=groups,o=test 501be157 <= acl_mask: [2] applying +r (stop) 501be157 <= acl_mask: [2] mask: =rs 501be157 => slap_access_allowed: read access granted by =rs 501be157 => access_allowed: read access granted by =rs 501be157 => access_allowed: result not in cache (cn) 501be157 => access_allowed: read access to "cn=PersonA,ou=persons,o=test" "cn" requested 501be157 => dn: [1] o=test 501be157 => acl_get: [1] matched 501be157 => acl_get: [2] attr cn 501be157 => acl_mask: access to entry "cn=PersonA,ou=persons,o=test", attr "cn" requested 501be157 => acl_mask: to value by "cn=persona,ou=persons,o=test", (=0) 501be157 <= check a_dn_pat: self 501be157 <= acl_mask: [1] applying write(=wrscxd) (stop) 501be157 <= acl_mask: [1] mask: write(=wrscxd) 501be157 => slap_access_allowed: read access granted by write(=wrscxd) 501be157 => access_allowed: read access granted by write(=wrscxd) 501be157 => access_allowed: search access to "cn=PersonB,ou=persons,o=test" "sn" requested 501be157 => dn: [1] o=test 501be157 => acl_get: [1] matched 501be157 => acl_get: [1] attr sn 501be157 => acl_mask: access to entry "cn=PersonB,ou=persons,o=test", attr "sn" requested 501be157 => acl_mask: to all values by "cn=persona,ou=persons,o=test", (=0) 501be157 <= check a_dn_pat: users 501be157 <= acl_mask: [1] applying =s (continue) 501be157 <= acl_mask: [1] mask: =s 501be157 <= check a_group_pat: cn=readers,ou=groups,o=test 501be157 <= acl_mask: [2] applying +r (stop) 501be157 <= acl_mask: [2] mask: =rs 501be157 => slap_access_allowed: search access granted by =rs 501be157 => access_allowed: search access granted by =rs 501be157 => access_allowed: read access to "cn=PersonB,ou=persons,o=test" "entry" requested 501be157 => dn: [1] o=test 501be157 => acl_get: [1] matched 501be157 => acl_get: [2] attr entry 501be157 => acl_mask: access to entry "cn=PersonB,ou=persons,o=test", attr "entry" requested 501be157 => acl_mask: to all values by "cn=persona,ou=persons,o=test", (=0) 501be157 <= check a_dn_pat: self 501be157 <= check a_dn_pat: users 501be157 <= acl_mask: [2] applying read(=rscxd) (stop) 501be157 <= acl_mask: [2] mask: read(=rscxd) 501be157 => slap_access_allowed: read access granted by read(=rscxd) 501be157 => access_allowed: read access granted by read(=rscxd) 501be157 => access_allowed: result not in cache (cn) 501be157 => access_allowed: read access to "cn=PersonB,ou=persons,o=test" "cn" requested 501be157 => dn: [1] o=test 501be157 => acl_get: [1] matched 501be157 => acl_get: [2] attr cn 501be157 => acl_mask: access to entry "cn=PersonB,ou=persons,o=test", attr "cn" requested 501be157 => acl_mask: to value by "cn=persona,ou=persons,o=test", (=0) 501be157 <= check a_dn_pat: self 501be157 <= check a_dn_pat: users 501be157 <= acl_mask: [2] applying read(=rscxd) (stop) 501be157 <= acl_mask: [2] mask: read(=rscxd) 501be157 => slap_access_allowed: read access granted by read(=rscxd) 501be157 => access_allowed: read access granted by read(=rscxd) 501be157 => access_allowed: result not in cache (sn) 501be157 => access_allowed: read access to "cn=PersonB,ou=persons,o=test" "sn" requested 501be157 => dn: [1] o=test 501be157 => acl_get: [1] matched 501be157 => acl_get: [1] attr sn 501be157 => acl_mask: access to entry "cn=PersonB,ou=persons,o=test", attr "sn" requested 501be157 => acl_mask: to value by "cn=persona,ou=persons,o=test", (=0) 501be157 <= check a_dn_pat: users 501be157 <= acl_mask: [1] applying =s (continue) 501be157 <= acl_mask: [1] mask: =s 501be157 <= check a_group_pat: cn=readers,ou=groups,o=test 501be157 <= acl_mask: [2] applying +r (stop) 501be157 <= acl_mask: [2] mask: =rs 501be157 => slap_access_allowed: read access granted by =rs 501be157 => access_allowed: read access granted by =rs #Test 2 does not seem to work as intended (at least to me): # bindDn "cn=PersonB,..." not a member of group "cn=readers,..." # filter: sn=* # read fails (that's ok) # search fails (but why is the privilege "=s" reset?) deepee@test:~$ ldapsearch -x -H "ldap://localhost:1389/"; -D "cn=PersonB,ou=persons,o=test" -w PersonB -b "ou=persons,o=test" '(sn=*)' sn cn # extended LDIF # # LDAPv3 # base <ou=persons,o=test> with scope subtree # filter: (sn=*) # requesting: sn cn # # search result search: 2 result: 0 Success # numResponses: 1 #slapd's log (level 128): 501be196 => access_allowed: result not in cache (userPassword) 501be196 => access_allowed: auth access to "cn=PersonB,ou=persons,o=test" "userPassword" requested 501be196 => dn: [1] o=test 501be196 => acl_get: [1] matched 501be196 => acl_get: [2] attr userPassword 501be196 => acl_mask: access to entry "cn=PersonB,ou=persons,o=test", attr "userPassword" requested 501be196 => acl_mask: to value by "", (=0) 501be196 <= check a_dn_pat: self 501be196 <= check a_dn_pat: users 501be196 <= check a_dn_pat: anonymous 501be196 <= acl_mask: [3] applying auth(=xd) (stop) 501be196 <= acl_mask: [3] mask: auth(=xd) 501be196 => slap_access_allowed: auth access granted by auth(=xd) 501be196 => access_allowed: auth access granted by auth(=xd) 501be196 => access_allowed: search access to "ou=persons,o=test" "entry" requested 501be196 => dn: [1] o=test 501be196 => acl_get: [1] matched 501be196 => acl_get: [2] attr entry 501be196 => acl_mask: access to entry "ou=persons,o=test", attr "entry" requested 501be196 => acl_mask: to all values by "cn=personb,ou=persons,o=test", (=0) 501be196 <= check a_dn_pat: self 501be196 <= check a_dn_pat: users 501be196 <= acl_mask: [2] applying read(=rscxd) (stop) 501be196 <= acl_mask: [2] mask: read(=rscxd) 501be196 => slap_access_allowed: search access granted by read(=rscxd) 501be196 => access_allowed: search access granted by read(=rscxd) 501be196 => access_allowed: search access to "ou=persons,o=test" "sn" requested 501be196 => dn: [1] o=test 501be196 => acl_get: [1] matched 501be196 => acl_get: [1] attr sn 501be196 => acl_mask: access to entry "ou=persons,o=test", attr "sn" requested 501be196 => acl_mask: to all values by "cn=personb,ou=persons,o=test", (=0) 501be196 <= check a_dn_pat: users 501be196 <= acl_mask: [1] applying =s (continue) 501be196 <= acl_mask: [1] mask: =s 501be196 <= check a_group_pat: cn=readers,ou=groups,o=test 501be196 => mdb_entry_get: found entry: "cn=readers,ou=groups,o=test" 501be196 <= acl_mask: no more <who> clauses, returning =0 (stop) 501be196 => slap_access_allowed: search access denied by =0 501be196 => access_allowed: no more rules 501be196 => access_allowed: search access to "cn=PersonA,ou=persons,o=test" "sn" requested 501be196 => dn: [1] o=test 501be196 => acl_get: [1] matched 501be196 => acl_get: [1] attr sn 501be196 => acl_mask: access to entry "cn=PersonA,ou=persons,o=test", attr "sn" requested 501be196 => acl_mask: to all values by "cn=personb,ou=persons,o=test", (=0) 501be196 <= check a_dn_pat: users 501be196 <= acl_mask: [1] applying =s (continue) 501be196 <= acl_mask: [1] mask: =s 501be196 <= check a_group_pat: cn=readers,ou=groups,o=test 501be196 <= acl_mask: no more <who> clauses, returning =0 (stop) 501be196 => slap_access_allowed: search access denied by =0 501be196 => access_allowed: no more rules 501be196 => access_allowed: search access to "cn=PersonB,ou=persons,o=test" "sn" requested 501be196 => dn: [1] o=test 501be196 => acl_get: [1] matched 501be196 => acl_get: [1] attr sn 501be196 => acl_mask: access to entry "cn=PersonB,ou=persons,o=test", attr "sn" requested 501be196 => acl_mask: to all values by "cn=personb,ou=persons,o=test", (=0) 501be196 <= check a_dn_pat: users 501be196 <= acl_mask: [1] applying =s (continue) 501be196 <= acl_mask: [1] mask: =s 501be196 <= check a_group_pat: cn=readers,ou=groups,o=test 501be196 <= acl_mask: no more <who> clauses, returning =0 (stop) 501be196 => slap_access_allowed: search access denied by =0 501be196 => access_allowed: no more rules

1 0

(ITS#7345) New Feature : Add Connection Information in Access Log Entries
by ldap＠htam.net 03 Aug '12

03 Aug '12

Full_Name: Mathieu MILLET Version: HEAD OS: Linux URL: ftp://ftp.openldap.org/incoming/accesslog_addConnectionInformation.patch Submission from: (NULL) (82.67.21.31) Entries provided by the Access Log Overlay does not contain informations such as the IP Address of the client. This patch adds a simple attribute : reqConnInfo containing the content of o_conn->c_peer_name . Please review this patch because I'm not sure about what safety checks must be performed on these data before "merging" them. If this patch is accepted : I, Mathieu MILLET, hereby place the following modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice.

1 0

Re: (ITS#7342) Password modify EXOP requires a DN
by hyc＠symas.com 02 Aug '12

02 Aug '12

Eric Clements wrote: > I filed it in response to a posting I saw on AFP548 regarding OS X. Some users have patched OpenLDAP to work around the issue. If you have a working patch that behaves as you think it should, you're welcome to submit it. Unfortunately, the RFC is explicitly silent on how other identity formats are represented. I.e., it doesn't even specify that SASL identities (such as used in SASL Bind) are valid here. > Though your statement is true, many SASL methods do not use DNs either. I > do not see why it is not allowed for passwordModify in the same way. If it behaves as designed then feel free to close. > > Thank you, > --------------------------- > Eric Clements > > On Aug 1, 2012, at 2:26 PM, Howard Chu <hyc(a)symas.com> wrote: > >> eclements(a)apple.com wrote: >>> Full_Name: Eric Clements >>> Version: 2.4.26 >>> OS: MacOS >>> URL: ftp://ftp.openldap.org/incoming/ >>> Submission from: (NULL) (17.193.15.131) >>> >>> >>> RFC 3062 Section 2.1 (authored by OpenLDAP) states that a password modify >>> request may or may not be an LDAP DN, yet OpenLDAP backend requires a DN. >> >> I'm not sure I understand why you've filed this ITS. The RFC doesn't specify >> that a server MUST support non-DN valued identities. It in fact says in Section 3: >> >> If the server does not recognize provided fields or does not support >> the combination of fields provided, it SHALL NOT change the user >> password. >> >> Clearly it is allowed for a server to reject identities if it doesn't >> recognize them. -- -- 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#7342) Password modify EXOP requires a DN
by eclements＠apple.com 02 Aug '12

02 Aug '12

I filed it in response to a posting I saw on AFP548 regarding OS X. Some users have patched OpenLDAP to work around the issue. Though your statement is true, many SASL methods do not use DNs either. I do not see why it is not allowed for passwordModify in the same way. If it behaves as designed then feel free to close. Thank you, --------------------------- Eric Clements On Aug 1, 2012, at 2:26 PM, Howard Chu <hyc(a)symas.com> wrote: > eclements(a)apple.com wrote: >> Full_Name: Eric Clements >> Version: 2.4.26 >> OS: MacOS >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (17.193.15.131) >> >> >> RFC 3062 Section 2.1 (authored by OpenLDAP) states that a password modify >> request may or may not be an LDAP DN, yet OpenLDAP backend requires a DN. > > I'm not sure I understand why you've filed this ITS. The RFC doesn't specify > that a server MUST support non-DN valued identities. It in fact says in Section 3: > > If the server does not recognize provided fields or does not support > the combination of fields provided, it SHALL NOT change the user > password. > > Clearly it is allowed for a server to reject identities if it doesn't > recognize them. > > -- > -- 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#7344) [PATCH] Add initial testsuit for slapo-constraint
by hyc＠symas.com 02 Aug '12

02 Aug '12

jsynacek(a)redhat.com wrote: > Full_Name: Jan Synacek > Version: master > OS: linux-fedora17 > URL: ftp://ftp.openldap.org/incoming/jsynacek-20120802-testsuit-slapo-constraint… > Submission from: (NULL) (209.132.186.34) > > > This patch adds an initial testsuit for slapo-constraint. Thanks, added to master. > > The attached file is derived from OpenLDAP Software. All of the modifications > to > OpenLDAP Software represented in the following patch(es) were developed by Red > Hat. Red Hat has not assigned rights and/or interest in this work to any party. > I, Jan Synacek am authorized by Red Hat, my employer, to release this work > under > the following terms. > > Red Hat hereby place the following modifications to OpenLDAP Software (and only > these modifications) into the public domain. Hence, these modifications may be > freely used and/or redistributed for any purpose with or without attribution > and/or other notice. > > -- -- 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#7344) [PATCH] Add initial testsuit for slapo-constraint
by jsynacek＠redhat.com 02 Aug '12

02 Aug '12

Full_Name: Jan Synacek Version: master OS: linux-fedora17 URL: ftp://ftp.openldap.org/incoming/jsynacek-20120802-testsuit-slapo-constraint… Submission from: (NULL) (209.132.186.34) This patch adds an initial testsuit for slapo-constraint. The attached file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Red Hat. Red Hat has not assigned rights and/or interest in this work to any party. I, Jan Synacek am authorized by Red Hat, my employer, to release this work under the following terms. Red Hat hereby place the following modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice.

1 0

Re: (ITS#7342) Password modify EXOP requires a DN
by hyc＠symas.com 01 Aug '12

01 Aug '12

eclements(a)apple.com wrote: > Full_Name: Eric Clements > Version: 2.4.26 > OS: MacOS > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (17.193.15.131) > > > RFC 3062 Section 2.1 (authored by OpenLDAP) states that a password modify > request may or may not be an LDAP DN, yet OpenLDAP backend requires a DN. I'm not sure I understand why you've filed this ITS. The RFC doesn't specify that a server MUST support non-DN valued identities. It in fact says in Section 3: If the server does not recognize provided fields or does not support the combination of fields provided, it SHALL NOT change the user password. Clearly it is allowed for a server to reject identities if it doesn't recognize them. -- -- 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#7343) dynlist overlay does not include attributes of an entry containing objectClass of the dynlist attrset
by openldap＠stormcloud9.net 01 Aug '12

01 Aug '12

Full_Name: Patrick Hemmer Version: 2.4.31 OS: RHEL6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (98.211.220.204) The issue is that if the entry being dynamically added to the parent entry has the objectClass slapo-dynlist is configured to use (to determine expansion), that entry is not dynamically added to the parent. For example: ---- dn: olcOverlay={4}dynlist,olcDatabase={3}hdb,cn=config objectClass: olcDynamicList objectClass: olcOverlayConfig olcOverlay: {4}dynlist olcDlAttrSet: {0}labeledURIObject labeledURI ---- dn: cn=parent,dc=example,dc=com objectClass: groupOfNames objectClass: top objectClass: labeledURIObject cn: parent member: uid=foo,dc=example,dc=com labeledURI: ldap:///cn=child,dc=example,dc=com??base?(objectClass=*) dn: cn=child,dc=example,dc=com objectClass: groupOfNames objectClass: top objectClass: labeledURIObject member: uid=bar,dc=example,dc=com cn: child ---- In the above example, I would expect "member: uid=bar,dc=example,dc=com" to be added to cn=parent,dc=example,dc=com, but it isn't. Now the documentation clearly states recursion is not allowed, so if cn=child were to have a 'labeledURI', this labeledURI would not be expanded. But this is not what is being done here, cn=child has no labeledURI present. It also behaves perfectly fine if I pull the "objetClass: labeledURIObject" off cn=child. ldapsearch with objectClass labeledURIObject present on cn=child: ---- dn: cn=parent,dc=example,dc=com objectClass: groupOfNames objectClass: top objectClass: labeledURIObject cn: parent member: uid=foo,dc=example,dc=com labeledURI: ldap:///cn=child,dc=example,dc=com??base?(objectClass=*) ---- ldapsearch without objectClass labeledURIObject present on cn=child: ---- dn: cn=parent,dc=example,dc=com objectClass: groupOfNames objectClass: top objectClass: labeledURIObject cn: parent cn: child member: uid=foo,dc=example,dc=com member: uid=bar,dc=example,dc=com labeledURI: ldap:///cn=child,dc=example,dc=com??base?(objectClass=*) ----

1 0

(ITS#7342) Password modify EXOP requires a DN
by eclements＠apple.com 31 Jul '12

31 Jul '12

Full_Name: Eric Clements Version: 2.4.26 OS: MacOS URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (17.193.15.131) RFC 3062 Section 2.1 (authored by OpenLDAP) states that a password modify request may or may not be an LDAP DN, yet OpenLDAP backend requires a DN.

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs August 2012