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 <[email protected]> To: Manuel Gaupp <[email protected]> Cc: OpenLDAP <[email protected]> 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 <[email protected]> To: Jim Vanes <[email protected]> Cc: OpenLDAP <[email protected]> Sent: Friday, February 1, 2013 5:59:42 AM Subject: Re: slapd-meta and tls_reqcert=allow Jim Vanes <[email protected]> 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
