First things first - can I clarify that your goal is to have users, using EAP TTLS/PAP, authenticating against LDAP entries. The LDAP entries are of the form: dn: cn=j_doe,ou=... cn: j_doe userPassword: {SSHA}bhjqewhtqothethwe== Correct? Looking at the first LDAP debug you show, we see:
...
...you've trimmed the debug lines above this - not helpful, but I think I can see the problem:
rlm_ldap: performing user authorization for j_doe expand: %{Stripped-User-Name} -> expand: %{User-Name} -> j_doe expand: (&(cn=%{%{Stripped-User-Name}:-%{User-Name}})(search filter trimmed for brevity)) -> (&(cn=j_doe)(search filter trimmed for brevity)) expand: ou=people,dc=concordia,dc=ca -> ou=people,dc=concordia,dc=ca rlm_ldap: ldap_get_conn: Checking Id: 0 rlm_ldap: ldap_get_conn: Got Id: 0 rlm_ldap: performing search in ou=people,dc=concordia,dc=ca, with filter (&(cn=j_doe)(search filter trimmed for brevity)) rlm_ldap: Added User-Password = {SSHA}*SANITIZED*e2E52K+sO/SC+wvE*SANITIZED*== in check items rlm_ldap: looking for check items in directory... rlm_ldap: looking for reply items in directory... rlm_ldap: user j_doe authorized to use remote access rlm_ldap: ldap_release_conn: Release Id: 0 ++[ldap] returns ok ++[expiration] returns noop ++[logintime] returns noop ++[pap] returns noop
Notice that "pap" does a no-op here. As far as I can see, rlm_pap should update the request, and from the source the only times it will no-op *SILENTLY* are: * if the config items contains Proxy-To-Realm AND the value of that attribute is a valid realm in proxy.conf AND the realm has no servers (and I think that last boolean is a bug/inverted) * or, there's no password attribute found AND: * the request is being proxied * or, the request is EAP-PEAP or EAP-TTLS or EAP-TLS do some buggy stuff... * or it's an Access-Challenge Basically, I think there is a logic check inverted in rlm_pap that means it's doing a no-op when it shouldn't
WARNING: You set Proxy-To-Realm = LOCAL, but it is a LOCAL realm! Cancelling invalid proxy request.
...try removing the "Proxy-To-Realm" stuff - it's not needed in your case.
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!! Replacing User-Password in config items with Cleartext-Password. !!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!! Please update your configuration so that the "known good" !!! !!! clear text password is in Cleartext-Password, and not in User-Password. !!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
These warnings appear because the Auth-Type defaults to Local
auth: type Local auth: user supplied User-Password does NOT match local User-Password auth: Failed to validate the user.
...and the "Local" auth type is handled internally by the server core, and doesn't do the magic required to recognize the {SSHA} in the User-Password config item.
Login incorrect: [j_doe/*SANITIZED*] (from client wireless-mcconnell
...hence login fails. Much later in your email, you list the output of a radtest against LDAP. Because that isn't EAP-TTLS, there's no tunnel and thus the rlm_pap bug isn't triggered.
radeapclient against a user listed in the users file still performs the ldap query for authorization (I actually don't want that; I'd like the users file to over-ride the LDAP listing, if an entry is matched in the users file),
In that case, you will need to configure the server appropriately - in older versions of the server you'd do this: authorize { preprocess files Autz-Type LDAP { ldap } } ...and in users: j_doe Cleartext-Password := "foo" DEFAULT Calling-Station-Id == "0011.2233.4455", Auth-Type := Reject DEFAULT Autz-Type := LDAP ...or something like: authorize { preprocess redundant { files ldap } } ...in 2.x versions of the server you might want to use "unlang"
but then seems to stop short of setting up the TTLS tunnel and performing any authentication:
radeapclient says:
In my opinion, radeapclient is not terribly useful. I would recommend compiling eapol_test from the "wpa_supplicant" package; it can do a full EAP TTLS/PAP request against a radius server.
Can someone please tell me where I should be looking? As promised, the unified context diff of my configuration against the default is appended below my signature.
As has been pointed out in another email, you have set: modules { ldap { ... password_radius_attribute = "SSHA-Password" } } "password_radius_attribute" is not a valid config item for the LDAP module; the ldap module will be ignoring it. You don't need it.