openldap-bugs

openldap-bugs@openldap.org

1 participants
20959 discussions

(ITS#6455) Able to crash slapd while using back_ldap
by j＠gropefruit.com 16 Jan '10

16 Jan '10

Full_Name: J Version: 2.4.20 OS: Debian-Lenny/amd64 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (68.15.14.98) Host running Debian Lenny amd64 is experiencing a strange issue. slapd is segfaulting for no obvious reason. Syslog output: Jan 15 19:29:59 ldapc1 kernel: [10702.262741] slapd[3218]: segfault at 40 ip 7fb2b4829875 sp 44d90940 error 4 in back_ldap-2.4.so.2.5.3[7fb2b4819000+1f000] We are running slapd 2.4.20, via this config: include /etc/ldap/schema/core.schema include /etc/ldap/schema/cosine.schema include /etc/ldap/schema/nis.schema include /etc/ldap/schema/inetorgperson.schema pidfile /var/run/slapd/slapd.pid argsfile /var/run/slapd/slapd.args disallow bind_anon loglevel 0 sizelimit 999999 idletimeout 10 modulepath /usr/lib/ldap moduleload back_ldap moduleload back_hdb moduleload pcache TLSCertificateFile /etc/ldap/ssl/wildcard.crt TLSCertificateKeyFile /etc/ldap/ssl/wildcard.key TLSCACertificateFile /etc/ldap/ssl/wildcard.pem database ldap uri ldaps://192.168.1.1:636/ suffix "ou=svcs,cn=auth" rootdn "uid=slapd,ou=svcs,cn=auth" idassert-bind bindmethod=simple binddn="uid=auth,ou=svcs,cn=auth" credentials="password" mode=none idassert-authzFrom "dn.subtree:ou=svcs,cn=auth" ### For some reason, we can no longer use indexes like we could in slapd 2.3 ### while using back_ldap (uncommenting these will present slapd from starting). #index objectClass eq #index uid,mail,cn eq,sub #index queryid eq overlay pcache proxycache hdb 1000 1 50 1200 directory "/var/lib/ldap" proxycachequeries 100 proxyattrset 0 uid mail cn proxytemplate (uid=) 0 600 include /etc/ldap/acls.slapd ########## My hunch, given ITS #6452 (which I remarked was "solved"), is that id assertion may cause slapd to crash when an identity tries to assert as itself? e.g: uid=auth,ou=svcs,cn=auth >--idassert--> uid=auth,ou=svcs,cn=auth by means of the idassert-authzFrom parameter, which authorizes the entire subtree in which this account resides. Again, just a hunch ... Thanks J

1 0

Re: (ITS#6454) idassert-bind, etc., assistance
by quanah＠zimbra.com 15 Jan '10

15 Jan '10

--On Thursday, January 14, 2010 8:49 PM +0000 j(a)gropefruit.com wrote: > Full_Name: J > Version: 2.4.20 > OS: Debian/Lenny > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (68.15.14.98) The ITS system is for bug reports, not help with usage. I don't see any evidence here you are reporting a bug. Please use the openldap-software(a)openldap.org list if you have questions on how to set up and configure OpenLDAP. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#6454) idassert-bind, etc., assistance
by j＠gropefruit.com 14 Jan '10

14 Jan '10

Full_Name: J Version: 2.4.20 OS: Debian/Lenny URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (68.15.14.98) Is there any way to use the idassert feature ONLY for anonymous connections, while allowing all other binddns to be directly proxied as themselves? I ask because we have root LDAP servers that have ACL configurations that work for our purposes, and we don't want to change them. We also do not allow anonymous binds to our root servers. To be clear, we do not want to change anything whatsoever on our root servers. however, some clients do need to be able to bind anonymously. We're ok with this, as long as anonymous is allowed against LDAP proxies only, and not on our root LDAP servers. This way, we can control what anonymous user sees. I am trying to make the proxy behave in the following ways: * authenticated non-admin Users may bind as themselves, they can see groups, etc., (anything non-confidential) but can only see their own account (we have this one working, but is an essential element of the larger picture) * anonymous users see all of the same non-sensitive material, but no user accounts whatsoever * there are proxybind users in our DIT, one for read-ops and one for write-ops. The writer-proxybind user typically is needed for changing a users' password, etc. The read user is the one that performs lookups for strictly read-only operations. He can see all users. If I set the idassert-bind to the read-only user, then no one can do writes. If i set it to the write-user, then everyone (even those who shouldn't) can do writes (except anonymous, which is good). The understanding I have is that we should be setting the proxy user in slapd's proxy config to be the highest-privileged user that we're ok with being "asserted". For example, we're not asserting to the rootdn or anything, rather we assert to a bind user that is designed to read the very information that the proxy is designed to lookup. Here is our running config, though its been hacked up so much you should understand its probably not perfect around the edges. Also ignore the comments as they haven't been updated with the rest of the real parameters. PS - I tried to upload as anonymous to your ftp and got this: local: j-gropefruit-100114.txt remote: j-gropefruit-100114.txt 229 Entering Extended Passive Mode (|||60518|) 553 j-gropefruit-100114.txt: Permission denied. So you'll just have to read it here: include /etc/ldap/schema/core.schema include /etc/ldap/schema/cosine.schema include /etc/ldap/schema/nis.schema include /etc/ldap/schema/inetorgperson.schema include /etc/ldap/schema/misc.schema include /etc/ldap/schema/openldap.schema include /etc/ldap/schema/duaconf.schema include /etc/ldap/schema/dyngroup.schema include /etc/ldap/schema/ppolicy.schema include /etc/ldap/schema/sudo.schema include /etc/ldap/schema/dhcp.schema include /etc/ldap/schema/samba.schema include /usr/share/doc/libpam-ldap/ldapns.schema include /etc/ldap/schema/hdb.schema include /etc/ldap/schema/uber.schema pidfile /var/run/slapd/slapd.pid argsfile /var/run/slapd/slapd.args loglevel stats stats2 conns parse idletimeout 0 sizelimit unlimited timelimit unlimited defaultsearchbase dc=fake,dc=example,dc=com limits dn.regex="^uid=([^,]+).,cn=plain,*" time.soft=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited access to dn.base="" by * read access to dn.base="cn=Subschema" by * read ## Load modules here modulepath /usr/lib/ldap moduleload back_relay moduleload back_ldap moduleload back_hdb moduleload pcache moduleload rwm.la ## SSL/TLS TLSCertificateFile /etc/ldap/ssl/wildcard.fake.example.com.crt TLSCertificateKeyFile /etc/ldap/ssl/wildcard.fake.example.com.key TLSCACertificateFile /etc/ldap/ssl/wildcard.fake.example.com.pem ## This is for SASL/GSSAPI authentication sasl-realm FAKE.EXAMPLE.COM sasl-host ds-fake-int.fake.example.com authz-regexp "uid=$.*$,cn=FAKE.EXAMPLE.COM,cn=gssapi,cn=auth" "uid=$1,cn=plain,cn=auth,dc=real,dc=example,dc=com" authz-regexp "uid=$.*$,cn=DEV.EXAMPLE.COM,cn=gssapi,cn=auth" "uid=$1,cn=plain,cn=auth,cn=dev,dc=real,dc=example,dc=com" ## Define the actual 'database', as referenced by the suffix. database ldap uri ldaps://10.9.8.7:636/ suffix "dc=real,dc=example,dc=com" rootdn "uid=rootdn,cn=plain,cn=auth,dc=real,dc=example,dc=com" overlay rwm rwm-rewriteEngine on # all dataflow from server to client rwm-rewriteContext searchEntryDN rwm-rewriteRule "(.+,)?dc=real,dc=example,dc=com$" "$1dc=fake,dc=example,dc=com" ## When proxying information, configure what identity to assert. #acl-bind # bindmethod="simple" # binddn="uid=plainproxy,cn=plain,cn=auth,dc=real,dc=example,dc=com" # credentials="pass" # starttls="no" # tls_reqcert="never" idassert-bind bindmethod="simple" binddn="uid=plainchange,cn=plain,cn=auth,dc=real,dc=example,dc=com" credentials="pass" starttls="no" tls_reqcert="never" mode="legacy" flags="override,non-prescriptive" idassert-authzFrom "dn.subtree:cn=plain,cn=auth,dc=real,dc=example,dc=com" idassert-authzFrom "dn.subtree:cn=plain,cn=auth,dc=real,dc=example,dc=com" idassert-authzFrom "dn.exact:" chase-referrals NO rebind-as-user NO ## Cache data for PERFORMANCE - this only works when the upstream proxy ## is online. There's no way to cache data in its entirety if the provider ## goes down (that's what actual replication is for). overlay pcache proxycache hdb 2000 5 100 1800 directory "/var/lib/ldap/cache" dbconfig set_cachesize 0 4097152 0 dbconfig set_lg_regionmax 1048576 dbconfig set_lg_max 1048576 dbconfig set_lg_dir /var/lib/ldap/cache dbconfig set_tmp_dir /tmp index uid,cn,sn,givenName eq,sub index uidNumber,gidNumber eq index homeDirectory,loginShell,gecos,objectClass eq proxycachequeries 10000 proxyattrset 0 uid userPassword uidNumber gidNumber cn homeDirectory loginShell gecos description objectClass proxytemplate (&(objectclass=)(uidNumber=)) 0 1200 proxytemplate (&(objectclass=)(uid=)) 0 1200 proxyattrset 1 objectclass proxytemplate (objectclass=) 1 1200 proxyattrset 2 uid proxytemplate (uid=) 2 1200 proxyattrset 3 cn nisNetgroupTriple memberNisNetgroup proxytemplate (&(objectClass=)(cn=)) 3 1200 proxyattrset 4 gidNumber proxytemplate (&(objectClass=)(memberUid=)) 4 1200 ## Set a global rule to allow everything to our service/proxy users, then forbid ## all others access, but BREAK the rule so it keeps processing the rest of the rules, ## which are all much less-permissive ... access to dn.subtree="dc=real,dc=example,dc=com" by group/groupOfUniqueNames/uniqueMember="cn=ldapadmin,cn=ldap,cn=groups,dc=real,dc=example,dc=com" write by dn.regex="^uid=plain$modify|change$,cn=plain,cn=auth,dc=real,dc=example,dc=com" write by dn.regex="^uid=plain$proxy|agent$,cn=plain,cn=auth,dc=real,dc=example,dc=com" read by * none break access to attrs=userPassword by self =w by * =x ## OMFGZZZZ the Solipsism rule - if you touch this I will kill you. ## This fixes the MUST-BIND-AS-SELF logic problem with Sun VDI access to dn.regex="^uid=([^,]+),cn=plain,cn=auth,dc=real,dc=example,dc=com" by dn.base,expand="uid=$1,cn=plain,cn=auth,dc=real,dc=example,dc=com" read by * none break ########## Relay Instance for the "fake" zone database relay suffix dc=fake,dc=example,dc=com relay dc=real,dc=example,dc=com overlay rwm rwm-suffixmassage dc=real,dc=example,dc=com rwm-rewriteEngine on rwm-normalize-mapped-attrs yes rwm-rewriteContext searchAttrDN rwm-rewriteRule "(.+,)?dc=real,dc=example,dc=com$" "$1dc=fake,dc=example,dc=com" access to dn.subtree="dc=fake,dc=example,dc=com" by group/groupOfUniqueNames/uniqueMember="cn=ldapadmin,cn=ldap,cn=groups,dc=real,dc=example,dc=com" write by dn.exact="uid=plainchange,cn=plain,cn=auth,dc=real,dc=example,dc=com" read by dn.exact="uid=plainmodify,cn=plain,cn=auth,dc=real,dc=example,dc=com" read by dn.exact="uid=plainproxy,cn=plain,cn=auth,dc=real,dc=example,dc=com" read by dn.exact="uid=plainagent,cn=plain,cn=auth,dc=real,dc=example,dc=com" read by * none break access to dn.children="cn=plain,cn=auth,dc=fake,dc=example,dc=com" attrs=userPassword filter=(&(uid=*)(|(objectClass=posixAccount)(objectClass=simpleSecurityObject)(objectClass=shadowAccount)(objectClass=inetOrgPerson)(objectClass=account))) by self write by dn.exact="uid=plainchange,cn=plain,cn=auth,dc=real,dc=example,dc=com" write by dn.exact="uid=plainmodify,cn=plain,cn=auth,dc=real,dc=example,dc=com" write by anonymous auth by * none break access to dn.children="cn=plain,cn=auth,dc=fake,dc=example,dc=com" filter=(&(uid=*)(|(objectClass=posixAccount)(objectClass=simpleSecurityObject)(objectClass=shadowAccount)(objectClass=inetOrgPerson)(objectClass=account))) by self read by dn.exact="uid=plainchange,cn=plain,cn=auth,dc=real,dc=example,dc=com" read by dn.exact="uid=plainmodify,cn=plain,cn=auth,dc=real,dc=example,dc=com" read by dn.exact="uid=plainproxy,cn=plain,cn=auth,dc=real,dc=example,dc=com" read by dn.exact="uid=plainagent,cn=plain,cn=auth,dc=real,dc=example,dc=com" read by * none break access to dn.subtree="cn=groups,dc=fake,dc=example,dc=com" filter=(|(objectClass=posixGroup)(objectClass=nisNetgroup)(objectClass=groupOfUniqueNames)(objectClass=groupOfNames)(objectClass=organizationalRole)) by dn.exact="uid=plainmodify,cn=plain,cn=auth,dc=real,dc=example,dc=com" read by dn.exact="uid=plainchange,cn=plain,cn=auth,dc=real,dc=example,dc=com" read by dn.exact="uid=plainagent,cn=plain,cn=auth,dc=real,dc=example,dc=com" read by dn.exact="uid=plainproxy,cn=plain,cn=auth,dc=real,dc=example,dc=com" read by anonymous read by * none break access to dn.onelevel="cn=gssapi,cn=auth,dc=fake,dc=example,dc=com" by dn="uidNumber=0+gidNumber=0,cn=peercred,cn=external,cn=auth" read by * none break access to dn.onelevel="cn=FAKE.EXAMPLE.COM,cn=gssapi,cn=auth,dc=fake,dc=example,dc=com" by dn="uidNumber=0+gidNumber=0,cn=peercred,cn=external,cn=auth" write by * none break access to dn.subtree="cn=sys,dc=fake,dc=example,dc=com" by * read access to dn.subtree="cn=tester,dc=fake,dc=example,dc=com" by * read access to dn.subtree="cn=dev,dc=fake,dc=example,dc=com" by * none access to dn.subtree="cn=elements,dc=fake,dc=example,dc=com" by * none The man pages and examples on OL.org have helped tremendously, but I need some living & breathing opinions. Thanks J

1 0

Re: (ITS#6453) OpenLDAP memory leak on LDAP_TIMEOUT
by rein＠OpenLDAP.org 14 Jan '10

14 Jan '10

On 13.01.2010 14:30, alinachegalati(a)yahoo.com wrote: > Spam detection software, running on the system "boole.openldap.org", has > identified this incoming email as possible spam. The original message > has been attached to this so you can view it (if it isn't spam) or label > similar future email. If you have any questions, see > The administrator of that system for details. > > Content analysis details: (5.2 points, 5.0 required) > > pts rule name description > ---- ---------------------- -------------------------------------------------- > 3.4 FH_DATE_PAST_20XX The date is grossly in the future. This is a broken spamassassin rule, it believes that the year 2010 is in the future. Run sa-update (if it works), or add to spamassassins local.cf: score FH_DATE_PAST_20XX 0 Rein

2 1

Re: (ITS#6453) OpenLDAP memory leak on LDAP_TIMEOUT
by alinachegalati＠yahoo.com 13 Jan '10

13 Jan '10

--0-1551663707-1263389393=:13367 Content-Type: text/plain; charset=us-ascii Workaround : count the number of timeouts per ldap connection and unbind it when it reaches a certain threshold (1000 for example). --0-1551663707-1263389393=:13367 Content-Type: text/html; charset=us-ascii <table cellspacing="0" cellpadding="0" border="0" ><tr><td valign="top" style="font: inherit;">Workaround : count the number of timeouts per ldap connection and unbind it when it reaches a certain threshold (1000 for example). </td></tr></table> --0-1551663707-1263389393=:13367--

1 0

Re: (ITS#6453) OpenLDAP memory leak on LDAP_TIMEOUT
by alinachegalati＠yahoo.com 13 Jan '10

13 Jan '10

--0-1599667706-1263381171=:58734 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Aditional Information : Note that the ldap connection is not un-binded, it = is simply returned to a connection pool. --- On Wed, 1/13/10, openldap-its(a)OpenLDAP.org <openldap-its(a)OpenLDAP.org> = wrote: From: openldap-its(a)OpenLDAP.org <openldap-its(a)OpenLDAP.org> Subject: Re: (ITS#6453) OpenLDAP memory leak on LDAP_TIMEOUT To: alinachegalati(a)yahoo.com Date: Wednesday, January 13, 2010, 3:05 AM *** THIS IS AN AUTOMATICALLY GENERATED REPLY *** Thanks for your report to the OpenLDAP Issue Tracking System.=A0 Your report has been assigned the tracking number ITS#6453. One of our support engineers will look at your report in due course. Note that this may take some time because our support engineers are volunteers.=A0 They only work on OpenLDAP when they have spare time. If you need to provide additional information in regards to your issue report, you may do so by replying to this message.=A0 Note that any mail sent to openldap-its(a)openldap.org with (ITS#6453) in the subject will automatically be attached to the issue report. =A0=A0=A0 mailto:openldap-its@openldap.org?subject=3D(ITS#6453) You may follow the progress of this report by loading the following URL in a web browser: =A0 =A0 http://www.OpenLDAP.org/its/index.cgi?findid=3D6453 Please remember to retain your issue tracking number (ITS#6453) on any further messages you send to us regarding this report.=A0 If you don't then you'll just waste our time and yours because we won't be able to properly track the report. Please note that the Issue Tracking System is not intended to be used to seek help in the proper use of OpenLDAP Software. Such requests will be closed. OpenLDAP Software is user supported. =A0=A0=A0 http://www.OpenLDAP.org/support/ -------------- Copyright 1998-2007 The OpenLDAP Foundation, All Rights Reserved. =0A=0A=0A --0-1599667706-1263381171=:58734 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable <table cellspacing=3D"0" cellpadding=3D"0" border=3D"0" ><tr><td valign=3D"= top" style=3D"font: inherit;">Aditional Information : Note that the ldap co= nnection is not un-binded, it is simply returned to a connection pool. <= br>--- On Wed, 1/13/10, openldap-its(a)OpenLDAP.org <openldap-its@Op= enLDAP.org> wrote: <blockquote style=3D"border-left: 2px soli= d rgb(16, 16, 255); margin-left: 5px; padding-left: 5px;"> From: openlda= p-its(a)OpenLDAP.org <openldap-its(a)OpenLDAP.org> Subject: Re: (ITS#6= 453) OpenLDAP memory leak on LDAP_TIMEOUT To: alinachegalati(a)yahoo.com<b= r>Date: Wednesday, January 13, 2010, 3:05 AM <div class=3D"plainMail= "> *** THIS IS AN AUTOMATICALLY GENERATED REPLY *** Thanks for yo= ur report to the OpenLDAP Issue Tracking System.  Your report has b= een assigned the tracking number ITS#6453. One of our support engine= ers will look at your report in due course. Note that this may take some= time because our support engineers are volunteers.  They only work on O= penLDAP when they have spare time. If you need to provide additio= nal information in regards to your issue report, you may do so by replyi= ng to this message.  Note that any mail sent to <a ymailto=3D"mailt= o:openldap-its@openldap.org" href=3D"/mc/compose?to=3Dopenldap-its@openldap= .org">openldap-its(a)openldap.org</a> with (ITS#6453) in the subject will = automatically be attached to the issue report.     ma= ilto:<a ymailto=3D"mailto:openldap-its@openldap.org" href=3D"/mc/compose?to= =3Dopenldap-its(a)openldap.org">openldap-its(a)openldap.org</a>?subject=3D(ITS#= 6453) You may follow the progress of this report by loading the foll= owing URL in a web browser:     <a href=3D"http://www.OpenL= DAP.org/its/index.cgi?findid=3D6453" target=3D"_blank">http://www.OpenLDAP.= org/its/index.cgi?findid=3D6453</a> Please remember to retain your i= ssue tracking number (ITS#6453) on any further messages you send to us regarding this= report.  If you don't then you'll just waste our time and yours be= cause we won't be able to properly track the report. Please note = that the Issue Tracking System is not intended to be used to seek help i= n the proper use of OpenLDAP Software. Such requests will be closed. = OpenLDAP Software is user supported.     <a href=3D"h= ttp://www.OpenLDAP.org/support/" target=3D"_blank">http://www.OpenLDAP.org/= support/</a> -------------- Copyright 1998-2007 The OpenLDAP Foun= dation, All Rights Reserved. </div></blockquote></td></tr></table><b= r>=0A=0A --0-1599667706-1263381171=:58734--

1 0

(ITS#6453) OpenLDAP memory leak on LDAP_TIMEOUT
by alinachegalati＠yahoo.com 13 Jan '10

13 Jan '10

Full_Name: Alin Vasile Version: 2.4.19 OS: Solaris 10 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (194.237.142.7) Hi, We have a memory leak LDAP_TIMEOUT is encountered on ldap_search_ext_invocation and we are unable to determine if it is related to OpenLdap or not. The following summarizes our code in case the LDAP_TIMEOUT response is returned : LDAPMessage *res ; // acquire connection // perform search if(rc == LDAP_TIMEOUT) { ldap_msgfree(res); // return connection } Is ldap_msgfree(res) enough in this case ? We tested our program by enabling a low timeout and hence all ldap calls resulting in timeout. The memory leak is about 9 Megs in several minutes, at a load of 5 req/ sec. dmalloc sees the following not allocated pointers 6642692 bytes : Line 640 of "io.c" starts at address 0xff2659c4 <ber_get_next+468> and ends at 0xff2659cc <ber_get_next+476>. 2019876 bytes : Line 277 of "memory.c" starts at address 0xff26676c <ber_memcalloc_x+132> and ends at 0xff266774 <ber_memcalloc_x+140>.

1 0

Re: (ITS#6452) Able to crash slapd when using identity assertion
by j＠gropefruit.com 13 Jan '10

13 Jan '10

Nevermind, commented out the following in my relay database config area: rwm-rewriteEngine on rwm-normalize-mapped-attrs yes rwm-rewriteContext searchAttrDN rwm-rewriteRule "(.+,)?dc=example,dc=com$" "$1,dc=public,dc=com" No longer crashes. You may close. J On Jan 12, 2010, at 21:39 , openldap-its(a)OpenLDAP.org wrote: > > *** THIS IS AN AUTOMATICALLY GENERATED REPLY *** > > Thanks for your report to the OpenLDAP Issue Tracking System. Your > report has been assigned the tracking number ITS#6452. > > One of our support engineers will look at your report in due course. > Note that this may take some time because our support engineers > are volunteers. They only work on OpenLDAP when they have spare > time. > > If you need to provide additional information in regards to your > issue report, you may do so by replying to this message. Note that > any mail sent to openldap-its(a)openldap.org with (ITS#6452) > in the subject will automatically be attached to the issue report. > > mailto:openldap-its@openldap.org?subject=(ITS#6452) > > You may follow the progress of this report by loading the following > URL in a web browser: > http://www.OpenLDAP.org/its/index.cgi?findid=6452 > > Please remember to retain your issue tracking number (ITS#6452) > on any further messages you send to us regarding this report. If > you don't then you'll just waste our time and yours because we > won't be able to properly track the report. > > Please note that the Issue Tracking System is not intended to > be used to seek help in the proper use of OpenLDAP Software. > Such requests will be closed. > > OpenLDAP Software is user supported. > http://www.OpenLDAP.org/support/ > > -------------- > Copyright 1998-2007 The OpenLDAP Foundation, All Rights Reserved. >

1 0

(ITS#6452) Able to crash slapd when using identity assertion
by j＠gropefruit.com 13 Jan '10

13 Jan '10

Full_Name: J Version: 2.4.20 OS: Debian-Lenny/amd64 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (68.15.14.98) Able to do all necessary identity assertion when using command-line tools (ldapsearch, ldapmodify, etc) against my server. Server is running back_ldap, back_relay, pcache and back_hdb. But when I point one of my test hosts (Debian Lenny) against this seemingly healthy server and I try to login, I get this while running slapd -d -1: [rw] searchEntryDN: "uid=jay,cn=plain,cn=auth,dc=example,dc=com" -> "uid=jay,cn=plain,cn=auth,dc=example,dc=com" slapd: /usr/src/openldap-src-2.4.20/openldap-2.4.20/servers/slapd/entry.c:483: entry_clean: Assertion `e->e_private == ((void *)0)' failed. Aborted Why?

1 0

(ITS#6449) roadmap update
by quanah＠OpenLDAP.org 12 Jan '10

12 Jan '10

Full_Name: Quanah Gibson-Mount Version: NA OS: NA URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.29.239) http://www.openldap.org/software/roadmap.html needs to be updated to note that OpenLDAP 2.3 is no longer maintained, same as 2.2 and prior.

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