openldap-bugs

openldap-bugs@openldap.org

1 participants
20967 discussions

(ITS#7437) Request to submit EnMasse project to OpenLDAP
by shawn.mckinney＠joshuatreesoftware.us 10 Nov '12

10 Nov '12

Full_Name: Shawn McKinney Version: all OS: all URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (99.34.196.221) Hello, We have created a new application, called EnMasse. EnMasse is a web application that implements RESTful Web services to interface with Fortress/OpenLDAP. EnMasse was built using established Open Source technologies including Apache CXF (web services stack), Spring Framework (glue), Maven (dependencies) and JAXB (data binding layer) and runs inside any reasonably compliant Java Servlets container. EnMasses service access decisions are made using declarative Java EE and Spring security policy hooks that are wired to connect back to the Fortress RBAC component itself. This product has not been published and we would like to release it as one of the products under OpenLDAP family of products. What we would like from OpenLDAP foundation is the following: 1. Separate GIT project called EnMasse. 2. Mailing list for developers and users to communicate with project team. 3. Issue tracking for EnMasse project. 4. Project page for overview and how to find out more information. I have uploaded one package, entitled enmasse-openldap-submission.zip to our FTP server that contains the source, documentation and other items for you to look at. host: joshuatreesoftware.us user: jtreeguest pw: Guest123 Everything under the /target folder contain generated project artifacts including deployable web archive (war) and javadoc. These artifacts will not be checked into GIT. The source is located /src folder in the package. Statement of origin for submitted works: The contributed EnMasse works described above were provided by JoshuaTree Software, LLC and referenced in this ITS were created by JoshuaTree Software, LLC, who is the exclusive owner of the contributed works. The contributed works are made available as indicated in the copyright and license statements attached to the work. Sincerely, Shawn McKinney Principal, JoshuaTree Software, LLC

1 0

Re: (ITS#7435) telexNumber
by quanah＠zimbra.com 09 Nov '12

09 Nov '12

--On Friday, November 09, 2012 6:59 AM +0000 masarati(a)aero.polimi.it wrote: > >> Full_Name: Roy Luckow >> Version: 2.4.30 >> OS: Win Server 2003 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (212.4.225.4) >> >> >> LDAP Search for attribute "telexNumber" doesn't work. >> If I do a search filter "(telexNumber=*)" --> Then I get my results >> (total of >> 4600 hits). If I set the search as "(telexNumber=*1*)" --> Then I get the >> Message "No entries matched" > > This is by design: "telexNumber" has no matching rule. This ITS will be > closed. I would note that you can force matching rules to apply to a particular attribute during a search. You might try the matching rules for telephoneNumber. Hope this helps, 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#7436) slapo-deref not working
by rhafer＠suse.de 09 Nov '12

09 Nov '12

Fixed slapo-deref. pcache still missing.

1 0

Re: (ITS#7436) slapo-deref not working
by rhafer＠suse.de 09 Nov '12

09 Nov '12

On Fri, Nov 09, 2012 at 02:04:13PM +0000, ralf(a)OpenLDAP.org wrote: > Independ of whether the slapo-deref beign configured or not it always returns > "Critical extension is unavailable" to the client. > > This is because it doesn't call overlay_register_control anywhere in its code. > Fix is underway. The PCACHE_CONTROL_PRIVDB control defined in slapo-pcache seems to suffer the same problem. (though that's still hidden behind LDAP_DEVEL)

1 0

(ITS#7436) slapo-deref not working
by ralf＠OpenLDAP.org 09 Nov '12

09 Nov '12

Full_Name: Ralf Haferkamp Version: RE24, HEAD OS: SLES11 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (188.118.144.197) Submitted by: ralf Independ of whether the slapo-deref beign configured or not it always returns "Critical extension is unavailable" to the client. This is because it doesn't call overlay_register_control anywhere in its code. Fix is underway.

1 0

Re: (ITS#7435) telexNumber
by masarati＠aero.polimi.it 08 Nov '12

08 Nov '12

> Full_Name: Roy Luckow > Version: 2.4.30 > OS: Win Server 2003 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (212.4.225.4) > > > LDAP Search for attribute "telexNumber" doesn't work. > If I do a search filter "(telexNumber=*)" --> Then I get my results (total > of > 4600 hits). If I set the search as "(telexNumber=*1*)" --> Then I get the > Message "No entries matched" This is by design: "telexNumber" has no matching rule. This ITS will be closed. p. -- Pierangelo Masarati Associate Professor Dipartimento di Ingegneria Aerospaziale Politecnico di Milano

1 0

(ITS#7435) telexNumber
by Roy.Luckow＠swmh.de 08 Nov '12

08 Nov '12

Full_Name: Roy Luckow Version: 2.4.30 OS: Win Server 2003 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (212.4.225.4) LDAP Search for attribute "telexNumber" doesn't work. If I do a search filter "(telexNumber=*)" --> Then I get my results (total of 4600 hits). If I set the search as "(telexNumber=*1*)" --> Then I get the Message "No entries matched"

1 0

Re: (ITS#7434) idassert-bind fails after restarting slapd
by quanah＠zimbra.com 08 Nov '12

08 Nov '12

--On Friday, November 09, 2012 2:10 AM +0000 quanah(a)zimbra.com wrote: > --On Friday, November 09, 2012 1:55 AM +0000 blance3459(a)hotmail.com wrote: > >> Full_Name: Barry Lance >> Version: 2.4.28 >> OS: Ubuntu 12.04 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (70.226.37.226) >> > > Hi Barry, Hi Barry, Are you sure you aren't hitting: Fixed slapd-ldap idassert bind handling (ITS#7403) Fixed in OpenLDAP 2.4.33? --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#7434) idassert-bind fails after restarting slapd
by quanah＠zimbra.com 08 Nov '12

08 Nov '12

--On Friday, November 09, 2012 1:55 AM +0000 blance3459(a)hotmail.com wrote: > Full_Name: Barry Lance > Version: 2.4.28 > OS: Ubuntu 12.04 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (70.226.37.226) > Hi Barry, Thanks for the report. I would note that OpenLDAP 2.4.28 is 5 releases old at this point. I don't see anything specific in the CHANGES file between 2.4.28 and 2.4.33 for this issue, but it may be fixed and not logged in there. Confirming that the behavior persists with 2.4.33 would be helpful. Also, don't confuse encoding with encryption. ;) It is standard in LDIF for data to be base64 encoded if the attribute value requires it based on the characters in the data. You can use various tools to decode the attribute value back out. Regards, 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

(ITS#7434) idassert-bind fails after restarting slapd
by blance3459＠hotmail.com 08 Nov '12

08 Nov '12

Full_Name: Barry Lance Version: 2.4.28 OS: Ubuntu 12.04 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (70.226.37.226) Two servers: Master (192.168.1.1) and Replica (192.168.1.2) both running slap 2.4.28 and ubuntu 12.04. Replica is a replication partner of Master using syncrepl. Replication is working fine. When I attempt to add a chain overlay to Replica to send all writes over to the master, it works exactly as expected allowing both normal users and the rootdn to make appropriate changes. However, once I either reboot the replica server or restart slapd, the chain overlay fails to allow any changes on the master. Looking at syslog shows that before the reboot/restart the requesting users' dn is proxied over as expected. After the restarting slapd or rebooting Replica, all changes are proxied anonymously (dn=""). I am using simple binds at this point in the project, but it doesn't seems to matter if I proxy in the clear, ldaps, or TLS the result is the same. All three methods can successfully negotiate a connection. I've even tried switching between using the rootdn and a different user as the binddn in my overlay, but the result is still the same no matter what I use for the binddn. When I look at my config, I notice that "chain-idassert-bind" appears to be hashed or encrypted in thew config. Is that normal? Just seems really odd that my config would work immediately when added, but fail after the the daemon has been restarted. Am I missing something really silly? Hopefully, someone can assist me on this. I've been driving myself crazy trying to figure out why this behavior is occurring. Disclaimer: I am using openldap as part of my capstone project for graduation. I'm not asking for anyone to do my "homework" for me, I'm just stuck on this one issue that I would love to resolve so I can move on to the Kerberos phase of my project (and maybe even study for an exam coming up in my algorithms class next week). Here is my overlay config using the rootDN and TLS (on Replica): dn: olcDatabase=ldap,olcOverlay={0}chain,olcDatabase={-1}frontend, cn=config changetype: add objectClass: olcLDAPConfig objectClass: olcChainDatabase olcDatabase: {0}ldap olcDbURI: "ldap://master.example.net/" olcDbRebindAsUser: TRUE olcDbIDAssertBind: bindmethod=simple binddn="cn=admin,dc=example,dc=net" credentials=(secret) mode=self starttls=critical tls_cacert=/etc/ssl/certs/cacert.pem tls_reqcert=demand And without TLS (also on Replica): dn: olcDatabase=ldap,olcOverlay={0}chain,olcDatabase={-1}frontend, cn=config changetype: add objectClass: olcLDAPConfig objectClass: olcChainDatabase olcDatabase: {0}ldap olcDbURI: "ldap://master.example.net/" olcDbRebindAsUser: TRUE olcDbIDAssertBind: bindmethod=simple binddn="cn=admin,dc=example,dc=net" credentials=(secret) mode=self

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