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.