Deprecated ldap_int_tls_config in rlm_ldap
jdennis at redhat.com
Mon May 6 19:45:06 CEST 2013
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:
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?
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 4046 bytes
Desc: not available
More information about the Freeradius-Devel