yet ANOTHER EAP-TTLS/PAP with OpenLDAP problem ...

[Sylvain Robitaille]

As promised, I'm reporting back with results from items discussed over
the weekend ...

> On Sat, 29 Mar 2008, Arran Cudbard-Bell wrote:
>> 
>> ldap {
>> 	auto_header = yes
>> }

As discussed, this duplicates functionality that is better handled by
the rlm_pap module.  I'm following Alan DeKok's reccomendation on this,
and leaving that out, so that rlm_pap can perform all handling of the
encrypted password.

> On Sat, 29 Mar 2008, Alan DeKok wrote:
>
>> There isn't really a whole lot that can go wrong with the server.  If
>> it's waiting more than 30 seconds to respond, then the likelihood is
>> that it's doing DNS lookups, and DNS is broken.

I haven't run our existing FreeRadius-1.1.6 server in debug mode to
verify this, but I've put in the LDAP server(s) in the /etc/hosts file,
to reduce its likelihood.  After taking further actions (described
below), I'm now running with 2.0.3.  So far it's performing better than
1.1.6, but that's with a significantly different configuration than
1.1.6 has (I'm much closer to an uneditted default config with 2.0.3).

>> That's not the issue.  The issue is that the rlm_ldap module is
>> reading the "userPassword" ldap field, and creating a User-Password
>> attribute.  It could really be fixed.

It seems, at least according to further developments, that rlm_ldap
already is putting the "userPassword" in the correct attribute for
rlm_pap, so I don't think anything needs to be done to followup on that,
at least not specifically for my case.

> On Sat, 29 Mar 2008, Phil Mayers wrote:
>
>> I don't have a copy of 2.0.3 handy, but this looks like a bug to me at
>> ~line 383 of rlm_pap.c:
>> 
>> case PW_PROXY_TO_REALM:
>> {
>>        REALM *realm = realm_find(vp->vp_strvalue);
>>        if (realm && !realm->auth_pool) {
>>                return RLM_MODULE_NOOP;
>>        }
>>        break;
>> }

I patched my copy here, recompiled, and tested: reversing this condition
indeed produces an rlm_pap that seems to do the right thing.

> On Sat, 29 Mar 2008, Alan DeKok wrote:
>
>> It may be the bug in rlm_pap.  Grab a current CVS snapshot, and see if
>> that works any better.

Hrmmm... That one segfaults on the first authentication request it
receives.  Correction: it's an accounting request for a "stop".

I'm not sure if it's segfaulting because of anything I did wrong, or not.
Debug output is fine for all config-file processing; the configuration
is identical to my now functioning (patched) 2.0.3 installation.  If the
debug output prior to what follows is still desired, I'll repost, but
the segfault occurs after what looks like a perfectly normal startup:

...
radiusd: #### Opening IP addresses and Ports ####
listen {
         type = "auth"
         ipaddr = *
         port = 0
}
listen {
         type = "acct"
         ipaddr = *
         port = 0
}
Listening on authentication address * port 1812
Listening on accounting address * port 1813
Listening on proxy address * port 1814
Ready to process requests.
rad_recv: Accounting-Request packet from host 192.168.154.6 port 1646, id=243, length=144
         Acct-Session-Id = "00012E2D"
         Called-Station-Id = "0009.b739.6eaf"
         Calling-Station-Id = "0012.f01b.9a62"
         User-Name = "j_smith"
         Acct-Session-Time = 0
         Acct-Input-Octets = 0
         Acct-Output-Octets = 178
         Acct-Input-Packets = 0
         Acct-Output-Packets = 2
         Acct-Terminate-Cause = Lost-Carrier
         Acct-Status-Type = Stop
         NAS-Port-Type = Wireless-802.11
         NAS-Port = 13349
         Service-Type = Framed-User
         NAS-IP-Address = 192.168.154.6
         Acct-Delay-Time = 96
+- entering group preacct
Segmentation fault

I tried this again on non-"production" ports, with input from
radeaptest, and that also fails, after "+- entering group authorize":
...
Listening on authentication address * port 1815
Listening on accounting address * port 1816
Listening on proxy address * port 1817
Ready to process requests.
rad_recv: Access-Request packet from host 127.0.0.1 port 42735, id=81, length=71
         User-Name = "j_doe"
         NAS-IP-Address = 192.168.198.20
         NAS-Port-Type = Wireless-802.11
         Message-Authenticator = 0xace3cf4de87a5f544d3a216c910a5542
         NAS-Port = 0
         EAP-Message = 0x02d200080173796c
+- entering group authorize

For some reason, I seem unable to get this to produce a core file to
try and track it down any further ("limit coredumpsize unlimited" as
root hasn't helped).  I'm not really able to spend more time on that,
given that I have a working 2.0.3, with patched rlm_pap, but if there's
something I can do to help gather more information I'm certainly willing
to try.

I'm going to return to configuring 2.0.3 with different authorization
queries for the various services we're using RADIUS with.  Hopefully
now I'll be able to do what I need without any further adventure.

Thanks to all who have followed along with this, and especially, of
course, to all who followed up with suggestions, recommendations, and
fixes.  Thanks also to those who put in so much time into creating and
maintaining this package.  You're making other people's jobs easier!

-- 
----------------------------------------------------------------------
Sylvain Robitaille                              syl at alcor.concordia.ca

Systems and Network analyst                       Concordia University
Instructional & Information Technology        Montreal, Quebec, Canada
----------------------------------------------------------------------