openldap-bugs

openldap-bugs@openldap.org

1 participants
21146 discussions

Re: (ITS#8209) Broken MDB_CP_COMPACT threading
by h.b.furuseth＠usit.uio.no 29 Jul '15

29 Jul '15

On 29/07/15 21:25, h.b.furuseth(a)usit.uio.no wrote: > (...)And copythr should set mc_new=0 before exiting also when setting > mc_status. so copyfd1 won't just sit and wait. I forgot it clears mc_new before setting mc_status. It's if it didn't keep the mutex it would have to set mc_new afterwards (after locking the mutex).

1 0

(ITS#8209) Broken MDB_CP_COMPACT threading
by h.b.furuseth＠usit.uio.no 29 Jul '15

29 Jul '15

Full_Name: Hallvard B Furuseth Version: LMDB_0.9.15 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.191.45.5) Submitted by: hallvard mdb_env_copyfd1() and mdb_env_copythr() synchronize via my->mc_new, but incorrectly. copythr() starts before there is any data to consume, and copyfd1() does not tell it (by setting mc_new and signalling) when there is data. Instead it sets mc_new before it has finished producing the data. I suppose copythr just waits for a spurious wakeup, I haven't looked closely. It got it right originally when copyfd1 did not start the new thread until data (metapages) was ready. Or copyfd1 could start with mc_new = 0, and set it and signal when data is ready. copythr holds the mutex while writing. That's not how conds are supposed to be used. Threads are supposed to grab the mutex briefly around code which operates on mc_new. mc_status can be lost. Copyfd1 does not always use it, or it discards it. And copythr should set mc_new=0 before exiting also when setting mc_status. so copyfd1 won't just sit and wait.

1 0

Re: (ITS#8208) ppolicy supportedControl not visible in root DSE
by michael＠stroeder.com 29 Jul '15

29 Jul '15

robert.brooks(a)reporo.com wrote: > with ppolicy overlay loaded (and functioning) the following root DSE is= : > [..] > I would expect to see output similar to... >=20 > http://docs.forgerock.org/en/opendj/2.6.0/dev-guide/index/chap-getting-= directory-info.html#read-root-dse > D0D > specifilllly line 12 (and maybe line 40). It's a bit hard to follow line number references in a web page. :-/ But I guess you mean the OIDs coming from draft-vchu-ldap-pwd-policy [1].= Note that AFAIK OpenDJ supports old draft-vchu-ldap-pwd-policy which is v= ery outdated and not supported by LDAP servers without Netscape roots. slapo-ppolicy implements draft-behera-ldap-password-policy [2]. > # Search the root DSE for the password policy (works > # with Netscape Directory Server) > pam_lookup_policy yes >=20 > does not make pam_ldap to interact with password policies against when > configured in openldap. Using pam_ldap is NOT recommended nowadays for a bunch of reasons. Use nss-pam-ldapd, sssd or OpenLDAP's slapo-nssov. AFAIK all of them support draft-behera-ldap-password-policy. But such usage discussion belong on the openldap-technical mailing list a= nd not in the ITS. Ciao, Michael. [1] https://tools.ietf.org/html/draft-vchu-ldap-pwd-policy [2] https://tools.ietf.org/html/draft-behera-ldap-password-policy

1 0

Re: (ITS#8208) ppolicy supportedControl not visible in root DSE
by hyc＠symas.com 29 Jul '15

29 Jul '15

robert.brooks(a)reporo.com wrote: > Full_Name: Robert Brooks > Version: openldap-2.4.41 > OS: Ubuntu 14.04 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (38.99.38.134) > > > Hi, > > with ppolicy overlay loaded (and functioning) the following root DSE is: > I believe this is why the following pam_ldap config: > > # Search the root DSE for the password policy (works > # with Netscape Directory Server) > pam_lookup_policy yes > > does not make pam_ldap to interact with password policies against when > configured in openldap. No. That controls compatibility with the obsolete/non-standard Netscape-specific password policy attributes. But pam_ldap itself is also obsolete. Pretty sure Ubuntu ships with nslcd and nss-pam-ldapd now. -- -- 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#8208) ppolicy supportedControl not visible in root DSE
by robert.brooks＠reporo.com 29 Jul '15

29 Jul '15

Full_Name: Robert Brooks Version: openldap-2.4.41 OS: Ubuntu 14.04 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (38.99.38.134) Hi, with ppolicy overlay loaded (and functioning) the following root DSE is: structuralObjectClass: OpenLDAProotDSE configContext: cn=config namingContexts: dc=ldap,dc=example,dc=org supportedControl: 2.16.840.1.113730.3.4.18 supportedControl: 2.16.840.1.113730.3.4.2 supportedControl: 1.3.6.1.4.1.4203.1.10.1 supportedControl: 1.2.840.113556.1.4.319 supportedControl: 1.2.826.0.1.3344810.2.3 supportedControl: 1.3.6.1.1.13.2 supportedControl: 1.3.6.1.1.13.1 supportedControl: 1.3.6.1.1.12 supportedExtension: 1.3.6.1.4.1.1466.20037 supportedExtension: 1.3.6.1.4.1.4203.1.11.1 supportedExtension: 1.3.6.1.4.1.4203.1.11.3 supportedExtension: 1.3.6.1.1.8 supportedFeatures: 1.3.6.1.1.14 supportedFeatures: 1.3.6.1.4.1.4203.1.5.1 supportedFeatures: 1.3.6.1.4.1.4203.1.5.2 supportedFeatures: 1.3.6.1.4.1.4203.1.5.3 supportedFeatures: 1.3.6.1.4.1.4203.1.5.4 supportedFeatures: 1.3.6.1.4.1.4203.1.5.5 supportedLDAPVersion: 3 supportedSASLMechanisms: DIGEST-MD5 supportedSASLMechanisms: NTLM supportedSASLMechanisms: CRAM-MD5 entryDN: subschemaSubentry: cn=Subschema I would expect to see output similar to... http://docs.forgerock.org/en/opendj/2.6.0/dev-guide/index/chap-getting-dire… D0D specifilllly line 12 (and maybe line 40). I believe this is why the following pam_ldap config: # Search the root DSE for the password policy (works # with Netscape Directory Server) pam_lookup_policy yes does not make pam_ldap to interact with password policies against when configured in openldap. Regards, Rob

1 0

Re: (ITS#8206) ldapsearch incorrectly cannonicalizes dns names for GSSAPI
by michael＠stroeder.com 29 Jul '15

29 Jul '15

Calvin Winkowski wrote: >> Did you already try with -N? > > Nope, a bit embarrassed that I didn't find that on my own. Thanks! It > does work with the -N flag. > > I think there is still argument for making that the default and > providing a flag to canonicalize the hostname, but I don't know enough > about GSSAPI's standard to say for certain. I've only used it with > Kerberos. IIRC there was a long-winding sasl-no-canonicalize debate on the mailing lists a while ago. I'm pretty sure nobody wants to repeat that. Ciao, Michael.

1 0

Re: (ITS#8207) ppolicy: pwdMinLength not checked if pwdInHistory == 0
by michael＠stroeder.com 29 Jul '15

29 Jul '15

porjo38(a)yahoo.com.au wrote: > Using password policy overlay, pwdMinLength is not checked when pwdInHistory == > 0. I tried to reproduce this with my local OpenLDAP 2.4.41 installation. In one case I thought to see this but I could not reproduce all the time. Maybe there's another condition for this to happen. Could you please also test with release 2.4.41? And please also post the entry with the password (and relevant pwd* attrs) and the pwdPolicy entry used, both as LDIF (minus sensitive data). Ciao, Michael.

1 0

Re: (ITS#8206) ldapsearch incorrectly cannonicalizes dns names for GSSAPI
by michael＠stroeder.com 29 Jul '15

29 Jul '15

cwinkows(a)vt.edu wrote: > When using ldapsearch GSSAPI mechanism with a server whose reverse DNS name > doesn't match its DNS name, ldapsearch will do the DNS lookups and hand the > reverse DNS entry to GSSAPI. If the reverse DNS entry is not what is used by > kerberos then kerberos will fail. Did you already try with -N? $ ldapsearch -h [..] -N do not use reverse DNS to canonicalize SASL host name [..] Ciao, Michael.

1 0

(ITS#8207) ppolicy: pwdMinLength not checked if pwdInHistory == 0
by porjo38＠yahoo.com.au 29 Jul '15

29 Jul '15

Full_Name: Ian Bishop Version: 2.4.39 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2001:388:e001:ce00:f2de:f1ff:fea7:d755) Using password policy overlay, pwdMinLength is not checked when pwdInHistory == 0. I tested this by setting pwdMinLength=6 and pwdInHistory=0. I was then able to set a 3 character password. When I changed pwdInHistory > 0 and tried to set a 3 charactepapassword, the attempt was denied. I repeated this several times, and also restarted slapd just in case - same result. Running Openldap 2.4.39 on Centos7, installed from Centos RPM repo.

1 0

(ITS#8206) ldapsearch incorrectly cannonicalizes dns names for GSSAPI
by cwinkows＠vt.edu 28 Jul '15

28 Jul '15

Full_Name: Calvin Winkowski Version: 2.4.41 OS: ArchLinux URL: Submission from: (NULL) (2001:468:c80:a202:3b1d:f567:f43c:7b3a) When using ldapsearch GSSAPI mechanism with a server whose reverse DNS name doesn't match its DNS name, ldapsearch will do the DNS lookups and hand the reverse DNS entry to GSSAPI. If the reverse DNS entry is not what is used by kerberos then kerberos will fail. There are settings in /etc/krb5.conf to disable canonicalizing the hostname provided. I have a server with a record example.ad.example.com whose PTR record is example.example.com, but the realm is ad.example.com and it's entry in the kerberos database is example.ad.example.com, not example.example.com. If I execute the command ``ldapsearch -b "" -s base -Y GSSAPI -D "dn" -H ldap://example.ad.example.com'' GSSAPI will submit a ticket request for example.example.com instead and result in a failure. All other services I've tested with this setup (disabling reverse dns in kerberos) do not give the PTR record, but the user provided hostname. These include mbsync, msmtp, and another ldap utility. I believe that the correct behaviour should be to provide the hostname provided to the utility to GSSAPI. I can provide packet captures illustrating the incorrect lookup if needed.

1 0

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs