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.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
