Deprecated ldap_int_tls_config in rlm_ldap

[Arran Cudbard-Bell]

On 6 May 2013, at 13:45, John Dennis <jdennis at redhat.com> wrote:

> 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

So close, still better than Aaron :)

> 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!

Yep.

> But more to the point OpenLDAP has addressed the TLS configuration issues a while ago.

Do you know the version? Want to make sure that it's checked in the autoconf script.

> 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).

You'd create a pull request that references the original issue. I think if you use something like '#fixes <issue number>' in the commit message it'll automatically reference the original issue.

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

The code is pretty similar for configuring the handles IIRC.

> 
> 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.
> 

OK. 

Arran Cudbard-Bell <a.cudbardb at freeradius.org>
FreeRADIUS Development Team