- openldap-bugs - openldap.org

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

(ITS#6551) wrapping lines option
by muzzol＠gmail.com 15 May '10

15 May '10

Full_Name: muzzol Version: 2.4.18 OS: ubuntu karmic URL: http://www.openldap.org/its/index.cgi/Contrib?id=4269;page=1 Submission from: (NULL) (62.43.106.218) this is a feature request for making wrapping optional. there's an old discussion here: http://www.openldap.org/its/index.cgi/Contrib?id=4269;page=1 but seems that no one take any final decission. disabling wrapping helps a lot when creating simple scripts and several ldap search utilities have this option (mozldap tools, etc).

1 0

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

14 May '10

This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig9D91E1E8CB10AE4177453556 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Yes, I'll have to do some work to set that up -- I'll get back to you. Frank On 5/13/10 8:44 PM, masarati(a)aero.polimi.it wrote: > I checked with HEAD and re24 (basically, 2.4.22 from CVS) and I couldn'= t > reproduce the issue. Can you provide the configuration and an example > LDIF that triggers the issue? I simply ran test043, restart both serve= rs, > and perform a modification similar to yours, and it went through with n= o > problems. > > p. > > =20 >> 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=3Dfcswasey,ou=3DPeople,dc=3Duvm,dc=3Dedu >> 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=3D100 mods check (sn: value #0 provided mo= re >> than once) >> >> >> >> =20 > =20 --=20 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) --------------enig9D91E1E8CB10AE4177453556 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.14 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJL7YngAAoJEK5S4SsZ5NvSXhMP/24kilppZcRb+NHqXnP1yqaP 3Y4U/6UJ4E6/oVOccr2trGXzCk4LDPyRvGrlY9SouX5Rf8Y7FsddoE0aiTN3mU+L xd4iTsExl7lTTuPZ55BvLBgCQWIkwppArXR/u8OasNTtIcgdDPKVkjbCsGY6xcji ISefkXix5jNgqOe6dQl/DTfJtsAQepCC18t2AvFh727udKu592e5lawlvc3EBH9C ZB+8Pn7iKbVsUX9htwD3PQY+v52SAgmANoPvbTIeH7HQiclqLBi5qgWW9EbOt43Y 716+FCB55M5W5SKSiFncj45UVAv7z+E1qVuduzcFDuX0LrnC1BMjL/9SbIN2IQX6 ATMrsR1DgxIlBFrKuEAyyQ3IdWMlEtNZQsKj1p+z3YXAJT6C2u8RC3slyL11vMAH OvkOLwj56Nlib70Zezuevh/5R+KnzEipVrGosIbsZSmTUx32MR4ByRy8DMi8uNkt JEGSULErsfQEiCr1UsFnwO7d06bf+m0NvcvxTJYvWPBXOjMkTQja1cKnxdEtgoP5 Qg9MZKia3PqO6lQUHgIkRfcqutbuJ+IIuQJ8/oijD3zc198fuUurtiIis/2mjRQv 1Jd/sa52A4z3YFqQ4GyEJokzxFa3xwF4pIoO8NEf1nE1kvUid2gBfqpIfn+SlwBQ nEKtuFX8bXBV0y2Ze3tv =7Ac3 -----END PGP SIGNATURE----- --------------enig9D91E1E8CB10AE4177453556--

1 0

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

14 May '10

Michael Ströder wrote: > Howard Chu wrote: >> michael(a)stroeder.com wrote: >>> michael(a)stroeder.com wrote: >>>> I'd rather argue that for >>>> Samba 3 'sambaPwdLastSet' should be set. >>> >>> Uumpf! This is already set. Sorry for the noise. >>> >>>> 'shadowLastChange' is rather a POSIX account attribute which from my >>>> understanding is out-of-scope for slapo-smbk5pwd. Well, the scope >>>> could be >>>> extended... >>> >>> But still it's the question whether we want to have this functionality >>> for >>> various password-related attribute all in on overlay or whether there >>> should >>> be distinct overlays for each account type (posixAccount/shadowAccount, >>> sambaSAMAccount, Kerberos user). >> >> shadowAccount is deprecated. LDAP ppolicy already provides a >> pwdChangedTime attribute. > > 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. Anyone running LDAP clients (pam_ldap, nss_ldap) older than that has far worse problems to worry about. >> Ultimately both Kerberos and Samba will just be using LDAP ppolicy. > > Yes. But there is indeed a real need for a solution in the meantime... Yes, in the meantime both Heimdal and Samba use the smbPwdLastSet attribute which is already taken care of. This ITS will be closed. -- -- 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 14 May '10

14 May '10

Howard Chu wrote: > michael(a)stroeder.com wrote: >> michael(a)stroeder.com wrote: >>> I'd rather argue that for >>> Samba 3 'sambaPwdLastSet' should be set. >> >> Uumpf! This is already set. Sorry for the noise. >> >>> 'shadowLastChange' is rather a POSIX account attribute which from my >>> understanding is out-of-scope for slapo-smbk5pwd. Well, the scope >>> could be >>> extended... >> >> But still it's the question whether we want to have this functionality >> for >> various password-related attribute all in on overlay or whether there >> should >> be distinct overlays for each account type (posixAccount/shadowAccount, >> sambaSAMAccount, Kerberos user). > > shadowAccount is deprecated. LDAP ppolicy already provides a > pwdChangedTime attribute. 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. > Ultimately both Kerberos and Samba will just be using LDAP ppolicy. Yes. But there is indeed a real need for a solution in the meantime... Ciao, Michael.

1 0

Re: (ITS#6550) Patch for smbk5pwd slapd overlay to include shadowLastChange
by michael＠stroeder.com 14 May '10

14 May '10

Mark A. Ziesemer wrote: > 2010/5/14 Michael Ströder <michael(a)stroeder.com > <mailto:michael@stroeder.com>> > 'shadowLastChange' is rather a POSIX account attribute which from my > understanding is out-of-scope for slapo-smbk5pwd. Well, the scope could be > extended... > > I guess I wouldn't have any objections if all the references to "shadow" > were renamed to "posix". However, the shadowLastChange attribute is > part of the shadowAccount objectClass - with neither of these names > referring to POSIX. I didn't consider to change the name of the attribute. With POSIX account data I rather wanted to point to RFC 2307 where posixAccount and shadowAccount object classes and the accompanying attributes are defined. Don't get me wrong. I support the idea of setting shadowLastChange even if Howard considers it to be deprecated. And I have no objections to a one-sets-all-of-these overlay. But I'd even like to see this overlay available as standard feature. Since in the current state it has build dependencies to Kerberos libs this is not easy. Only building the Samba support is possible and needs some tweaking of the Makefile. > There are many issues posted online with all the password attributes > except shadowLastChange getting updated. This patch should provide a > solution for many of these cases. Yupp. I already thought these problems long ago when implementing the different password change use-cases in web2ldap. Ciao, Michael.

1 0

Re: (ITS#6550) Patch for smbk5pwd slapd overlay to include shadowLastChange
by online＠mark.ziesemer.com 14 May '10

14 May '10

--00504501586f17398e04868dddb7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 2010/5/14 Michael Str=F6der <michael(a)stroeder.com> > online(a)mark.ziesemer.com wrote: > > Full_Name: Mark A. Ziesemer > > Version: 2.4.21 / HEAD > > OS: Ubuntu Linux > > URL: ftp://ftp.openldap.org/incoming/smbk5pwd-shadow-b.patch > > Submission from: (NULL) (2001:470:1f11:3ae:dc54:73ba:be16:148) > > > > Using the PasswordModify Extended Operation (exop) along with the > smbk5pwd slapd > > overlay provides several benefits, but does not currently include the > > shadowLastChange attribute of the shadowAccount class. This means the > > shadowLastChange is missed from update, unless specially done along wit= h > a > > PasswordModify. > > While I agree that this could be useful in general I'd rather argue that > for > Samba 3 'sambaPwdLastSet' should be set. > sambaPwdLastSet is already handled by the "samba" portion of this overlay. 'shadowLastChange' is rather a POSIX account attribute which from my > understanding is out-of-scope for slapo-smbk5pwd. Well, the scope could b= e > extended... > I guess I wouldn't have any objections if all the references to "shadow" were renamed to "posix". However, the shadowLastChange attribute is part o= f the shadowAccount objectClass - with neither of these names referring to POSIX. I had considered a separate overlay. However, in terms of purpose, shared code, functionality, and performance, it seems to make the most sense to include this addition into the smbk5pwd overlay. Both pam_ldap and the Samba client support use of exop password changes. Additionally, pam_ldap doesn't appear to support hashing to SSHA (only MD5, which is also the default) - so setting to "exop" also allows for a stronge= r hash of the password to be stored. With the unpatched overlay, doing an exop password change updates userPassword (used by POSIX), as well as all the Samba attributes: sambaLMPassword, sambaNTPassword, and sambaPwdLastSet . This allows Samba clients to use the updated password as well as seeing when the password was last set, but POSIX clients do not see an updated shadowLastChange. This patch adds support for the otherwise missing shadowLastChange, keeping everything consistent. There are many issues posted online with all the password attributes except shadowLastChange getting updated. This patch should provide a solution for many of these cases. > Ciao, Michael. > -- Mark A. Ziesemer www.ziesemer.com --00504501586f17398e04868dddb7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote">2010/5/14 Michael Str=F6der &l= t;<a href=3D"mailto:michael@stroeder.com">michael(a)stroeder.com</a>></spa= n> <blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex;= border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> <a href=3D"mailto:online@mark.ziesemer.com">online(a)mark.ziesemer.com</a> wr= ote: > Full_Name: Mark A. Ziesemer > Version: 2.4.21 / HEAD > OS: Ubuntu Linux > URL: <a href=3D"ftp://ftp.openldap.org/incoming/smbk5pwd-shadow-b.patc= h" target=3D"_blank">ftp://ftp.openldap.org/incoming/smbk5pwd-shadow-b.patc= h</a> > Submission from: (NULL) (2001:470:1f11:3ae:dc54:73ba:be16:148) > > Using the PasswordModify Extended Operation (exop) along with the smbk= 5pwd slapd > overlay provides several benefits, but does not currently include the<= br> > shadowLastChange attribute of the shadowAccount class. =A0This means t= he > shadowLastChange is missed from update, unless specially done along wi= th a > PasswordModify. While I agree that this could be useful in general I'd rather argue tha= t for Samba 3 'sambaPwdLastSet' should be set. </blockquote><div> s= ambaPwdLastSet is already handled by the "samba" portion of this = overlay. </div><blockquote class=3D"gmail_quote" style=3D"margin: 0= pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: = 1ex;"> 'shadowLastChange' is rather a POSIX account attribute which from m= y understanding is out-of-scope for slapo-smbk5pwd. Well, the scope could be<= br> extended... </blockquote><div> I guess I wouldn't have any object= ions if all the references to "shadow" were renamed to "posi= x".=A0 However, the shadowLastChange attribute is part of the shadowAc= count objectClass - with neither of these names referring to POSIX. I had considered a separate overlay.=A0 However, in terms of purpose, s= hared code, functionality, and performance, it seems to make the most sense= to include this addition into the smbk5pwd overlay. Both pam_ldap a= nd the Samba client support use of exop password=20 changes.=A0 Additionally, pam_ldap doesn't appear to support hashing to= =20 SSHA (only MD5, which is also the default) - so setting to "exop"= also=20 allows for a stronger hash of the password to be stored. With the unpatched overlay, doing an exop password change updates userP= assword (used by POSIX), as well as all the Samba attributes: sambaLMPasswo= rd, sambaNTPassword, and sambaPwdLastSet .=A0 This allows Samba clients to = use the updated password as well as seeing when the password was last set, = but POSIX clients do not see an updated shadowLastChange.=A0 This patch add= s support for the otherwise missing shadowLastChange, keeping everything co= nsistent. =A0 There are many issues posted online with all the password attributes= except shadowLastChange getting updated.=A0 This patch should provide a so= lution for many of these cases. </div><blockquote class=3D"gmail_quo= te" style=3D"margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204= , 204); padding-left: 1ex;"> Ciao, Michael. </blockquote><div>=A0</div></div>-- Mark A. Ziesemer<b= r><a href=3D"http://www.ziesemer.com">www.ziesemer.com</a> --00504501586f17398e04868dddb7--

1 0

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

14 May '10

michael(a)stroeder.com wrote: > michael(a)stroeder.com wrote: >> I'd rather argue that for >> Samba 3 'sambaPwdLastSet' should be set. > > Uumpf! This is already set. Sorry for the noise. > >> 'shadowLastChange' is rather a POSIX account attribute which from my >> understanding is out-of-scope for slapo-smbk5pwd. Well, the scope could be >> extended... > > But still it's the question whether we want to have this functionality for > various password-related attribute all in on overlay or whether there should > be distinct overlays for each account type (posixAccount/shadowAccount, > sambaSAMAccount, Kerberos user). shadowAccount is deprecated. LDAP ppolicy already provides a pwdChangedTime attribute. > Personally I'd like to see this overlay moved from contrib/ into the standard > build. But for Kerberos-related attributes the build and schema dependencies > are an obstacle. => separate overlays at least for KDC/LDAP and Samba-Posix/LDAP. Ultimately both Kerberos and Samba will just be using LDAP ppolicy. But yes, the build dependencies are still annoying. -- -- 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 14 May '10

14 May '10

michael(a)stroeder.com wrote: > I'd rather argue that for > Samba 3 'sambaPwdLastSet' should be set. Uumpf! This is already set. Sorry for the noise. > 'shadowLastChange' is rather a POSIX account attribute which from my > understanding is out-of-scope for slapo-smbk5pwd. Well, the scope could be > extended... But still it's the question whether we want to have this functionality for various password-related attribute all in on overlay or whether there should be distinct overlays for each account type (posixAccount/shadowAccount, sambaSAMAccount, Kerberos user). Personally I'd like to see this overlay moved from contrib/ into the standard build. But for Kerberos-related attributes the build and schema dependencies are an obstacle. => separate overlays at least for KDC/LDAP and Samba-Posix/LDAP. Ciao, Michael.

1 0

Re: (ITS#6550) Patch for smbk5pwd slapd overlay to include shadowLastChange
by michael＠stroeder.com 14 May '10

14 May '10

online(a)mark.ziesemer.com wrote: > Full_Name: Mark A. Ziesemer > Version: 2.4.21 / HEAD > OS: Ubuntu Linux > URL: ftp://ftp.openldap.org/incoming/smbk5pwd-shadow-b.patch > Submission from: (NULL) (2001:470:1f11:3ae:dc54:73ba:be16:148) > > Using the PasswordModify Extended Operation (exop) along with the smbk5pwd slapd > overlay provides several benefits, but does not currently include the > shadowLastChange attribute of the shadowAccount class. This means the > shadowLastChange is missed from update, unless specially done along with a > PasswordModify. While I agree that this could be useful in general I'd rather argue that for Samba 3 'sambaPwdLastSet' should be set. 'shadowLastChange' is rather a POSIX account attribute which from my understanding is out-of-scope for slapo-smbk5pwd. Well, the scope could be extended... Ciao, Michael.

1 0

(ITS#6550) Patch for smbk5pwd slapd overlay to include shadowLastChange
by online＠mark.ziesemer.com 13 May '10

13 May '10

Full_Name: Mark A. Ziesemer Version: 2.4.21 / HEAD OS: Ubuntu Linux URL: ftp://ftp.openldap.org/incoming/smbk5pwd-shadow-b.patch Submission from: (NULL) (2001:470:1f11:3ae:dc54:73ba:be16:148) Using the PasswordModify Extended Operation (exop) along with the smbk5pwd slapd overlay provides several benefits, but does not currently include the shadowLastChange attribute of the shadowAccount class. This means the shadowLastChange is missed from update, unless specially done along with a PasswordModify. This patch adds support for updating shadowLastChange into the smbk5pwd overlay for slapd. An added benefit is that once the updated overlay is in effect, write access to the shadowLastChange attribute can optionally be restricted by configuration, preventing users from updating shadowLastChange without actually updating their password. The SHA-1 hash of the provided patch (smbk5pwd-shadow-b.patch) is c29ff518ea4fe03a4c5ee87d07a3af0082256950 . (Please discard "smbk5pwd-shadow.patch".) Patch was generated against HEAD just now, but also applies cleanly to 2.4.21. I am currently using the patched overlay in my current environment without noticeable issue. However, C is not current primary language, so please give appropriate attention to review. This patch file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch were developed by Mark A. Ziesemer <online(a)mark.ziesemer.com>. I have not assigned rights and/or interest in this work to any party. I, Mark A. Ziesemer, 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#6545) delta-syncrepl rejects modification master accepted
by masarati＠aero.polimi.it 13 May '10

13 May '10

I checked with HEAD and re24 (basically, 2.4.22 from CVS) and I couldn't reproduce the issue. Can you provide the configuration and an example LDIF that triggers the issue? I simply ran test043, restart both servers, and perform a modification similar to yours, and it went through with no problems. p. > 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#6545) delta-syncrepl rejects modification master accepted
by quanah＠zimbra.com 13 May '10

13 May '10

--On May 12, 2010 1:06:53 PM +0000 Frank.Swasey(a)uvm.edu wrote: > This is an OpenPGP/MIME signed message (RFC 2440 and 3156) > --------------enig666A26622E67D44DE6AFFA9C > Content-Type: text/plain; charset=ISO-8859-1 > Content-Transfer-Encoding: quoted-printable > > I see someone has tagged this as unreproducable in head/re24.=20 > > Ok.... Are you saying that 2.4.23 will not have this bug or that I did > something wrong in compiling 2.4.22???? Pierangelo made that note, but failed to follow up with the ITS in any way. Maybe he will be willing to provide more information, since RE24 and 2.4.22 are identical. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#6549) test043 hasSubordinates attribute inconsistencies
by mhardin＠symas.com 12 May '10

12 May '10

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

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

12 May '10

--00c09f76b87ebad978048667feb6 Content-Type: text/plain; charset=ISO-8859-1 On Wed, May 12, 2010 at 10:05 AM, Howard Chu <hyc(a)symas.com> wrote: > online(a)mark.ziesemer.com wrote: > >> 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 also happens when the connection manager queues up a thread to handle > a "socket is readable" event on a socket that's in the process of closing. > Pretty much unavoidable, when a lot of threads are active. I don't see this > as a high enough priority to warrant fixing. > This was not happening under a high load, but with only 1-2 connections active. I might not have focused on it enough in the original report, but isn't this looking like it is probably an issue with the libldap client library (provided by OpenLDAP), rather than the slapd daemon? Looking at the provided logs, it appears that no do_unbind request is received (not sent by the client) when using ldapi:/// with a bind DN. If it can't / won't be fixed, can the logging of the "connection_read(): no connection!" event in slapd at least be demoted to a lower level so that it doesn't fill the default logging output, without having to change the overall configured logging level and potentially missing other logged events that do require attention? > 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 >> >> >> > > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/ > -- Mark A. Ziesemer www.ziesemer.com --00c09f76b87ebad978048667feb6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote">On Wed, May 12, 2010 at 10:05 AM, Howard Chu <sp= an dir=3D"ltr"><<a href=3D"mailto:hyc@symas.com">hyc(a)symas.com</a>></= span> wrote: <blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt = 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> <a href=3D"mailto:online@mark.ziesemer.com" target=3D"_blank">online(a)mark.z= iesemer.com</a> wrote: <blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; borde= r-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> Full_Name: Mark A. Ziesemer Version: 2.4.21 OS: Ubuntu Linux 10.04 URL: <a href=3D"ftp://ftp.openldap.org/incoming/" target=3D"_blank">ftp://f= tp.openldap.org/incoming/</a> 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. =A0As stated at <a href=3D"http://www.openldap.org/lists/openldap-software/200811/msg00079.= html" target=3D"_blank">http://www.openldap.org/lists/openldap-software/200= 811/msg00079.html</a> , this is apparently not a problem with slapd, but a client that is disconnecting wit= hout first unbinding. </blockquote> This also happens when the connection manager queues up a thread to handle = a "socket is readable" event on a socket that's in the proces= s of closing. Pretty much unavoidable, when a lot of threads are active. I = don't see this as a high enough priority to warrant fixing. </blockquote><div> This was not happening under a high load, but with on= ly 1-2 connections active. I might not have focused on it enough in = the original report, but isn't this looking like it is probably an issu= e with the libldap client library (provided by OpenLDAP), rather than the s= lapd daemon?=A0 Looking at the provided logs, it appears that no do_unbind = request is received (not sent by the client) when using ldapi:/// with a bi= nd DN. If it can't / won't be fixed, can the logging of the "conn= ection_read(): no connection!" event in slapd at least be demoted to a= lower level so that it doesn't fill the default logging output, withou= t having to change the overall configured logging level and potentially mis= sing other logged events that do require attention? =A0 </div><blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex;= border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><blockquote= class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; border-left: 1px= solid rgb(204, 204, 204); padding-left: 1ex;"> This appears to be an issue with the libldap client library provided by Ope= nLDAP itself (2.4.21), and not the slapd daemon. Issue is reproducible even by just using "ldapsearch -H ldapi:///&quot= ;, 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. =A0Note 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=3D0+uidNumber=3D0,cn=3Dpeercred,cn=3Dexternal,cn= =3Dauth SASL SSF: 0 No such object (32) slap_listener_activate(9): <blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; borde= r-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><blockquote class= =3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid= rgb(204, 204, 204); padding-left: 1ex;"> <blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; borde= r-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> slap_listener(ldapi:///) </blockquote></blockquote></blockquote> connection_get(14): got connid=3D1000 connection_read(14): checking for input on id=3D1000 ber_get_next ber_get_next: tag 0x30 len 24 contents: op tag 0x60, time 1273546410 ber_get_next conn=3D1000 op=3D0 do_bind ber_scanf fmt ({imt) ber: ber_scanf fmt ({m) ber: ber_scanf fmt (m) ber: ber_scanf fmt (}}) ber: <blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; borde= r-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><blockquote class= =3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid= rgb(204, 204, 204); padding-left: 1ex;"> <blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; borde= r-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> dnPrettyNormal:<> </blockquote></blockquote></blockquote> <<< =A0dnPrettyNormal:<>,<> do_bind: dn () SASL mech EXTERNAL =3D=3D>slap_sasl2dn: converting SASL name gidNumber=3D0+uidNumber=3D0,cn=3Dpeercred,cn=3Dexternal,cn=3Dauth to a DN<b= r> <=3D=3Dslap_sasl2dn: Converted SASL name to<nothing> SASL Authorize [conn=3D1000]: =A0proxy authorization allowed authzDN=3D&quo= t;" send_ldap_sasl: err=3D0 len=3D-1 do_bind: SASL/EXTERNAL bind: dn=3D"gidNumber=3D0+uidNumber=3D0,cn=3Dpeercred,cn=3Dexternal,cn=3Daut= h" sasl_ssf=3D0 send_ldap_response: msgid=3D1 tag=3D97 err=3D0 ber_flush2: 14 bytes to sd 14 <=3D=3D slap_sasl_bind: rc=3D0 connection_get(14): got connid=3D1000 connection_read(14): checking for input on id=3D1000 ber_get_next ber_get_next: tag 0x30 len 37 contents: op tag 0x63, time 1273546410 ber_get_next conn=3D1000 op=3D1 do_search ber_scanf fmt ({miiiib) ber: <blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; borde= r-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><blockquote class= =3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid= rgb(204, 204, 204); padding-left: 1ex;"> <blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; borde= r-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> dnPrettyNormal:<> </blockquote></blockquote></blockquote> <<< =A0dnPrettyNormal:<>,<> ber_scanf fmt (m) ber: ber_scanf fmt ({M}}) ber: send_ldap_result: conn=3D1000 op=3D1 p=3D3 send_ldap_response: msgid=3D2 tag=3D101 err=3D32 ber_flush2: 14 bytes to sd 14 connection_get(14): got connid=3D1000 connection_read(14): checking for input on id=3D1000 ber_get_next ber_get_next: tag 0x30 len 5 contents: op tag 0x42, time 1273546410 ber_get_next conn=3D1000 op=3D2 do_unbind connection_close: conn=3D1000 sd=3D14 $ ldapsearch -H ldapi:/// -D "cn=3Dadmin,dc=3Dexample,dc=3Dcom" -= b "" -W Enter LDAP Password: ldap_bind: Invalid credentials (49) slap_listener_activate(9): <blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; borde= r-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><blockquote class= =3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid= rgb(204, 204, 204); padding-left: 1ex;"> <blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; borde= r-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> slap_listener(ldapi:///) </blockquote></blockquote></blockquote> connection_get(14): got connid=3D1001 connection_read(14): checking for input on id=3D1001 ber_get_next ber_get_next: tag 0x30 len 44 contents: op tag 0x60, time 1273546420 ber_get_next conn=3D1001 op=3D0 do_bind ber_scanf fmt ({imt) ber: ber_scanf fmt (m}) ber: <blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; borde= r-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><blockquote class= =3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid= rgb(204, 204, 204); padding-left: 1ex;"> <blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; borde= r-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> dnPrettyNormal:<cn=3Dadmin,dc=3Dexample,dc=3Dcom> </blockquote></blockquote></blockquote> <<< =A0dnPrettyNormal:<cn=3Dadmin,dc=3Dexample,dc=3Dcom>,&lt= ;cn=3Dadmin,dc=3Dexample,dc=3Dcom> do_bind: version=3D3 dn=3D"cn=3Dadmin,dc=3Dexample,dc=3Dcom" meth= od=3D128 send_ldap_result: conn=3D1001 op=3D0 p=3D3 send_ldap_response: msgid=3D1 tag=3D97 err=3D49 ber_flush2: 14 bytes to sd 14 connection_get(14): got connid=3D1001 connection_read(14): checking for input on id=3D1001 ber_get_next ber_get_next on fd 14 failed errno=3D0 (Success) connection_close: conn=3D1001 sd=3D14 connection_read(14): no connection! connection_read(14): no connection! $ ldapsearch -H ldap:/// -D "cn=3Dadmin,dc=3Dexample,dc=3Dcom" -b= "" -W Enter LDAP Password: ldap_bind: Invalid credentials (49) slap_listener_activate(8): <blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; borde= r-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><blockquote class= =3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid= rgb(204, 204, 204); padding-left: 1ex;"> <blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; borde= r-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> slap_listener(ldap:///) </blockquote></blockquote></blockquote> connection_get(14): got connid=3D1002 connection_read(14): checking for input on id=3D1002 ber_get_next ber_get_next: tag 0x30 len 44 contents: op tag 0x60, time 1273546425 ber_get_next conn=3D1002 op=3D0 do_bind ber_scanf fmt ({imt) ber: ber_scanf fmt (m}) ber: <blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; borde= r-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><blockquote class= =3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid= rgb(204, 204, 204); padding-left: 1ex;"> <blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; borde= r-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> dnPrettyNormal:<cn=3Dadmin,dc=3Dexample,dc=3Dcom> </blockquote></blockquote></blockquote> <<< =A0dnPrettyNormal:<cn=3Dadmin,dc=3Dexample,dc=3Dcom>,&lt= ;cn=3Dadmin,dc=3Dexample,dc=3Dcom> do_bind: version=3D3 dn=3D"cn=3Dadmin,dc=3Dexample,dc=3Dcom" meth= od=3D128 send_ldap_result: conn=3D1002 op=3D0 p=3D3 send_ldap_response: msgid=3D1 tag=3D97 err=3D49 ber_flush2: 14 bytes to sd 14 connection_get(14): got connid=3D1002 connection_read(14): checking for input on id=3D1002 ber_get_next ber_get_next on fd 14 failed errno=3D0 (Success) connection_close: conn=3D1002 sd=3D14 </blockquote> -- =A0-- Howard Chu =A0CTO, Symas Corp. =A0 =A0 =A0 =A0 =A0 <a href=3D"http://www.symas.com" t= arget=3D"_blank">http://www.symas.com</a> =A0Director, Highland Sun =A0 =A0 <a href=3D"http://highlandsun.com/hyc/" = target=3D"_blank">http://highlandsun.com/hyc/</a> =A0Chief Architect, OpenLDAP =A0<a href=3D"http://www.openldap.org/project= /" target=3D"_blank">http://www.openldap.org/project/</a> </blockquote></div> -- Mark A. Ziesemer <a href=3D"http://www.zies= emer.com">www.ziesemer.com</a> --00c09f76b87ebad978048667feb6--

1 0

Re: (ITS#6548) Many "connection_read(): no connection!" warnings when using ldapi:/// and a bind DN (no external authentication)
by hyc＠symas.com 12 May '10

12 May '10

online(a)mark.ziesemer.com wrote: > 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 also happens when the connection manager queues up a thread to handle a "socket is readable" event on a socket that's in the process of closing. Pretty much unavoidable, when a lot of threads are active. I don't see this as a high enough priority to warrant fixing. > 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 > > -- -- 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#6545) delta-syncrepl rejects modification master accepted
by Frank.Swasey＠uvm.edu 12 May '10

12 May '10

This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig666A26622E67D44DE6AFFA9C Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I see someone has tagged this as unreproducable in head/re24.=20 Ok.... Are you saying that 2.4.23 will not have this bug or that I did something wrong in compiling 2.4.22???? --=20 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) --------------enig666A26622E67D44DE6AFFA9C Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.14 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJL6qe8AAoJEK5S4SsZ5NvSFWcQAJJ3SvQyoD+Te4dvxJghyF44 FlOv9y6hi9vWw6fHcPJlvKBY6ZCgJoq7QeWjYXhYCk8643Yq7HRA0q3TtADwRw08 8UObJjrNoABII3QHuta7wQWNC6xKoGRUd17hzTDTZAv2AH8lMYRQPjpUKNOXAE1G gaVOcIEM5ZHTX3y1uusu5xUbEVc/t8YlDRMIzDBukyLJaPO+/Aqy+adhpEkdULV3 1K3AlcrQDZWiD6TeWd1xIPGtrNaW1poHKIDa7ziU75D/8GQdP4FIDxwb83wQUbwi 5ZjYD0jjtoRqSvaprRL5GUPrq/s9E5ccqlPsjaVUoalHc3/VoMMpFWYewE2P/b5e R89U9kHKkimFOUROyC4gS/cI9SiNhL0L9TOryUAE4JUG1PEGiAHEYoxxRQj8Cmk0 7OcVTNLS5Jtyx3MRCqds2CSfNL71rXJxJok6n/1OlZvkx4E7GlVXWxmWs7o9uL5P GsYHlbTiWH08NoEb5cejOekALV6p8OY8gXLYSvxslc0p4a5HTAQI6ozwMhAY1JNS 0hZAG7cOTsBcmoNsF1Vf2DQbkZ68je6N/Hz75QfBJgzkFvd/kqadpIwu3yCljCEo eZal5tkC5CcmcPNOIndxPgyMrafX7CogSvZ80cPGlwWd8rBL7rAccBO7JjGhf9dM 9X57ftTkOpZzsi1/oA+q =sb/D -----END PGP SIGNATURE----- --------------enig666A26622E67D44DE6AFFA9C--

1 0

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

10 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

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs