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

[Alan DeKok]

Sylvain Robitaille wrote:
>  In fact, I've been trying to get this working for
> years with older versions of FreeRADIUS, and have succeeded only with
> FreeRADIUS<=1.1.6, using configurations that readers of this list are
> repeatedly told not to use (such as setting Auth-Type in the users file).

  It really depends on what you're doing.  The recommendations against
setting Auth-Type are there because almost everyone gets it wrong.
There *are* situations where setting it is the right thing to do.  But
it's almost always wrong...

> [ASIDE]
>    With the older versions of FreeRADIUS we're having performance problems
>    with the authentication.  Research on this list has uncovered no end
>    of responses that such problems are normally caused by the back-end,
>    not radiusd, but our backend (OpenLDAP) responds to an identical query
>    as that sent by radius in approximately 6ms (7ms when it's slow), yet
>    radiusd is still not responding after 30 seconds.  We have thousands
>    of users trying to use our service simultaneously, through hundreds
>    of wireless access points.

  Run it in debugging mode to see what the problem is.  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.

> What I have seems to pass tests that have been recommended as "get these
> working before moving on", but I can't seem to figure out how to get
> from here to being able to unleash my access points on this and have
> successful authentications.  I see (from -X output) that the TTLS tunnel
> is successfully built (that seems to be several steps), a query against
> LDAP for authorization (and to retrieve the user's encypted password)
> succeeds, but when the request finally gets to the authentication,
> radiusd reports:

  You may need to install "sites-available/inner-tunnel".  There's a
symlink from 'sites-enables/inner-tunnel" to
"sites-availabe/inner-tunnel"... which isn't installed in 2.0.3, due to
a bug in the Makefile.

>   WARNING: You set Proxy-To-Realm = LOCAL, but it is a LOCAL realm! 
> Cancelling invalid proxy request.
> 
> Is this caused by the following in raddb/sites-*/inner-tunnel?

  Yes.  The message is there to warn people about common
misconfigurations.  Don't worry about it.

> The text "User-Password" appears in exactly the following places in my
> raddb directory (not counting comment lines):

  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.

> The above issues of course still don't address what I see as the real
> problem:
> 
>    Login incorrect: [j_doe/*SANITIZED*] ...
> 
> Somebody please tell me where I should be looking to make this work
> correctly.

  It doesn't work because the PAP module isn't doing anything.  The PAP
module *should* be taking the crypt'd password, and doing something
useful with it.  (See "man rlm_pap")

> I can run the new server on an alternate port for the preliminary
> tests, such as using radtest against a user in LDAP (success), 

  Yes... because it's behaving differently.  See the debug output for
what differences there are.

> and
> radeapclient against a user in the users file (success using md5
> as the default_eap_type, but not ttls), 

  Because you're putting a clear-text password in the "users" file, not
a SSHA encrypted blob like you're getting from LDAP.

  Compare apples to apples, not apples to oranges.  If you put the
*same* SSHA blob you get from ldap into the "users" file, then it would
likely behave differently...

  Alan DeKok.