openldap-bugs

openldap-bugs@openldap.org

1 participants
20966 discussions

Re: (ITS#6546) Default olcRootDN of "cn=config" should be documented
by masarati＠aero.polimi.it 17 May '10

17 May '10

> 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. Fixed in HEAD's slapd-config(5); may be worth mentioning in the admin guide as well. Thanks, p.

1 0

Re: (ITS#6549) test043 hasSubordinates attribute inconsistencies
by masarati＠aero.polimi.it 17 May '10

17 May '10

> Indeed, syncprov_operational() is right: it duplicates the entry only if > contextCSN is already present in the entry, and thus may need to be > updated. What's wrong is back-bdb, which gives up when the entry does not > have e_private set appropriately, while it could do more to find out about > the entry's subordinates. This may explain why in some cases the > attribute is present. This occurs whenever contextCSN is not already > present in the entry. I'm preparing a fix for back-bdb. Fixed in HEAD; please test. Thanks, p.

1 0

Re: (ITS#6549) test043 hasSubordinates attribute inconsistencies
by masarati＠aero.polimi.it 17 May '10

17 May '10

> masarati(a)aero.polimi.it wrote: >> I just checked with HEAD and re24 (basically 2.4.22) on Linux (CentOS >> 5.2, >> for what it matters, and db-4.6.21, for what it matters), and it works >> fine if you explicitly ask for hasSubordinates, while this specific attr >> is not returned if you request '+'. The fact hasSubordinates does not >> appear means that the appropriate backend operational attrs hook was not >> called, or its value was ignored. > > Since hasSubordinates is a generated attribute, it would be filtered out > on > the consumer anyway. There's no reason to ever include it in replication > traffic. Indeed, syncprov_operational() is right: it duplicates the entry only if contextCSN is already present in the entry, and thus may need to be updated. What's wrong is back-bdb, which gives up when the entry does not have e_private set appropriately, while it could do more to find out about the entry's subordinates. This may explain why in some cases the attribute is present. This occurs whenever contextCSN is not already present in the entry. I'm preparing a fix for back-bdb. p. >> After a quick check, I figured out that bdb_hasSubordinates is passed a >> copy of the original entry, thus without bdb information, and >> bdb_hasSubordinates bails out. Apparently, syncprov copies the entry >> instead of putting operational attrs in rs_operational_attrs in >> SlapReply. >> >> p. >> >>> Full_Name: Matt Hardin >>> Version: 2.4.22 >>> OS: Red Hat AS 4 >>> URL: ftp://ftp.openldap.org/incoming/ >>> Submission from: (NULL) (74.38.117.141) >>> >>> >>> In test043 the test database defines a root entry of dc=example,dc=com. >>> For this >>> entry, the results of the ldapsearch do not include the hasSubordinates >>> attribute at all, in spite of the fact that the entry does have >>> subordinates. >>> Test043 passes, due to the fact that this attribute is missing from the >>> root >>> entry in both the provider and the consumer. >>> >>> Other entries with subordinates do include this attribute and its value >>> is >>> correct in all the cases I examined. >>> >>> Here is the snippet from tests/testrun/server1.flt: >>> >>> dn: dc=example,dc=com >>> dc: example >>> objectClass: organization >>> objectClass: domainRelatedObject >>> objectClass: dcObject >>> l: Anytown, Michigan >>> st: Michigan >>> o: Example, Inc. >>> o: EX >>> o: Ex. >>> description: The Example, Inc. at Anytown >>> postalAddress: Example, Inc. $ 535 W. William St. $ Anytown, MI 48109 $ >>> US >>> telephoneNumber: +1 313 555 1817 >>> associatedDomain: example.com >>> structuralObjectClass: organization >>> entryUUID: e2d47ecc-f24a-102e-90fb-9f641f00f9d2 >>> creatorsName: cn=Manager,dc=example,dc=com >>> createTimestamp: 20100512194705Z >>> entryCSN: 20100512194705.076849Z#000000#000#000000 >>> modifiersName: cn=Manager,dc=example,dc=com >>> modifyTimestamp: 20100512194705Z >>> contextCSN: 20100512194748.621773Z#000000#000#000000 >>> entryDN: dc=example,dc=com >>> subschemaSubentry: cn=Subschema >>> >>> The version of BDB in use here is 4.8.30, although I note this happens >>> with >>> earlier releases of BDB as well. >>> >>> Also of interest is the fact that this test fails on some platforms >>> (e.g. >>> Windows), because the provider slapd correctly reports >>> hasSubordinates=TRUE, >>> while the consumer omits the attribute entirely, in spite of the fact >>> that >>> subordinate entries do exist on the consumer. >>> >>> -Matt >>> >>> >>> >> >> >> >> > > > -- > -- 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#6549) test043 hasSubordinates attribute inconsistencies
by masarati＠aero.polimi.it 17 May '10

17 May '10

> masarati(a)aero.polimi.it wrote: >> I just checked with HEAD and re24 (basically 2.4.22) on Linux (CentOS >> 5.2, >> for what it matters, and db-4.6.21, for what it matters), and it works >> fine if you explicitly ask for hasSubordinates, while this specific attr >> is not returned if you request '+'. The fact hasSubordinates does not >> appear means that the appropriate backend operational attrs hook was not >> called, or its value was ignored. > > Since hasSubordinates is a generated attribute, it would be filtered out > on > the consumer anyway. There's no reason to ever include it in replication > traffic. I'd concur, but syncprov_operational steps in even for regular operations (correctly, because a client might want to see the contextCSN), and duplicates the entry unnecessarily, as contextCSN could be appended to sr_operational_attrs, unless it needs to be in the entry for some reason. p. >> After a quick check, I figured out that bdb_hasSubordinates is passed a >> copy of the original entry, thus without bdb information, and >> bdb_hasSubordinates bails out. Apparently, syncprov copies the entry >> instead of putting operational attrs in rs_operational_attrs in >> SlapReply. >> >> p. >> >>> Full_Name: Matt Hardin >>> Version: 2.4.22 >>> OS: Red Hat AS 4 >>> URL: ftp://ftp.openldap.org/incoming/ >>> Submission from: (NULL) (74.38.117.141) >>> >>> >>> In test043 the test database defines a root entry of dc=example,dc=com. >>> For this >>> entry, the results of the ldapsearch do not include the hasSubordinates >>> attribute at all, in spite of the fact that the entry does have >>> subordinates. >>> Test043 passes, due to the fact that this attribute is missing from the >>> root >>> entry in both the provider and the consumer. >>> >>> Other entries with subordinates do include this attribute and its value >>> is >>> correct in all the cases I examined. >>> >>> Here is the snippet from tests/testrun/server1.flt: >>> >>> dn: dc=example,dc=com >>> dc: example >>> objectClass: organization >>> objectClass: domainRelatedObject >>> objectClass: dcObject >>> l: Anytown, Michigan >>> st: Michigan >>> o: Example, Inc. >>> o: EX >>> o: Ex. >>> description: The Example, Inc. at Anytown >>> postalAddress: Example, Inc. $ 535 W. William St. $ Anytown, MI 48109 $ >>> US >>> telephoneNumber: +1 313 555 1817 >>> associatedDomain: example.com >>> structuralObjectClass: organization >>> entryUUID: e2d47ecc-f24a-102e-90fb-9f641f00f9d2 >>> creatorsName: cn=Manager,dc=example,dc=com >>> createTimestamp: 20100512194705Z >>> entryCSN: 20100512194705.076849Z#000000#000#000000 >>> modifiersName: cn=Manager,dc=example,dc=com >>> modifyTimestamp: 20100512194705Z >>> contextCSN: 20100512194748.621773Z#000000#000#000000 >>> entryDN: dc=example,dc=com >>> subschemaSubentry: cn=Subschema >>> >>> The version of BDB in use here is 4.8.30, although I note this happens >>> with >>> earlier releases of BDB as well. >>> >>> Also of interest is the fact that this test fails on some platforms >>> (e.g. >>> Windows), because the provider slapd correctly reports >>> hasSubordinates=TRUE, >>> while the consumer omits the attribute entirely, in spite of the fact >>> that >>> subordinate entries do exist on the consumer. >>> >>> -Matt >>> >>> >>> >> >> >> >> > > > -- > -- 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#6549) test043 hasSubordinates attribute inconsistencies
by hyc＠symas.com 17 May '10

17 May '10

masarati(a)aero.polimi.it wrote: > I just checked with HEAD and re24 (basically 2.4.22) on Linux (CentOS 5.2, > for what it matters, and db-4.6.21, for what it matters), and it works > fine if you explicitly ask for hasSubordinates, while this specific attr > is not returned if you request '+'. The fact hasSubordinates does not > appear means that the appropriate backend operational attrs hook was not > called, or its value was ignored. Since hasSubordinates is a generated attribute, it would be filtered out on the consumer anyway. There's no reason to ever include it in replication traffic. > After a quick check, I figured out that bdb_hasSubordinates is passed a > copy of the original entry, thus without bdb information, and > bdb_hasSubordinates bails out. Apparently, syncprov copies the entry > instead of putting operational attrs in rs_operational_attrs in SlapReply. > > p. > >> Full_Name: Matt Hardin >> Version: 2.4.22 >> OS: Red Hat AS 4 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (74.38.117.141) >> >> >> In test043 the test database defines a root entry of dc=example,dc=com. >> For this >> entry, the results of the ldapsearch do not include the hasSubordinates >> attribute at all, in spite of the fact that the entry does have >> subordinates. >> Test043 passes, due to the fact that this attribute is missing from the >> root >> entry in both the provider and the consumer. >> >> Other entries with subordinates do include this attribute and its value is >> correct in all the cases I examined. >> >> Here is the snippet from tests/testrun/server1.flt: >> >> dn: dc=example,dc=com >> dc: example >> objectClass: organization >> objectClass: domainRelatedObject >> objectClass: dcObject >> l: Anytown, Michigan >> st: Michigan >> o: Example, Inc. >> o: EX >> o: Ex. >> description: The Example, Inc. at Anytown >> postalAddress: Example, Inc. $ 535 W. William St. $ Anytown, MI 48109 $ US >> telephoneNumber: +1 313 555 1817 >> associatedDomain: example.com >> structuralObjectClass: organization >> entryUUID: e2d47ecc-f24a-102e-90fb-9f641f00f9d2 >> creatorsName: cn=Manager,dc=example,dc=com >> createTimestamp: 20100512194705Z >> entryCSN: 20100512194705.076849Z#000000#000#000000 >> modifiersName: cn=Manager,dc=example,dc=com >> modifyTimestamp: 20100512194705Z >> contextCSN: 20100512194748.621773Z#000000#000#000000 >> entryDN: dc=example,dc=com >> subschemaSubentry: cn=Subschema >> >> The version of BDB in use here is 4.8.30, although I note this happens >> with >> earlier releases of BDB as well. >> >> Also of interest is the fact that this test fails on some platforms (e.g. >> Windows), because the provider slapd correctly reports >> hasSubordinates=TRUE, >> while the consumer omits the attribute entirely, in spite of the fact that >> subordinate entries do exist on the consumer. >> >> -Matt >> >> >> > > > > -- -- 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#6549) test043 hasSubordinates attribute inconsistencies
by masarati＠aero.polimi.it 17 May '10

17 May '10

I just checked with HEAD and re24 (basically 2.4.22) on Linux (CentOS 5.2, for what it matters, and db-4.6.21, for what it matters), and it works fine if you explicitly ask for hasSubordinates, while this specific attr is not returned if you request '+'. The fact hasSubordinates does not appear means that the appropriate backend operational attrs hook was not called, or its value was ignored. After a quick check, I figured out that bdb_hasSubordinates is passed a copy of the original entry, thus without bdb information, and bdb_hasSubordinates bails out. Apparently, syncprov copies the entry instead of putting operational attrs in rs_operational_attrs in SlapReply. p. > Full_Name: Matt Hardin > Version: 2.4.22 > OS: Red Hat AS 4 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (74.38.117.141) > > > In test043 the test database defines a root entry of dc=example,dc=com. > For this > entry, the results of the ldapsearch do not include the hasSubordinates > attribute at all, in spite of the fact that the entry does have > subordinates. > Test043 passes, due to the fact that this attribute is missing from the > root > entry in both the provider and the consumer. > > Other entries with subordinates do include this attribute and its value is > correct in all the cases I examined. > > Here is the snippet from tests/testrun/server1.flt: > > dn: dc=example,dc=com > dc: example > objectClass: organization > objectClass: domainRelatedObject > objectClass: dcObject > l: Anytown, Michigan > st: Michigan > o: Example, Inc. > o: EX > o: Ex. > description: The Example, Inc. at Anytown > postalAddress: Example, Inc. $ 535 W. William St. $ Anytown, MI 48109 $ US > telephoneNumber: +1 313 555 1817 > associatedDomain: example.com > structuralObjectClass: organization > entryUUID: e2d47ecc-f24a-102e-90fb-9f641f00f9d2 > creatorsName: cn=Manager,dc=example,dc=com > createTimestamp: 20100512194705Z > entryCSN: 20100512194705.076849Z#000000#000#000000 > modifiersName: cn=Manager,dc=example,dc=com > modifyTimestamp: 20100512194705Z > contextCSN: 20100512194748.621773Z#000000#000#000000 > entryDN: dc=example,dc=com > subschemaSubentry: cn=Subschema > > The version of BDB in use here is 4.8.30, although I note this happens > with > earlier releases of BDB as well. > > Also of interest is the fact that this test fails on some platforms (e.g. > Windows), because the provider slapd correctly reports > hasSubordinates=TRUE, > while the consumer omits the attribute entirely, in spite of the fact that > subordinate entries do exist on the consumer. > > -Matt > > >

1 0

(ITS#6552) Request For Improvement - DSML support to ldap-clients/slap-tools
by marco.pizzoli＠gmail.com 16 May '10

16 May '10

Full_Name: Marco Pizzoli Version: ALL OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (217.133.1.151) Request For Improvement I would like to export a LDAP-database in DSML format with command line tools like ldapsearch or slapcat, so I ask if is it possible to extend functionality of openldap client tools.

1 0

openldap test-058 error
by tibor benke 15 May '10

15 May '10

Hi, I try to compile openLDAP 2.4.21 with this flags: ldap:~# ./configure --enable-bdb --enable-hdb --enable-dnssrv --enable-ldap --enable-ppolicy --disable-nbd The configuration works perfectly (make depend too), but i get 3 erros messages by test-058. ERROR: Second site1 backend not replicated to central master ERROR: Second site1 backend not replicated to central search What could cause this? Does anyone know? Any suggestions or help will be appreciated platform: Debian Lenny

3 2

Re: (ITS#6550) Patch for smbk5pwd slapd overlay to include shadowLastChange
by hyc＠symas.com 15 May '10

15 May '10

Michael Ströder wrote: > Howard Chu wrote: >> Michael Ströder wrote: >>> While I agree that slapo-ppolicy is the better solution in the long run I >>> see no reason why to not set both attributes at the server's side to >>> make older LDAP clients happy. >> >> This is not a realistic use case. smbk5pwd was written starting in 2004; >> pam_ldap started supporting LDAP password policy long before then. > > Yes, pam_ldap supports enforcing the password policy probably by correcty > handling the response controls. Grepping through the source of recent versions > it seems to me it does not read attribute pwdChangedTime nor does nss_ldap. Because clients don't need to read the value. Since password modification is all managed on the server, it's an irrelevant detail on the client. >> Anyone running LDAP clients (pam_ldap, nss_ldap) older than that has far >> worse problems to worry about. > > AFAICS nss_ldap cannot deliver the correct value for 'shadowLastChange' when > someone or something invokes a call like this > > getent shadow michael Nobody does that. Normal users don't even have read permission to do that. > 'pwdChangedTime' is of syntax Generalized Time whereas 'shadowLastChange' is > Integer with seconds since epoch. In theory nss_ldap could convert it. But > AFAICs it doesn't. Also if an older client would search for > (shadowLastChange<=<value>) this wouldn't work either. You've just proven the point why shadowLastChange is problematic. The encoded value is in *minutes* since the epoch. All of the shadow values were poorly defined to begin with (talking about /etc/shadow, not just RFC2307), inconsistent with common Unix practice, and most people don't understand them anyway. They have no role in an LDAP-enabled environment, all they do is perpetuate confusion. >> This ITS will be closed. > > Well, you're the OpenLDAP boss and free to refuse anything you want. But > personally I don't understand your strong objections. -- -- 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#6550) Patch for smbk5pwd slapd overlay to include shadowLastChange
by michael＠stroeder.com 15 May '10

15 May '10

Howard Chu wrote: > Michael Ströder wrote: >> While I agree that slapo-ppolicy is the better solution in the long run I >> see no reason why to not set both attributes at the server's side to >> make older LDAP clients happy. > > This is not a realistic use case. smbk5pwd was written starting in 2004; > pam_ldap started supporting LDAP password policy long before then. Yes, pam_ldap supports enforcing the password policy probably by correcty handling the response controls. Grepping through the source of recent versions it seems to me it does not read attribute pwdChangedTime nor does nss_ldap. > Anyone running LDAP clients (pam_ldap, nss_ldap) older than that has far > worse problems to worry about. AFAICS nss_ldap cannot deliver the correct value for 'shadowLastChange' when someone or something invokes a call like this getent shadow michael 'pwdChangedTime' is of syntax Generalized Time whereas 'shadowLastChange' is Integer with seconds since epoch. In theory nss_ldap could convert it. But AFAICs it doesn't. Also if an older client would search for (shadowLastChange<=<value>) this wouldn't work either. > This ITS will be closed. Well, you're the OpenLDAP boss and free to refuse anything you want. But personally I don't understand your strong objections. Ciao, Michael.

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