Hi,
I just started looking at FreeRadius and tried to get version 0.3
to work in a configuration similar to my current Livingston 2.1 server.
I noticed 2 things that were a little disconcerting. Both situations
can be worked around, but I'd like to mention them as "nice-to-have".
LOCAL realm handling
--------------------
I tried to define a realm to strip @epix.net from a username and
authorize/authenticate with just the username :
radiusd.conf file :
...
realm suffix {
format = suffix
delimiter = "@"
}
...
realms file :
...
epix.net LOCAL
...
My first attempt at running /usr/local/sbin/radiusd -X
resulted in the following output :
...
read_config_files: reading realms
/usr/local/etc/raddb/realms[33]: Cannot find 'clients' file entry of
remote server LOCAL for realm "epix.net"
Errors reading realms
...
I can work around that problem by adding a client entry for localhost
but I was wondering if it wouldn't be better to skip client_find at
line 433 of src/main/files.c if hostnm is LOCAL.
PW_PASSWORD handling by paircmp() in src/main/valuepair.c
---------------------------------------------------------
I tried the following authentication parameters that were
supported in Livingstion radius 2.1 (and still seem to have
support at least in src/main/auth.c) :
levan Password = "UNIX", Auth-Type = System
levan Password = "xxxxxxxxxxxxx", Auth-Type = Crypt-Local
levan Password = "xxxxxxxxxxxxx", Auth-Type = Reject
(I realize that Reject and System do not need a password and
Crypt-Local could be specified with Crypt-Password but it would
be nice to be able to inactivate/reactivate a user by just changing
the Auth-Type, without touching the Password attribute, which is
why I was trying to keep it in the above examples.)
Upon running "radtest levan xxxxxxxx localhost 10 xxxxxxx", the
radius server outputs :
rad_recv: Access-Request packet from host 127.0.0.1:33543, id=111,
length=55
User-Name = "levan"
Password = "......"
NAS-IP-Address = 255.255.255.255
NAS-Port-Id = "10"
rad_lowerpair: User-Name now 'levan'
modcall: entering group authorize
modcall[authorize]: module "suffix" returns ok
rlm_fastusers: checking defaults
rlm_fastusers: user not found
modcall[authorize]: module "fastusers" returns notfound
modcall: group authorize returns ok
auth: No Auth-Type configuration for the request, rejecting the user
auth: Failed to validate the user.
This behaviour seems to come from the fact that, although the
documentation states that authentication parameters are ignored
when scanning the users file for a matching entry, paircmp() in
valuepair.c happens to contain the following code at line 235 :
...
/*
* IF the password attribute exists, THEN
* we can do comparisons against it. If not,
* then the request did NOT contain a Password
* attribute, so we CANNOT do comparisons
* against it.
*
* This hack makes CHAP-Password work..
*/
case PW_PASSWORD:
if (pairfind(request, PW_PASSWORD) == NULL) {
check_item = check_item->next;
continue;
}
break;
...
And paircmp() is called by rlm_files and rlm_fastusers to find
the user entry : in both cases, paircmp() tries to do a straight
comparison against a special keyword or an encrypted password,
before the authentication part is reaching.
I do not know what that reference to a CHAP hack means, but if it
really needed, I can see 2 conflicting requirements for paircmp().
Maybe the CHAP hack should be removed if it is unused, or maybe
paircmp() should take an additional parameter to turn it on or off.
I couldn't figure out the reason for keeping PW_PASSWORD in any
of the files using paircmp() :
modules/rlm_attr_filter/rlm_attr_filter.c
modules/rlm_fastusers/rlm_fastusers.c
modules/rlm_files/rlm_files.c
modules/rlm_preprocess/rlm_preprocess.c
modules/rlm_sql/rlm_sql.c
Philippe.
---
Philippe Levan | Systems Engineering
[EMAIL PROTECTED] | epix Internet Services
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
