openldap-bugs

openldap-bugs@openldap.org

1 participants
21003 discussions

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

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