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

[Phil Mayers]

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.