openldap-bugs

openldap-bugs@openldap.org

1 participants
21003 discussions

Re: (ITS#6996) Bad cn=config quotes in Admin Guide
by hyc＠symas.com 28 Jul '11

28 Jul '11

h.b.furuseth(a)usit.uio.no wrote: > Full_Name: Hallvard B Furuseth > Version: master, 2.4.26 > OS: > URL: > Submission from: (NULL) (129.240.6.233) > Submitted by: hallvard > > > http://www.openldap.org/doc/admin24/slapdconf2.html > contains a number of examples with quoted DNs in cn=config attributes: > olcSuffix, olcRootDN. This is wrong, likely a cut&paste from slapd.conf. There's nothing wrong here, the config parser accepts quotes for these attributes. -- -- 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#7004) ppolicy pwdCheckQuality constraint prevents from changing userPassword, even if pwdPolicySubentry is removed in the same modify operation
by masarati＠aero.polimi.it 27 Jul '11

27 Jul '11

> Full_Name: Clément OUDOT > Version: 2.4.26 > OS: GNU/Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (90.9.0.93) > > > I have a piece of code that does this singel modify operation on OpenLDAP: > * remove pwdPolicySubentry value > * replace userPassword value > > My password policy has pwdCheckQuality set to 2 (strict checking). My new > userPassword value is {SASL}bob(a)example.com. But the modify operation > failed > with: > > conn=1058 op=100 RESULT tag=103 err=19 text=Password fails quality > checking > policy > > > I was thinking than removing the pwdPolicySubentry was sufficient to > disable all > ppolicy constraint on the userPassword replacement in the same modify > operation. > Am I wrong or do I face a ppolicy overlay bug? I think this question should be directed to openldap-technical, as it is a usage question. In detail, I think the behavior of slapd and slapo-ppolicy(5) is correct, because pwdPolicySubentry was present when the operation initiated, and thus the behavior of slapo-ppolicy(5) needs to be based on the entry's content when the operation was initiated. I also think this may represent a possible field of application of the "relax" control, although neither draft-zeilenga-ldap-relax nor draft-behera-ldap-password-policy document it. Something like the relax control would allow to change a password despite the password policy, as soon as the final result complies with the protocol, including extensions. This would mean that slapo-ppolicy(5) constraints would eventually be evaluated for the entry as it results from the operation. But I think I've gone too far in discussing a usage question on the ITS. p.

1 0

(ITS#7004) ppolicy pwdCheckQuality constraint prevents from changing userPassword, even if pwdPolicySubentry is removed in the same modify operation
by clem.oudot＠gmail.com 27 Jul '11

27 Jul '11

Full_Name: Clément OUDOT Version: 2.4.26 OS: GNU/Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (90.9.0.93) I have a piece of code that does this singel modify operation on OpenLDAP: * remove pwdPolicySubentry value * replace userPassword value My password policy has pwdCheckQuality set to 2 (strict checking). My new userPassword value is {SASL}bob(a)example.com. But the modify operation failed with: conn=1058 op=100 RESULT tag=103 err=19 text=Password fails quality checking policy I was thinking than removing the pwdPolicySubentry was sufficient to disable all ppolicy constraint on the userPassword replacement in the same modify operation. Am I wrong or do I face a ppolicy overlay bug?

1 0

(ITS#7003) Document typo
by xianhua.zhou＠gmail.com 26 Jul '11

26 Jul '11

Full_Name: Zhou Xianhua Version: 2.4 OS: Ubuntu11.04 URL: Submission from: (NULL) (116.231.39.45) page: http://www.openldap.org/doc/admin24/slapdconfig.html section: "6.2.2.1. backend <type>" There is a table's title called "Table 5.2: Database Backends", it should be "Table 6.2: Database Backends".

1 0

Re: (ITS#6994) Syncrepl with MozNSS inherits TLS context form main configuration breaking some syncrepl setups
by richm＠stanfordalumni.org 25 Jul '11

25 Jul '11

On 07/11/2011 10:44 AM, thibault.lemeur(a)supelec.fr wrote: > Full_Name: Thibault Le Meur > Version: 2.4.23-15 > OS: RHEL6 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (160.228.28.55) > > > Previously on my FC13 installation (openldap-servers-2.4.21-11) the main slapd > process used an X509 "server" while my syncrepl processes were using the > /etc/openldap/ldap.conf client configuration file in order to connect to my > LDAPs Syncrepl providers. > > In my new RHEL6 setup (openldap-servers-2.4.23-15.el6.x86_64) is linked to > MozNSS and Syncrepl can't connect to my LDAPs providers anymore because it > complains about the TLS context not beeing intitialized correctly (the server's > certificate isn't accepted as a client certificate). > > Here is the lightly obfuscated log: > > ---------------------------------------------------------- > ldap_connect_to_host: Trying 10.10.10.10:636 > ldap_pvt_connect: fd: 21 tm: -1 async: 0 > TLS: loaded CA certificate file /etc/ssl/cacerts/cacert.pem. > TLS: certificate [CN=myldap.mydom.fr,OU=myou,O=myorg,L=myloc,ST=myst,C=FR] is > not valid - error -8101:Unknown code ___f 91. > TLS: error: unable to set up client certificate authentication for certificate > named PEM Token #0:myldap.mydom.fr-cert.pem - 0 > TLS: error: unable to set up client certificate authentication using PEM Token > #0:myldap.mydom.fr-cert.pem - 0 > TLS: error: could not initialize moznss security context - error -8101:Unknown > code ___f 91 > TLS: can't create ssl handle. > slap_client_connect: URI=ldaps://otherldap.mydom.fr > DN="cn=myreplicationAccount,dc=mydom,dc=fr" ldap_sasl_bind_s failed (-1) > do_syncrepl: rid=125 rc -1 retrying (9 retries left) > ---------------------------------------------------------- > > Here is my syncrepl setup: > --------------------------------------------------------- > syncrepl rid=125 > provider=ldaps://otherldap.mydom.fr > type=refreshOnly > interval=00:00:03:00 > retry="60 10 300 +" > searchbase="dc=subranch,dc=mydom,dc=fr" > filter="(objectClass=*)" > scope=sub > schemachecking=off > bindmethod=simple > binddn="cn=myreplicationAccount,dc=mydom,dc=fr" > credentials="MyVerySecretPassword" > --------------------------------------------------------- > > My setup related to TLS: > --------------------------------------------------------- > TLSCipherSuite HIGH > TLSCertificateFile /etc/ssl/certs/myldap.mydom.fr-cert.pem > TLSCertificateKeyFile /etc/ssl/keys/myldap.mydom.fr-key.pem > TLSCACertificateFile /etc/ssl/cacerts/cacert.pem > --------------------------------------------------------- > > And my /etc/openldap/ldap.conf: > --------------------------------------------------------- > TLS_CACERT /etc/ssl/cacerts/cacert.pem > --------------------------------------------------------- > > Here is the obfuscated certificate: > --------------------------------------------------------- > Certificate: > Data: > Version: 3 (0x2) > Serial Number: 221 (0xdd) > Signature Algorithm: sha1WithRSAEncryption > Issuer: C=FR, ST=myst, L=myloc, O=myorg, OU=myou, > CN=myCA/emailAddress=myemail(a)mydom.fr > Validity > Not Before: Oct 2 16:42:15 2007 GMT > Not After : Dec 14 16:42:15 2012 GMT > Subject: C=FR, ST=myst, L=myloc, O=myorg, OU=myou, CN=myldap.mydom.fr > Subject Public Key Info: > Public Key Algorithm: rsaEncryption > Public-Key: (2048 bit) > Modulus: > ... > Exponent: 65537 (0x10001) > X509v3 extensions: > X509v3 Basic Constraints: > CA:FALSE > Netscape Cert Type: > SSL Server > Netscape Comment: > TinyCA Generated Certificate > X509v3 Subject Key Identifier: > ... > X509v3 Authority Key Identifier: > keyid:... > DirName:/C=FR/ST=myst/L=myloc/O=myorg/OU=myou/CN=myCA/emailAddress=thibault.lemeur@supelec.fr > serial:00 > > X509v3 Issuer Alternative Name: > <EMPTY> > > Netscape SSL Server Name: > myldap.mydom.fr > X509v3 Subject Alternative Name: > DNS:ldap, DNS:ldapalias1, DNS:ldapalias2, > DNS:ldapalias1.mydom.fr, DNS:ldapalias2.mydom.fr, DNS:ldap.mydom.fr, DNS:myldap, > DNS:myldap.mydom.fr > X509v3 Extended Key Usage: critical > TLS Web Server Authentication, Code Signing > Signature Algorithm: sha1WithRSAEncryption > ... > --------------------------------------------------------- I think this ITS is superseded by http://www.openldap.org/its/index.cgi?findid=7001 and http://www.openldap.org/its/index.cgi?findid=7002 Note that even with openldap built with openssl (ol 2.4.latest and openssl 1.0.x), the syncrepl tls context is inherited from the main server context, and the server cert is sent as the client cert. If the server sets TLSVerifyClient to never or allow, syncrepl will work, because the server will ignore the problems with the client cert. But if TLSVerifyClient is set to "try", "demand", or "hard", syncrepl will fail because the server always sends the server cert as the client cert, and since the server cert cannot also be used as a client cert, the server will correctly reject it.

1 0

(ITS#7002) Patch - Mozilla NSS - if client cert is bad, VerifyCert allow should warn and try should fail
by rmeggins＠redhat.com 25 Jul '11

25 Jul '11

Full_Name: Rich Megginson Version: 2.4.26 (tip of git OPENLDAP_REL_ENG_2_4) OS: RHEL6 URL: ftp://ftp.openldap.org/incoming/0001-Patch-Mozilla-NSS-if-client-cert-is-ba… Submission from: (NULL) (76.113.106.30) If the olcTLSVerifyClient is set to a value other than "never", the server should request that the client send a client certificate for possible use with client cert auth (e.g. SASL/EXTERNAL). If set to "allow", if the client sends a cert, and there are problems with it, the server will warn about problems, but will allow the SSL session to proceed without a client cert. If set to "try", if the client sends a cert, and there are problems with it, the server will warn about those problems, and shutdown the SSL session. If set to "demand" or "hard", the client must send a cert, and the server will shutdown the SSL session if there are problems. I added a new member of the tlsm context structure - tc_warn_only - if this is set, tlsm_verify_cert will only warn about errors, and only if TRACE level debug is set. This allows the server to warn but allow bad certs if "allow" is set, and warn and fail if "try" is set. Note: The patch applies on top of ITS#7001 - you cannot apply this patch first, then the patch to 7001

1 0

(ITS#7001) Patch - Mozilla NSS - memleak - free the return of tlsm_find_and_verify_cert_key
by rmeggins＠redhat.com 25 Jul '11

25 Jul '11

Full_Name: Rich Megginson Version: 2.4.26 (tip of git OPENLDAP_REL_ENG_2_4) OS: RHEL6 URL: ftp://ftp.openldap.org/incoming/0001-Patch-Mozilla-NSS-memleak-free-the-ret… Submission from: (NULL) (76.113.106.30) If tlsm_find_and_verify_cert_key finds the cert and/or key, and it fails to verify them, it will leave them allocated for the caller to dispose of. There were a couple of places that were not disposing of the cert and key upon error. These patch files are derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Red Hat. Red Hat has not assigned rights and/or interest in this work to any party. I, Rich Megginson am authorized by Red Hat, my employer, to release this work under the following terms. Red Hat hereby place the following modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice.

1 0

(ITS#7000) Slapd crashed during modrdn in syncrepl
by tedcheng＠symas.com 25 Jul '11

25 Jul '11

Full_Name: Ted C. Cheng Version: trunk OS: RHEL 5 x86_64 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (123.194.135.105) 2655 static int 2656 syncrepl_entry( 2657 syncinfo_t* si, . 3082 retry_modrdn:; 3083 rs_reinit( &rs_modify, REP_RESULT ); 3084 rc = op->o_bd->be_modrdn( op, &rs_modify ); 3085 3086 /* NOTE: noSuchObject should result because the new superior 3087 * has not been added yet (ITS#6472) */ #ifdef SLAPD_CRASHED_MODRDN_SYNCREPL 3088 if ( rc == LDAP_NO_SUCH_OBJECT && !BER_BVISNULL( op->orr_nnewSup )) { #else /* fix */ 3088 if ( rc == LDAP_NO_SUCH_OBJECT && (op->orr_nnewSup != NULL ) && !BER_BVISNULL( op->orr_nnewSup )) { #endif /* SLAPD_CRASHED_MODRDN_SYNCREPL */ 3089 Operation op2 = *op;

1 0

(ITS#6999) retry: counter not reaching zero, continuing on
by ml+openldap＠esmtp.org 25 Jul '11

25 Jul '11

Full_Name: Claus Assmann Version: 2.4.23 OS: Red Hat Enterprise Linux Server release 5.5 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (63.211.143.38) While trying to determine how syncrepl behaves in various error conditions, I encountered an unexpected behaviour in which the retry specification doesn't seem to work. A MASTER is set up to use push replication to a REPLICA as follows: database ldap hidden on suffix "" rootdn "cn=slapd-ldap" uri ldap://REPLICA/ lastmod on restrict all sync_use_subentry true acl-bind bindmethod=simple binddn="cn=Monitor" credentials=password syncrepl rid=001 provider=ldapi://%2Fvar%2Frun%2Fldapi binddn="cn=Manager" bindmethod=simple credentials=passwd searchbase="" type=refreshAndPersist retry="5 5 60 +" When I stop the REPLICA and add an entry on the MASTER, then the MASTER is retrying every 5s and claims that 4 (sometimes 3) retries are left: Jul 22 13:12:52 MASTER slapd[23778]: do_syncrepl: rid=001 rc 52 retrying (4 retries left) Jul 22 13:12:57 MASTER slapd[23778]: do_syncrepl: rid=001 rc 52 retrying (3 retries left) Jul 22 13:13:02 MASTER slapd[23778]: do_syncrepl: rid=001 rc 52 retrying (4 retries left) Jul 22 13:13:07 MASTER slapd[23778]: do_syncrepl: rid=001 rc 52 retrying (3 retries left) Jul 22 13:13:12 MASTER slapd[23778]: do_syncrepl: rid=001 rc 52 retrying (4 retries left) Jul 22 13:13:17 MASTER slapd[23778]: do_syncrepl: rid=001 rc 52 retrying (4 retries left) Jul 22 13:13:22 MASTER slapd[23778]: do_syncrepl: rid=001 rc 52 retrying (4 retries left) Jul 22 13:13:28 MASTER slapd[23778]: do_syncrepl: rid=001 rc 52 retrying (4 retries left) Jul 22 13:13:33 MASTER slapd[23778]: do_syncrepl: rid=001 rc 52 retrying (4 retries left) Jul 22 13:13:38 MASTER slapd[23778]: do_syncrepl: rid=001 rc 52 retrying (4 retries left) Jul 22 13:13:43 MASTER slapd[23778]: do_syncrepl: rid=001 rc 52 retrying (4 retries left) Jul 22 13:13:48 MASTER slapd[23778]: do_syncrepl: rid=001 rc 52 retrying (4 retries left) Jul 22 13:13:53 MASTER slapd[23778]: do_syncrepl: rid=001 rc 52 retrying (4 retries left) Jul 22 13:13:58 MASTER slapd[23778]: do_syncrepl: rid=001 rc 52 retrying (4 retries left) When I start REPLICA again, syncrepl succeeds. Do I have to set some other option such that the retry specification is actually used? That is, try every 5s for 5 times, then try every 60s. Or is the retry logic dependent on the error syncrepl encounters? The full log for one failed retry is: conn=1004 op=0 BIND dn="cn=manager" method=128 conn=1004 op=0 BIND dn="cn=manager" mech=SIMPLE ssf=0 conn=1004 op=0 RESULT tag=97 err=0 text= conn=1004 op=1 SRCH base="" scope=2 deref=0 filter="(objectClass=*)" conn=1004 op=1 SRCH attr=* + srs csn 20110722201233.471069Z#000000#001#000000 log csn 20110722201233.471069Z#000000#001#000000 cmp 0, too old log csn 20110722201252.820971Z#000000#001#000000 Entry uid=user68,ou=People,dc=example,dc=com CSN 20110722201233.471069Z#000000#001#000000 older or equal to ctx 20110722201233.471069Z#000000#001#000000 syncprov_search_response: cookie=rid=001,sid=001,csn=20110722201252.820971Z#000000#001#000000 syncrepl_entry: rid=001 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) syncrepl_entry: rid=001 inserted UUID 95b838a2-4b55-4bcc-8b00-be329b138db0 conn=1004 fd=15 ACCEPT from PATH=/var/run/ldapi (PATH=/var/run/ldapi) syncrepl_entry: rid=001 be_search (52) syncrepl_entry: rid=001 uid=user69,ou=People,dc=example,dc=com null_callback : error code 0x34 syncrepl_entry: rid=001 be_add uid=user69,ou=People,dc=example,dc=com (52) syncrepl_entry: rid=001 be_add uid=user69,ou=People,dc=example,dc=com failed (52) do_syncrepl: rid=001 rc 52 retrying (4 retries left) conn=1004 op=2 UNBIND conn=1004 fd=15 closed connection_read(15): no connection! connection_read(15): no connection!

1 0

(ITS#6998) MozNSS: when server certificate is not required, ignore expired issuer errors
by jvcelak＠redhat.com 20 Jul '11

20 Jul '11

Full_Name: Jan Vcelak Version: 2.4.26 OS: Linux URL: ftp://ftp.openldap.org/incoming/jvcelak-nss-ignore-issuer-expiration-110720… Submission from: (NULL) (209.132.186.34) Hello. When the server certificate validity is not required in a TLS session (e.g. TLS_REQCERT is set to 'never'), expired certificate of the issuer of the server certificate causes the connection to be terminated. Uploaded patch fixes this by adding SEC_ERROR_EXPIRED_ISSUER_CERTIFICATE error to the list of ignored errors, when the certificate is not being checked. The patch is created against OPENLDAP_REL_ENG_2_4 branch. Jan

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