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@alcor.concordia.ca Systems and Network analyst Concordia University Instructional & Information Technology Montreal, Quebec, Canada ----------------------------------------------------------------------