openldap-bugs

openldap-bugs@openldap.org

1 participants
20967 discussions

(ITS#6839) Expanded documentation for ldapi: and SASL EXTERNAL
by andrew.findlay＠skills-1st.co.uk 17 Feb '11

17 Feb '11

Full_Name: Andrew Findlay Version: 2.4.24 OS: OpenSuSE 11.3 URL: ftp://ftp.openldap.org/incoming/afindlay-slapi-doc-patch-20110217a Submission from: (NULL) (88.97.25.132) This documentation patch affects the Admin Guide and one manpage. It gives information about the ldapi: transport and the use of SASL EXTERNAL with it. The SASL EXTERNAL section also contains a small expansion on the use of TLS.

1 0

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

17 Feb '11

Full_Name: Andrew Findlay Version: 2.4.24 OS: OpenSuSE 11.3 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (88.97.25.132) For various test and teaching purposes I have a set of OpenLDAP configs that run small servers intended for local access only. As I run these on a wide variety of machines and also give them to students to run on their own machines, all the LDAP clients are set up to access the servers via the loopback interface: typically ldap://localhost:1389/ Some of the configs use TLS. I have a local CA which issues simple server certs, usually with 'CN=localhost' as part of the subject name. Since upgrading the OS and OpenLDAP version of my main test environment I find that TLS connections are failing: > ldapsearch -d 768 -x -ZZ -H ldap://localhost:1389/ -b dc=example,dc=org sn=trott TLS: hostname (slab.skills-1st.co.uk) does not match common name in certificate (localhost). ldap_start_tls: Connect error (-11) additional info: TLS: hostname does not match CN in peer certificate slab.skills-1st.co.uk is indeed the name of the machine, but I asked to connect to 'localhost' so that is the name that should be checked against the certificate. If I put in any other alias for localhost in /etc/hosts and issue a certificate for that, the connection is OK so the problem is specific to the string 'localhost', not to the use of the loopback interface in general. I think the problem is in tlso_session_chkhost() in tls_o.c: if( ldap_int_hostname && ( !name_in || !strcasecmp( name_in, "localhost" ) ) ) { name = ldap_int_hostname; } else { name = name_in; } If I understand this correctly, the intention appears to be to allow a certificate issued for the FQDN of the machine to be accepted when it is presented on the loopback interface. This may be a reasonable thing to do, but the current implementation prevents the use of a certificate issued specifically for 'localhost'. My client scripts used to work: I think this was purely because earlier versions of the TLS client code were less careful about checking certificates. Specifically, the 'self signed certificate in certificate chain' error was not even reported unless client-side debugging was turned on.

1 0

(ITS#6837) slapd doesn't start anymore after adding olcChainDatabase
by rhafer＠suse.de 17 Feb '11

17 Feb '11

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.)

1 0

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

17 Feb '11

I believe this may be the same issue as in #6217, given this behavior with two users which have the same objectclasses, same attributes, and differ only in the attribute values (e.g., their name, phone number, and so on): The initial query, where one entry doesn't get returned as it should: ===================================================================== bash:~# ldapsearch -x -H ldaps://localhost -LLL -b ou=Users,dc=example,dc=com '(&(|(objectClass=examplecomEmployee)(objectClass=examplecomUtilityUser))(uid=jdoe1))' uid dn: uid=jdoe1,ou=Users,dc=example,dc=com uid: jdoe1 bash:~# ldapsearch -x -H ldaps://localhost -LLL -b ou=Users,dc=example,dc=com '(&(|(objectClass=examplecomEmployee)(objectClass=examplecomUtilityUser))(uid=jdoe2))' uid If I reverse the filter, I get the expected results: ===================================================================== bash:~# ldapsearch -x -H ldaps://localhost -LLL -b ou=Users,dc=example,dc=com '(&(|(objectClass=examplecomUtilityUser)(objectClass=examplecomEmployee))(uid=jdoe1))' uid dn: uid=jdoe1,ou=Users,dc=example,dc=com uid: jdoe1 bash:~# ldapsearch -x -H ldaps://localhost -LLL -b ou=Users,dc=example,dc=com '(&(|(objectClass=examplecomUtilityUser)(objectClass=examplecomEmployee))(uid=jdoe2))' uid dn: uid=jdoe2,ou=Users,dc=example,dc=com uid: jdoe2 Furthermore, if I now try the first query again, it too works: ===================================================================== bash:~# ldapsearch -x -H ldaps://localhost -LLL -b ou=Users,dc=example,dc=com '(&(|(objectClass=examplecomEmployee)(objectClass=examplecomUtilityUser))(uid=jdoe1))' uid dn: uid=jdoe1,ou=Users,dc=example,dc=com uid: jdoe1 bash:~# ldapsearch -x -H ldaps://localhost -LLL -b ou=Users,dc=example,dc=com '(&(|(objectClass=examplecomEmployee)(objectClass=examplecomUtilityUser))(uid=jdoe2))' uid dn: uid=jdoe2,ou=Users,dc=example,dc=com uid: jdoe2 I already have the patch for ITS#5756 applied in all the versions I've tested (2.4.17, 2.4.21, and 2.4.23). I can provide a sample database which exhibits this behavior if needed, as I am working on providing a self-contained sanitized example already. If the developers agree that the issue described in these two ITS's are one and the same, I'm fine with marking this bug as a duplicate of ITS#6217 to avoid fragmentation of debugging efforts.

1 0

Re: (ITS#6217) proxycache not returning cached data
by ryans＠aweber.com 17 Feb '11

17 Feb '11

hyc(a)symas.com wrote: > > ryans(a)aweber.com wrote: > > I am experiencing what appears to be the same issue, and opened a > > ticket - http://www.openldap.org/its/index.cgi?findid=6831 - > > because this one did not pop up when I searched for existing ITS's > > (perhaps my search terms did not match or I just overlooked it). > > As I mentioned in the ticket I opened, this is not a schema issue; > > all the schema match on every server, and if that were the problem, > > none of the users would be served properly. What I found is that > > the keys that proxycache was looking for did not exist in the bdb > > it was searching. Why exactly that is, I'm not sure. Hopefully > > the information I provided in that ITS (or, perhaps some additional > > debugging information - gdb output or copies of databases exhibiting > > the problem) will help shed some light. If it is indeed the same > > issue, I'm all for coalescing the two. I have tested this all the > > way up through 2.4.23, and there are no commits to pcache.c or > > back-ldap/search.c since 2.4.23 was released that addresses this problem. > > Since you are not having the objectclass-related problem described in this > ticket it is not the same issue. Actually, having just tested that theory, I think my problem is actually objectclass-related, because it seems that it only happens when the objectClass attribute is included in the filter, and I can get different results by swapping the order of the filter components. Consider these two users, who have the same objectclasses, same attributes, and differ only in the attribute values (e.g., their name, phone number, and so on): bash:~# ldapsearch -x -H ldaps://localhost -LLL -b ou=Users,dc=example,dc=com '(&(|(objectClass=examplecomEmployee)(objectClass=examplecomUtilityUser))(uid=jdoe1))' uid dn: uid=jdoe1,ou=Users,dc=example,dc=com uid: jdoe1 bash:~# ldapsearch -x -H ldaps://localhost -LLL -b ou=Users,dc=example,dc=com '(&(|(objectClass=examplecomEmployee)(objectClass=examplecomUtilityUser))(uid=jdoe2))' uid So, one entry doesn't get returned when it should. If I reverse the filter, I get the expected results: bash:~# ldapsearch -x -H ldaps://localhost -LLL -b ou=Users,dc=example,dc=com '(&(|(objectClass=examplecomUtilityUser)(objectClass=examplecomEmployee))(uid=jdoe1))' uid dn: uid=jdoe1,ou=Users,dc=example,dc=com uid: jdoe1 bash:~# ldapsearch -x -H ldaps://localhost -LLL -b ou=Users,dc=example,dc=com '(&(|(objectClass=examplecomUtilityUser)(objectClass=examplecomEmployee))(uid=jdoe2))' uid dn: uid=jdoe2,ou=Users,dc=example,dc=com uid: jdoe2 Furthermore, if I now try the first query again, it too works: bash:~# ldapsearch -x -H ldaps://localhost -LLL -b ou=Users,dc=example,dc=com '(&(|(objectClass=examplecomEmployee)(objectClass=examplecomUtilityUser))(uid=jdoe1))' uid dn: uid=jdoe1,ou=Users,dc=example,dc=com uid: jdoe1 bash:~# ldapsearch -x -H ldaps://localhost -LLL -b ou=Users,dc=example,dc=com '(&(|(objectClass=examplecomEmployee)(objectClass=examplecomUtilityUser))(uid=jdoe2))' uid dn: uid=jdoe2,ou=Users,dc=example,dc=com uid: jdoe2 And, like Jim, I already have the patch for ITS#5756 applied in 2.4.17, 2.4.21, and 2.4.23. I can give you an example database exhibiting this behavior, if you like?

1 0

Re: (ITS#6740) syncrepl/--disable-rewrite dependency
by h.b.furuseth＠usit.uio.no 17 Feb '11

17 Feb '11

Howard Chu writes: > Agreed. I'm fine with dropping this configure switch and unifdef'ing it so > that librewrite is always used. Built unless --disable-slapd, I think. It is not installed, and the other libraries do not use it. -- Hallvard

1 0

(ITS#6836) Conversion to cn=config needs more detail
by andrew.findlay＠skills-1st.co.uk 17 Feb '11

17 Feb '11

Full_Name: Andrew Findlay Version: 2.4.24 OS: OpenSuSE 11.3 URL: ftp://ftp.openldap.org/incoming/afindlay-slapdconf2.sdf.20110216.diff Submission from: (NULL) (88.97.25.132) Admin Guide Section 5.4. "Converting old style slapd.conf(5) file to cn=config format" suggests that it is enough to run a slapd tool with both -f and -F options to perform this conversion. While strictly true, this will almost certainly result in an un-manageable server because there is no rootPW set for cn=config. The attached patch provides guidance to avoid this trap.

1 0

Re: (ITS#6834) Conversion to cn=config needs more detail
by andrew.findlay＠skills-1st.co.uk 17 Feb '11

17 Feb '11

On Wed, Feb 16, 2011 at 03:44:28PM -0800, Howard Chu wrote: > >It would also be useful to copy the config database clause from > >slapd-config(5) into the example in the Admin Guide: > > > > # set a rootpw for the config database so we can bind. > > # deny access to everyone else. > > dn: olcDatabase=config,cn=config > > objectClass: olcDatabaseConfig > > olcDatabase: config > > olcRootPW: {SSHA}XKYnrjvGT3wZFQrDD5040US592LxsdLy > > olcAccess: to * by * none > > That ACL is already the default. In an isolated example there's no > need to specify it. (It is present in the slapd-config(5) example to > ensure that it takes precedence over the olcFrontendConfig ACLs > immediately above it.) I was suggesting the inclusion of this entry mainly because of the olcRootPW, but as it would go into the config example in section 5.3 at about line 20, surely the ACL should be present for the same reason that it is in the manpage example? 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

Re: (ITS#6115) gdi32.lib required by OpenSSL+Windows
by hyc＠symas.com 16 Feb '11

16 Feb '11

slapd(a)hannebauer.name wrote: > Full_Name: Christoph Hannebauer > Version: 2.4.16 > OS: Windows/cygwin > URL: http://www.hannebauer.name/openldap-openssl/configure.in.patch > Submission from: (NULL) (139.18.40.169) > > > I tried to use OpenSSL 0.9.8k for TLS in my cygwin (target MinGW) OpenLDAP > build. The configure script does not detect OpenSSL (however, it doesn't break, > instead it finishes without TLS support), because the static library cannot be > linked. The config.log file contains error messages like > > /usr/local/mingw/lib/libcrypto.a(rand_win.o):rand_win.c:(.text+0xa0c): undefined > reference to `_CreateDCA@16' > > The missing functions are part of the library gdi32.lib. The OpenSSL readme file > INSTALL.W32 says, that Windows program using OpenSSL should link gdi32.lib (and > user32.lib, ..., but on my machine, gdi32.lib seems to be sufficient). Therefore > I have created the attached patch file to configure.in (1.697), which adds > gdi32.lib to LIBS, if it is required for OpenSSL. I have tested the patched > configure file on my machine, the build works without problems. You should simply add -lgdi32 to LIBS when running configure then, as documented in the INSTALL file. We add some platform-specific flags but we don't add site-specific flags to configure itself, and your problem depends on whether OpenSSL is using static or shared libraries on your installation. I.e., this issue is not generic to the Win32 platform. -- -- 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#6740) syncrepl/--disable-rewrite dependency
by hyc＠symas.com 16 Feb '11

16 Feb '11

h.b.furuseth(a)usit.uio.no wrote: > Full_Name: Hallvard B Furuseth > Version: HEAD > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (129.240.6.233) > Submitted by: hallvard > > > configure should mention syncrepl here: > --enable-rewrite enable DN rewriting in back-ldap and rwm overlay > > test059-slave-config fails with --disable-rewrite. Testrun/test.out says > parse_syncrepl_line: > unable to parse "suffixmassage=cn=schema,cn=config,cn=slave" > > Ando wrote: >> What's special about DN rewriting so it has a configure option >> anyway? It doesn't disable building of libraries/librewrite. > > It used to, as far as I remember. I remember something about performing > simple suffixmassage when librewrite is not built. In any case I agree > that given the widespread usage of rewrite capabilities (authz regexp, for > example) not building librewrite is somehow pointless. Agreed. I'm fine with dropping this configure switch and unifdef'ing it so that librewrite is always used. -- -- 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

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