[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: slapd-meta and tls_reqcert=allow



I've patched (locally) Redhat's  2.4.23-26 rpm with http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=patch;h=1760501cea561c2794b1bfaf0e619a531a654799   and it now works as expected.

Thanks again.


From: Jim Vanes <jimvanes@yahoo.ca>
To: Manuel Gaupp <mgaupp@googlemail.com>
Cc: OpenLDAP <openldap-technical@openldap.org>
Sent: Friday, February 1, 2013 10:47:58 AM
Subject: Re: slapd-meta and tls_reqcert=allow

Thanks!  I've looked for any ITS regarding this but failed to find anything.  I'll try with a newer version. 


From: Manuel Gaupp <mgaupp@googlemail.com>
To: Jim Vanes <jimvanes@yahoo.ca>
Cc: OpenLDAP <openldap-technical@openldap.org>
Sent: Friday, February 1, 2013 5:59:42 AM
Subject: Re: slapd-meta and tls_reqcert=allow


Jim Vanes <jimvanes@yahoo.ca> wrote:

> I'm using OpenLDAP 2.4.23-26 from Centos 6. I seem to be hitting a configuration issue regarding slapd-meta and SSL/TLS.
>
> Here is my meta config:
>
> database        meta
> suffix          "dc=virtual,dc=local"
> rootdn          "cn=root,dc=virtual,dc=local"
> rootpw          password
>
> # Local
> uri            ldap://localhost/dc=ds1,dc=virtual,dc=local
> suffixmassage  "dc=ds1,dc=virtual,dc=local" "dc=lab,dc=local"
> idassert-bind  bindmethod=simple binddn="cn=root,dc=lab,dc=local" credentials=password
>
> #Remote AD server
> uri ldap://10.33.63.125:389/dc=ad1,dc=virtual,dc=local
> tls start
> suffixmassage "dc=ad1,dc=virtual,dc=local" "dc=mslab,dc=local"
> idassert-bind bindmethod=simple binddn="CN=Sync,CN=Users,DC=lab,DC=local" credentials="Password1" starttls="yes" tls_reqcert="allow"
>
> It seems as though  tls_reqcert="allow" is ignored for the remote AD server.  If set that variable in the ldap.conf everything works fine.  But shouldn't the above function as an override to the default of 'demand'?  The behaviour is the same when I change the above to use SSL instead.

I think you're running into an issue that I reported in September 2010.
See http://www.openldap.org/lists/openldap-technical/201009/msg00073.html and http://www.openldap.org/its/index.cgi?findid=6642

According to the Release Change Log, this issue should have been fixed in release 2.4.24. So you should definitely update to a more recent release.

Best regards,
Manuel