Deprecated ldap_int_tls_config in rlm_ldap

[John Dennis]

I was going through some of our fixes for 2.x and noticed that the new 
rlm_ldap for 3.0 has the same problem. Apparently Arron wondered about 
the use of  ldap_int_tls_config as well and wrote up this issue:

https://github.com/FreeRADIUS/freeradius-server/issues/236

The short story is that ldap_int_tls_config was never meant to be a 
public LDAP API, that's why it's not in the public header! But more to 
the point OpenLDAP has addressed the TLS configuration issues a while 
ago. Note OpenLDAP provides the *client* library most everyone uses, 
this is not an OpenLDAP server issue, we're talking client code here 
independent of your LDAP server of choice.

The code in question centers around setting the REQUIRE_CERT option. To 
be able to use the correct API for setting REQUIRE_CERT one has to 
enable the NEW_TLS_CTX option (this is how OpenLDAP fixed the use of 
bogus use ldap_int_tls_config, by moving the TLS options into the 
standard config area). The old deprecated LDAP API took string 
arguments, the new API uses enumerated constants. To preserve backwards 
compatibility with rlm_ldap and because we really don't want enumerated 
constants in the rlm_ldap module config we also need to translate the 
string option to an enumerated constant.

I could not figure out how to attach a patch to the github issue, so a 
git formatted patch is attached which can be applied with git-am or 
git-apply. This patch is against master (the rewritten rlm_ldap).

Caveat: I have not actually tested the proposed patch against master, I 
simply ported our 2.x patch which had been tested.

Note, the 2.x rlm_ldap has the same issue and the only reason we didn't 
push a 2.x patch yet is because while testing we discovered a bug in the 
OpenLDAP TLS driver code in which operations related to TLS were 
performed in the wrong order, that has since been fixed and was 
restricted to the case where NSS was the TLS provider. Once we finish 
testing the 2.x I'll submit that as well. But as far as I'm concerned in 
the new FreeRADIUS 3.x version there should be no reference whatsoever 
to a non-public deprecated LDAP API, instead 3.x should only use the 
currently defined public LDAP API's, trying to be backward compatible to 
something that was broken is not something that should be carried 
forward into a new version.


-- 
John Dennis <jdennis at redhat.com>

Looking to carve out IT costs?
www.redhat.com/carveoutcosts/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Replace-deprecated-ldap_int_tls_config-with-new-TLS-.patch
Type: text/x-patch
Size: 4046 bytes
Desc: not available
URL: <http://lists.freeradius.org/pipermail/freeradius-devel/attachments/20130506/5d29451b/attachment-0001.bin>