- openldap-bugs - openldap.org

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

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

18 Feb '11

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: 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 -- ----------------------------------------------------------------------- | 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#6829) Auditlog Mod Patch
by masarati＠aero.polimi.it 18 Feb '11

18 Feb '11

> Full_Name: Kyle Smith > Version: 2.4.24 > OS: Ubuntu 10.04 > URL: > http://faculty.ycp.edu/~ksmith8/patches/servers-slapd-overlays-auditlog.c.p… > Submission from: (NULL) (192.245.87.12) > > > This is an enhancement of the auditlog overlay. By using a new directive, > auditlog_single_line, the auditlog is outputted on a single line, instead > of the > normal ldif style. I needed to make this change so that our log indexer > doesn't > have to parse lots of ldif data, instead it will just index the fields as > written. This will also give the benefit of reduced filesize of the audit > logs, > as it shortens the record by a fair number of characters. > > How To configure: > > Add "auditlog_single_line" to the "overlay auditlog" configuration in > slapd.conf. I think this contribution is not acceptable, since by violating the LDIF specs it makes the string unparsable. Remember that newline has a special meaning in LDIF, it separates tokens. If you need auditlogs to be single-line for some purpose, you should design a format that makes it parseable, to be generally useful. In any case, I believe OpenLDAP software's task is to make (useful) information available in a general format, and this is already accomplished by slapo-audotlog. If you need it in another format, you can easily post-process it later, without modifying the baseline code. p.

1 0

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

17 Feb '11

andrew.findlay(a)skills-1st.co.uk wrote: > 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: > 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. Used to work - since when, what release, what else has changed since then? 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.) -- -- 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 17 Feb '11

17 Feb '11

andrew.findlay(a)skills-1st.co.uk wrote: > 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. > This patch fails to apply to HEAD. Please re-read the contributing guidelines; all patches must be against HEAD. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#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

ITS#6512 BDB 5.0
by hyc＠symas.com 16 Feb '11

16 Feb '11

This was resolved by ITS#6698, support for BDB 5.x was released in 2.4.24. -- -- 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#6834) Conversion to cn=config needs more detail
by hyc＠symas.com 16 Feb '11

16 Feb '11

andrew.findlay(a)skills-1st.co.uk wrote: > On Wed, Feb 16, 2011 at 11:50:21AM +0000, Andrew Findlay wrote: > >> 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. > > 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.) -- -- 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#6833) LDAP hangs on Solaris
by tombolala＠gmx.de 16 Feb '11

16 Feb '11

Hi Quanah! sorry for the wrong release, I meant 2.4.22 of course. /Thomas -------- Original-Nachricht -------- > Datum: Wed, 16 Feb 2011 16:34:39 GMT > Von: quanah(a)zimbra.com > An: openldap-its(a)openldap.org > Betreff: Re: (ITS#6833) LDAP hangs on Solaris > --On Wednesday, February 16, 2011 11:37 AM +0000 tombolala(a)gmx.de wrote: > > > Full_Name: Thomas Bopp > > Version: 4.2.22 > > > I really need a solution for this problem. > > I suggest you list an actual OpenLDAP release. It's near impossible to > help you without that. > > --Quanah > > -- > > Quanah Gibson-Mount > Sr. Member of Technical Staff > Zimbra, Inc > A Division of VMware, Inc. > -------------------- > Zimbra :: the leader in open source messaging and collaboration > > -- Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de

1 0

(ITS#6835) extend pwFailureTime timestamp to microsecond resolution to improve pwdMaxFailure enforcement
by brian-ldap＠starvingprogrammer.com 16 Feb '11

16 Feb '11

Full_Name: Brian Wasserman Version: 2.4.21-0ubuntu5.3 OS: Ubuntu 10.04 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (198.151.13.15) More than pwdMaxFailure attempts can be made before locking out an account if multiple attempts are made within the same second since it'll only log one pwdFailureTime per second. This is because the timestamp is stored in second resolution. Changing this timestamp to use microsecond resolution should minimize this limitation. In order to reproduce the problem by exceeding the number of max failures configured, just attempt to bind to a server with the policy below (or similar) multiple times per second with a valid user and observer the number of pwdFailureTime entries that are added to the given account. The account is locked after three pwdFailureTime entries are added, regardless of the number of actual attempts. Here's my policy configuration: dn: cn=Standard,ou=Policies,dc=local,dc=com cn: Standard description: Standard password policy. pwdAttribute: userPassword pwdCheckQuality: 1 pwdLockout: TRUE pwdMustChange: TRUE pwdAllowUserChange: TRUE pwdSafeModify: TRUE objectClass: device objectClass: pwdPolicy pwdInHistory: 3 pwdMaxFailure: 3 pwdMinLength: 8 pwdMaxAge: 7776000 pwdMinAge: 86400

1 0

sortvals oddity
by Andrew Elble 16 Feb '11

16 Feb '11

I've run into the following issue while trying to track down why we are occasionally seeing duplicate members/memberUids in our groups: Set the server up for "sortvals memberUid". Add a posixGroup without any memberUid attributes present. Adding new memberUid attributes to the group afterwards will result in them being unsorted until server restart. I'm shooting from the hip here - shouldn't attr_merge() (in attr.c) have something like the following? if ( *a == NULL ) { *a = attr_alloc( desc ); if (desc->ad_type->sat_flags & SLAP_AT_SORTED_VAL) { (*a)->a_flags |= SLAP_ATTR_SORTED_VALS; } } else { Thanks, Andy -- Andrew W. Elble aweits(a)discipline.rit.edu Infrastructure Engineer, Communications Technical Lead Rochester Institute of Technology PGP: BFAD 8461 4CCF DC95 DA2C B0EB 965B 082E 863E C912 CONFIDENTIALITY NOTE: The information transmitted, including attachments, is intended only for the person(s) or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and destroy any copies of this information.

2 1

Re: (ITS#6833) LDAP hangs on Solaris
by quanah＠zimbra.com 16 Feb '11

16 Feb '11

--On Wednesday, February 16, 2011 11:37 AM +0000 tombolala(a)gmx.de wrote: > Full_Name: Thomas Bopp > Version: 4.2.22 > I really need a solution for this problem. I suggest you list an actual OpenLDAP release. It's near impossible to help you without that. --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

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

16 Feb '11

On Wed, Feb 16, 2011 at 11:50:21AM +0000, Andrew Findlay wrote: > 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. 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 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

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

16 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

(ITS#6833) LDAP hangs on Solaris
by tombolala＠gmx.de 16 Feb '11

16 Feb '11

Full_Name: Thomas Bopp Version: 4.2.22 OS: Solaris 10 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (195.47.255.100) After approximately one week our LDAP stops working and hangs (we had this situation several times). We have the www.sunfreeware.com package of LDAP installed. It had a bunch of connection in CLOSE_WAIT state (indicating basically that a close request has come in but slapd did not serve it). Making a truss on the process showed all threads blocked on lwp_cond_wait. I really need a solution for this problem.

1 0

(ITS#6832) fix #elif statement
by naota＠elisp.net 16 Feb '11

16 Feb '11

Full_Name: Naohiro Aota Version: 2.4.23 OS: Gentoo/FreeBSD 8.0 URL: http://elisp.net/openldap.patch Submission from: (NULL) (125.102.92.74) There are some #elif statements like "#elif FOOBAR", which should be "#elif defined(FOOBAR)". These statements might cause build error like this: i686-gentoo-freebsd8.0-gcc -O2 -pipe -march=prescott --param l1-cache-size=16 --param l1-cache-line-size=64 -mtune=prescott -D_GNU_SOURCE -I../../include -I../../include -I/usr/include/db4.8 -I/usr/include/db4.8 -c -o detach.o detach.c detach.c:131:7: error: missing binary operator before token "long" gmake[2]: *** [detach.o] Error 1 gmake[2]: Leaving directory `/usr/tmp/portage/net-nds/openldap-2.4.23/work/openldap-2.4.23/libraries/liblutil' gmake[1]: *** [all-common] Error 1 gmake[1]: Leaving directory `/usr/tmp/portage/net-nds/openldap-2.4.23/work/openldap-2.4.23/libraries' gmake: *** [all-common] Error 1 Build Environment: Gentoo/FreeBSD 8.0 gcc 4.4.4 URL is a address of the patch to fix the statements.

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs