openldap-bugs

openldap-bugs@openldap.org

1 participants
21001 discussions

Re: (ITS#6831) Proxycache database corruption
by ryans＠aweber.com 21 Feb '11

21 Feb '11

I just uploaded two log file snippets for consideration. One is a failed query to the proxycache database exhibiting this problem, and the other is a successful query to the proxycache database. A gzipp'ed tarball can be found here: ftp://ftp.openldap.org/incoming/ryan-steele-110221.proxycache-logs-for-comp…. Up until the point where the unsuccessful query fails to read the key for the UID equality candidate, both the failed query and the successful query are locking the same exact QC index (0x7f50429860f0), trying to fetch the exact same keys ([b49d1940], [807e234d], [8f951c4a]), and comparing the same equality/filter/list candidates ("id=9, first=2699, last=2731"). This is what I would expect, since the values for the two objectClasses in the search filter are the same. However, once it gets to the point where it compares the bdb_equality_candidates for the UID, the values of the bdb_filter_candidates, bdb_equality_candidates, and bdb_list_candidates in logs for the unsuccessful query are a little confusing. I gather that a value of "0" for id/first/last is normal when it cannot find the index in question (as it does for the UID value that it said was "ANSWERABLE" but was unable to find), but the "first=2" and "first=2699" values seem a little strange, especially since the "first=2699" value supposedly matches the bdb_equality_candidates value found at one of the indices for the objectClass searches. I have no idea where the value "2" comes from, but it too seems out of place if it couldn't find the index. Perhaps those values make more sense in the context where it thought it *could* find the values, but then wasn't able to (though I admit that sounds like a pretty big stretch). ## UID portion of unsuccessful query Feb 21 10:02:00 blog2 slapd[18797]: bdb_idl_fetch_key: [8f951c4a] Feb 21 10:02:00 blog2 slapd[18797]: <= bdb_index_read 9 candidates Feb 21 10:02:00 blog2 slapd[18797]: <= bdb_equality_candidates: id=9, first=2699, last=2731 Feb 21 10:02:00 blog2 slapd[18797]: <= bdb_filter_candidates: id=9 first=2699 last=2731 Feb 21 10:02:00 blog2 slapd[18797]: <= bdb_list_candidates: id=9 first=2699 last=2731 Feb 21 10:02:00 blog2 slapd[18797]: <= bdb_filter_candidates: id=9 first=2699 last=2731 Feb 21 10:02:00 blog2 slapd[18797]: => bdb_filter_candidates Feb 21 10:02:00 blog2 slapd[18797]: EQUALITY Feb 21 10:02:00 blog2 slapd[18797]: => bdb_equality_candidates (uid) Feb 21 10:02:00 blog2 slapd[18797]: => key_read Feb 21 10:02:00 blog2 slapd[18797]: bdb_idl_fetch_key: [efb8b856] Feb 21 10:02:00 blog2 slapd[18797]: <= bdb_equality_candidates: id=0, first=0, last=0 Feb 21 10:02:00 blog2 slapd[18797]: <= bdb_filter_candidates: id=0 first=0 last=0 Feb 21 10:02:00 blog2 slapd[18797]: <= bdb_list_candidates: id=0 first=2699 last=0 Feb 21 10:02:00 blog2 slapd[18797]: <= bdb_filter_candidates: id=0 first=2699 last=0 Feb 21 10:02:00 blog2 slapd[18797]: <= bdb_list_candidates: id=0 first=0 last=0 Feb 21 10:02:00 blog2 slapd[18797]: <= bdb_filter_candidates: id=0 first=0 last=0 Feb 21 10:02:00 blog2 slapd[18797]: <= bdb_list_candidates: id=0 first=2 last=0 Feb 21 10:02:00 blog2 slapd[18797]: <= bdb_filter_candidates: id=0 first=2 last=0 Feb 21 10:02:00 blog2 slapd[18797]: bdb_search_candidates: id=0 first=2 last=0 Feb 21 10:02:00 blog2 slapd[18797]: hdb_search: no candidates ## UID portion of successful query Feb 21 10:06:22 blog2 slapd[18797]: bdb_idl_fetch_key: [8f951c4a] Feb 21 10:06:22 blog2 slapd[18797]: <= bdb_index_read 9 candidates Feb 21 10:06:22 blog2 slapd[18797]: <= bdb_equality_candidates: id=9, first=2699, last=2731 Feb 21 10:06:22 blog2 slapd[18797]: <= bdb_filter_candidates: id=9 first=2699 last=2731 Feb 21 10:06:22 blog2 slapd[18797]: <= bdb_list_candidates: id=9 first=2699 last=2731 Feb 21 10:06:22 blog2 slapd[18797]: <= bdb_filter_candidates: id=9 first=2699 last=2731 Feb 21 10:06:22 blog2 slapd[18797]: => bdb_filter_candidates Feb 21 10:06:22 blog2 slapd[18797]: EQUALITY Feb 21 10:06:22 blog2 slapd[18797]: => bdb_equality_candidates (uid) Feb 21 10:06:22 blog2 slapd[18797]: => key_read Feb 21 10:06:22 blog2 slapd[18797]: bdb_idl_fetch_key: [ea38ed84] Feb 21 10:06:22 blog2 slapd[18797]: <= bdb_index_read 1 candidates Feb 21 10:06:22 blog2 slapd[18797]: <= bdb_equality_candidates: id=1, first=2701, last=2701 Feb 21 10:06:22 blog2 slapd[18797]: <= bdb_filter_candidates: id=1 first=2701 last=2701 Feb 21 10:06:22 blog2 slapd[18797]: <= bdb_list_candidates: id=1 first=2701 last=2701 Feb 21 10:06:22 blog2 slapd[18797]: <= bdb_filter_candidates: id=1 first=2701 last=2701 Feb 21 10:06:22 blog2 slapd[18797]: <= bdb_list_candidates: id=1 first=2701 last=2701 Feb 21 10:06:22 blog2 slapd[18797]: <= bdb_filter_candidates: id=1 first=2701 last=2701 Feb 21 10:06:22 blog2 slapd[18797]: <= bdb_list_candidates: id=1 first=2701 last=2701 Feb 21 10:06:22 blog2 slapd[18797]: <= bdb_filter_candidates: id=1 first=2701 last=2701 Feb 21 10:06:22 blog2 slapd[18797]: bdb_search_candidates: id=1 first=2701 last=2701 Feb 21 10:06:22 blog2 slapd[18797]: => test_filter I unfortunately don't have enough knowledge about what's going here, or where things go awry in the codebase, to abstract something more meaningful from these logs, but hopefully this provides a little bit of framing/contextual information to someone else that does.

1 0

Re: (ITS#6837) slapd doesn't start anymore after adding olcChainDatabase
by hyc＠symas.com 19 Feb '11

19 Feb '11

masarati(a)aero.polimi.it wrote: > >> The cleanest solution would probably be to make olcChainDatabase >> structural, >> copying all of the attributes of olcLDAPConfig into it, and dropping >> olcLDAPConfig itself from this situation. Too bad changing that now would >> break existing deployments. > >> From a protocol point of view, olcChainDatabase could be derived from > olcLDAPConfig; at this point the two could coexist in existing > deployments. back-config could take care of objectClass inheritance while > selecting configuration tables. back-config already uses inheritance to order the objectClasses. But I think it may be happening too late to address this. Still looking, probably a simple fix in that case. -- -- 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#6837) slapd doesn't start anymore after adding olcChainDatabase
by masarati＠aero.polimi.it 19 Feb '11

19 Feb '11

> The cleanest solution would probably be to make olcChainDatabase > structural, > copying all of the attributes of olcLDAPConfig into it, and dropping > olcLDAPConfig itself from this situation. Too bad changing that now would > break existing deployments. >From a protocol point of view, olcChainDatabase could be derived from olcLDAPConfig; at this point the two could coexist in existing deployments. back-config could take care of objectClass inheritance while selecting configuration tables. p.

1 0

Re: (ITS#6837) slapd doesn't start anymore after adding olcChainDatabase
by hyc＠symas.com 19 Feb '11

19 Feb '11

rhafer(a)suse.de wrote: > Full_Name: Ralf Haferkamp > Version: RE24, HEAD > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (89.166.243.151) > > > After adding the following LDIF to cn=config (via ldapadd), slapd does not start > anymore: > ------------------------------------ > dn: olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config > objectclass: olcChainConfig > > dn: olcDatabase={0}ldap,olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config > objectclass: olcLDAPConfig > objectclass: olcChainDatabase > olcDbUri: ldap://ldap.server > olcDatbase: {0}ldap > ------------------------------------ > > To add some fun. Everything works as expected if I reorder the "objectClass" > Values so that "olcLDAPConfig" appears after "olcChainDatabase". > > Additionally the error messages I get in the log when slapd fails to start with > the above config seem to be completely unrelated: > ------ > olcRootPW: value #0:<olcRootPW> can only be set when rootdn is under suffix > config error processing olcDatabase={0}config,cn=config:<olcRootPW> can only be > set when rootdn is under suffix > ------ > > The underlying problem seems to be that, when the "olcLDAPConfig" objectclass > appears first slapd seems to choose the wrong ConfigTable for the olcDatabase > attribute of the olcChainDatabase object. Instead of using olcDatabaseDummy as > defined in back-ldap/chain.c it uses the "normal" ConfigTable and starts up the > LDAP Database as if it were in "normal" database, including adding it to the > backendDB list. As I configured the chain overlay as a global overlay this > back-ldap database is put to the front of the backendDB list leading to problems > when initializing the cn=config database itself, because the code assumes that > the config database is always the first one, which will than lead to the strange > error message above. > > (... that's how far I got with analyzing the problem, I have no idea yet how to > fix it though. Suggestions are welcome.) > The cleanest solution would probably be to make olcChainDatabase structural, copying all of the attributes of olcLDAPConfig into it, and dropping olcLDAPConfig itself from this situation. Too bad changing that now would break existing deployments. I'll look into this some more. -- -- 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#6839) Expanded documentation for ldapi: and SASL EXTERNAL
by hyc＠symas.com 18 Feb '11

18 Feb '11

Andrew Findlay wrote: > On Thu, Feb 17, 2011 at 04:21:35PM -0800, Howard Chu wrote: > >>> URL: ftp://ftp.openldap.org/incoming/afindlay-slapi-doc-patch-20110217a > >> This patch fails to apply to HEAD. Please re-read the contributing >> guidelines; all patches must be against HEAD. > > It applies perfectly to the copy of HEAD that I downloaded this > morning: Strange. Must have had some end-of-line issues here. re: TLS Authentication Identity Format Strictly speaking, the order of components is not changed at all. The sequence of RDNs in the DN is what it is; just that the convention for *displaying* it is ass-backwards in LDAP. I'm afraid the wording here will confuse people into thinking that the *semantics* of the DN are changed, when it's only a display issue. > andrew@slab:~/src/openldap-head> cvs -z3 checkout -P -rHEAD openldap > ... much logging deleted ... > andrew@slab:~/src/openldap-head> cd openldap > andrew@slab:~/src/openldap-head/openldap> patch -b -p0< ../afindlay-slapi-doc-patch-20110217a > patching file doc/man/man8/slapd.8 > patching file doc/guide/admin/runningslapd.sdf > patching file doc/guide/admin/sasl.sdf > patching file doc/guide/preamble.sdf > > Andrew -- -- 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#6838) TLS client will not accept certificate for 'localhost'
by Kurt＠OpenLDAP.org 18 Feb '11

18 Feb '11

And, for the OP, I suggest issuing your test certificates for the FQDN = "test" and then setting up name service to resolve this to local host. = Using "test" indicates that the scope of name is limited to some = infrastructure used for testing (and is not a name used on the public = Internet). -- Kurt=

1 0

Re: (ITS#6838) TLS client will not accept certificate for 'localhost'
by Kurt＠OpenLDAP.org 18 Feb '11

18 Feb '11

On Feb 18, 2011, at 9:37 AM, hyc(a)symas.com wrote: > Closing this ITS. It's not a regression and not a bug, just a long = established=20 > feature. Right, the bug is listing non-fully-qualified names as subjects in the = certificate. So, generally speaking, subject names checks fail, as they should fail, = when the asserted name is not fully-qualified. The intent of the code is avoid always failing when the = non-fully-qualified asserted name can be securely transformed into a = fully-qualified name. This is a feature. -- Kurt=

1 0

Re: (ITS#6838) TLS client will not accept certificate for 'localhost'
by hyc＠symas.com 18 Feb '11

18 Feb '11

rhafer(a)suse.de wrote: > Am Freitag 18 Februar 2011, 13:17:17 schrieb > andrew.findlay(a)skills-1st.co.uk: >> On Fri, Feb 18, 2011 at 12:30:25AM +0000, hyc(a)symas.com wrote: >>> Used to work - since when, what release, what else has changed since >>> then? >> >> Unfortunately I cannot tell you exactly when this changed. In any >> case, the change only affects a different bug which was masking the >> problem that I now see. >> >> I do know that 2.3.32 as shipped with SLES 10.3 masks the problem by >> not checking the server certificate properly. So does 2.4.12 as >> shipped with OpenSuSE 11.1. Both will allow ldapsearch -ZZ to connect >> to *any* TLS-capable server if they do *not* have access to the CA >> certificate. >> >> 2.4.24 built on OpenSuSE 11.3 (i.e. using OpenSSL 1.0) correctly >> refuses to connect if there is no CA cert. > Yes, older openSUSE releases used a bad (i.e. less secure) default for > the TLS_REQCERT setting. That's why you never ran into the problem before > :/ Sigh... Apparently nobody reads the part of the doc that says "there is no good reason to change this from the libldap default." >> All versions that I have tested (certainly back to 2.3.32) incorrectly >> fail to connect when the URL is ldap://localhost:1389/ and a CA cert >> is provided. > Yes, AFAIK libldap's behavior of trying to figure out the machines real > hostname when connecting to localhost and using that hostname to verify > the server's certificate is there since quite some time already. It will > only verify against "localhost" when it completely fails to get the > machines' real name. I always considered that a feature more than a bug. Agreed. Server certs are supposed to carry the host's FQDN. "localhost" is just a magic alias; in a cert it shouldn't be anywhere other than a subjectAltName. >>> I'll note that I just tested some localhost certs a few days ago and > they were >>> fine, and the cert verification code hasn't changed in quite a long > time. >>> >>> (E.g., ITS#6711 the test setup there uses localhost with no problem.) > But if I see it correctly it sets "TLSVerifyClient allow" on the master > and "tls_reqcert=never" on the consumer. So it doesn't really verify the > certificates. (I might have overlooked something, took only a brief > glance at it). Ah, that sounds familiar. Closing this ITS. It's not a regression and not a bug, just a long established feature. -- -- 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#6838) TLS client will not accept certificate for 'localhost'
by rhafer＠suse.de 18 Feb '11

18 Feb '11

Am Freitag 18 Februar 2011, 13:17:17 schrieb andrew.findlay(a)skills-1st.co.uk: > On Fri, Feb 18, 2011 at 12:30:25AM +0000, hyc(a)symas.com wrote: > > Used to work - since when, what release, what else has changed since > > then? > > Unfortunately I cannot tell you exactly when this changed. In any > case, the change only affects a different bug which was masking the > problem that I now see. > > I do know that 2.3.32 as shipped with SLES 10.3 masks the problem by > not checking the server certificate properly. So does 2.4.12 as > shipped with OpenSuSE 11.1. Both will allow ldapsearch -ZZ to connect > to *any* TLS-capable server if they do *not* have access to the CA > certificate. > > 2.4.24 built on OpenSuSE 11.3 (i.e. using OpenSSL 1.0) correctly > refuses to connect if there is no CA cert. Yes, older openSUSE releases used a bad (i.e. less secure) default for the TLS_REQCERT setting. That's why you never ran into the problem before :/ > All versions that I have tested (certainly back to 2.3.32) incorrectly > fail to connect when the URL is ldap://localhost:1389/ and a CA cert > is provided. Yes, AFAIK libldap's behavior of trying to figure out the machines real hostname when connecting to localhost and using that hostname to verify the server's certificate is there since quite some time already. It will only verify against "localhost" when it completely fails to get the machines' real name. I always considered that a feature more than a bug. > > I'll note that I just tested some localhost certs a few days ago and they were > > fine, and the cert verification code hasn't changed in quite a long time. > > > > (E.g., ITS#6711 the test setup there uses localhost with no problem.) But if I see it correctly it sets "TLSVerifyClient allow" on the master and "tls_reqcert=never" on the consumer. So it doesn't really verify the certificates. (I might have overlooked something, took only a brief glance at it). Ralf

1 0

Re: (ITS#6838) TLS client will not accept certificate for 'localhost'
by andrew.findlay＠skills-1st.co.uk 18 Feb '11

18 Feb '11

On Fri, Feb 18, 2011 at 12:30:25AM +0000, hyc(a)symas.com wrote: > Used to work - since when, what release, what else has changed since then? Unfortunately I cannot tell you exactly when this changed. In any case, the change only affects a different bug which was masking the problem that I now see. I do know that 2.3.32 as shipped with SLES 10.3 masks the problem by not checking the server certificate properly. So does 2.4.12 as shipped with OpenSuSE 11.1. Both will allow ldapsearch -ZZ to connect to *any* TLS-capable server if they do *not* have access to the CA certificate. 2.4.24 built on OpenSuSE 11.3 (i.e. using OpenSSL 1.0) correctly refuses to connect if there is no CA cert. All versions that I have tested (certainly back to 2.3.32) incorrectly fail to connect when the URL is ldap://localhost:1389/ and a CA cert is provided. > I'll note that I just tested some localhost certs a few days ago and they were > fine, and the cert verification code hasn't changed in quite a long time. > > (E.g., ITS#6711 the test setup there uses localhost with no problem.) Hmm - that seems to be server-to-server. My problem is with the client tools, so maybe a different code-path is used. I have put a small test case here: ftp://ftp.openldap.org/incoming/afindlay-localhost-tls-test-20110218.tgz The server cert is valid for 'localhost' and also for '127.0.0.1' The tests are: sh 1-plain Plain LDAP connection - no problems Connects to ldap://localhost:1389/ sh 2-tls-no-ca With TLS but client has no access to the CA cert so this should fail with a complaint about 'self-signed certificate' sh 3-tls-with-ca With TLS and access to the CA cert. Connects to ldap://localhost:1389/ This should succeed but it does not. sh 4-tls-with-ca-numeric With TLS and access to the CA cert. This one uses ldap://127.0.0.1:1389/ and succeeds. Andrew -- ----------------------------------------------------------------------- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/ +44 1628 782565 | -----------------------------------------------------------------------

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