Hi Kostas
I wanted to submit a patch to rlm_ldap (see below). The patch is very simple - the
addition of one line, and change of an existing line, to rlm_ldap.c.
=============== PATCH ========================
[EMAIL PROTECTED] SOURCES]# cat freeradius-0.9.3-tlsmode.patch
--- freeradius-0.9.3/src/modules/rlm_ldap/rlm_ldap.c.tlsmode 2003-09-28
23:24:50.000000000 +1000
+++ freeradius-0.9.3/src/modules/rlm_ldap/rlm_ldap.c 2004-04-02 13:53:23.000000000
+1000
@@ -270,6 +270,7 @@
/* allow server unlimited time for search (server-side limit) */
{"timelimit", PW_TYPE_INTEGER, offsetof(ldap_instance,timelimit), NULL, "20"},
{"identity", PW_TYPE_STRING_PTR, offsetof(ldap_instance,login), NULL, ""},
+ {"tls_mode", PW_TYPE_BOOLEAN, offsetof(ldap_instance,tls_mode), NULL, "no"},
{"start_tls", PW_TYPE_BOOLEAN, offsetof(ldap_instance,start_tls), NULL, "no"},
{"password", PW_TYPE_STRING_PTR, offsetof(ldap_instance,password), NULL, ""},
{"basedn", PW_TYPE_STRING_PTR, offsetof(ldap_instance,basedn), NULL,
"o=notexist"},
@@ -377,7 +378,7 @@
inst->timeout.tv_usec = 0;
inst->net_timeout.tv_usec = 0;
/* workaround for servers which support LDAPS but not START TLS */
- if(inst->port == LDAPS_PORT)
+ if((inst->tls_mode) || (inst->port == LDAPS_PORT))
inst->tls_mode = LDAP_OPT_X_TLS_HARD;
else
inst->tls_mode = 0;
=============== END PATCH ====================
What the patch does is enable FreeRadius to link up to LDAP servers on non-standard
ports using TLS, in situations where START_TLS cannot be used. Currently, the code in
rlm_ldap uses the standard LDAPS port (636) to see is the tls_mode flag needs to be
set to LDAP_OPT_X_TLS_HARD. There does not appear to be any other way to set tls_mode
when the port is not 636. The actual tls_mode int variable in the ldap_instance
structure and all other supporting code already existed in the module source. All that
needed to be done was to add tls_mode as a valid choice in the parser table, and an OR
check for the variable being set in radiusd.conf. (I seem to recall tls_mode was a
valid config string at one time - perhaps it was removed).
For those who want to know why this is necessary, read on. As you perhaps know, MS
Active Directory (as an LDAP server) does not work with START_TLS (I believe Novell
eDirectory is the same). To get LDAP with TLS (LDAPS), the normal option is to set
start_tls=no and set port=636 in radiusd.conf. This works fine for communication over
port 636. However, depending on the base DN used, and the location of the users in the
tree, a simple LDAP request for group membership check can result in a series of
LDAPv3 referrals. These are, at the minimum, to the base DN supplied (which may be at
the LDAP root in some cases), and with Windows Server 2003 DCs, includes referrals to
ForestDNSZones.<something> and DomainDNSZones.<something>. These referrals, with
normal DNS resolution, may result in servers being contacted (or attempted to be
contacted) that were not part of the list of LDAP servers configured in radiusd.conf
(whether or not configurable failover is being used). Besides slowing the LDAP
authentication/authorisation process immensely, this causes network ACL complications
when the FreeRadius servers and LDAP servers are on different sides of firewalls.
To alleviate this situation, I attempted to contact the Windows AD Global Catalog
directly (which is also contactable via LDAP and LDAPS but on TCP ports 3268 and 3269
respectively), after contacting our MS technical rep. With LDAP (i.e without TLS),
this worked blindingly fast with no referrals at all. However, I was stuck when I
wanted to connect with LDAP & TLS over port 3269 as there was no way to trigger
tls_mode with a port other than 636. Incidentally, the URL form
"ldaps://somedc.somecompany.com:3269" does not work as it attempts to tag on ":389" to
it, or, if "port=3269" is also used, tries to make some other calls to "ldap://:389";,
with no hostname at all.
To cut a long story short, the simple patch enabled me to connect to the GC with LDAP
& TLS over port 3269 with the following in the ldap radiusd.conf:
ldap ldap1 {
server = "somedc.somecompany.com"
port = 3269
<snip>
start_tls = no
tls_mode = yes
<snip>
}
<and similar for the other LDAP servers>
This enabled me to get responses in 10 milliseconds as opposed to the 2000 to 3000
milliseconds it used to take earlier.
Tarun Bhushan
Principal Information Security Consultant
Macquarie Bank Limited
1 Martin Place
Sydney NSW 2000
EMail: [EMAIL PROTECTED]
NOTICE
This e-mail and any attachments are confidential and may contain copyright material of
Macquarie Bank or third parties. If you are not the intended recipient of this email
you should not read, print, re-transmit, store or act in reliance on this e-mail or
any attachments, and should destroy all copies of them. Macquarie Bank does not
guarantee the integrity of any emails or any attached files. The views or opinions
expressed are the author's own and may not reflect the views or opinions of Macquarie
Bank.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
