Alan,
please excuse my foolery. I just had a look at the changelog and into the
source of the preprocessor and files module, but because I'm currently not in,
I'm doing hard. ;-)
If it's the wanted behaviour that %{Stripped-User-Name} is used over
%{User-Name} to lookup users that's everything I need to know, yet. I assume
this behaviour is different depending on the modules used for authorization and
their configuration. That's it I wanted to know.
I'm not just a user, I'm a developer too and so I'll try to get a better
understanding about what's happening behind the scenes. But currently I'm
really new to RADIUS and FreeRADIUS in special...
So long,
Robert.
-----Original Message-----
From: freeradius-users-bounces+robert.borz=web...@lists.freeradius.org
[mailto:freeradius-users-bounces+robert.borz=web...@lists.freeradius.org] On
Behalf Of Alan DeKok
Sent: Saturday, December 27, 2008 2:50 PM
To: FreeRadius users mailing list
Subject: Re: FreeRADIUS 2.0.4, Prefix/Suffix
Robert Borz wrote:
> You're right, it is fixed in the current version, but there's one thing I
> still don't understand. Comparing the debug output...
>
> --- FreeRADIUS v2.0.4 ---
> rad_recv: Access-Request packet from host 84.154.9.221 port 3402, id=32,
> length=46
> User-Name = "Speter"
> User-Password = "secret1"
> +- entering group authorize
> hints: Matched DEFAULT at 1
The prefix/suffix stripping doesn't work in 2.0.4.
> ++[preprocess] returns ok
> ++[mschap] returns noop
> expand: %{Stripped-User-Name} -> peter
> ++[files] returns noop
Because that version has a bug.
> rlm_pap: WARNING! No "known good" password found for the user.
> Authentication may fail because of this.
> ...
>
> --- FreeRADIUS v2.1.3 ---
> rad_recv: Access-Request packet from host 84.154.9.221 port 3395, id=31,
> length=46
> User-Name = "Speter"
> User-Password = "secret1"
> +- entering group authorize {...}
> [preprocess] hints: Matched DEFAULT at 1
> ++[preprocess] returns ok
> ++[mschap] returns noop
> [files] expand: %{Stripped-User-Name} -> peter
> [files] users: Matched entry peter at line 14
Because the stripped user name does exist.
> ...it seems to me that if in the hints file Strip-User-Name is set ("yes"),
> in the authorize section Stripped-User-Name (if exists) will be used instead
> of User-Name to lookup the user. So it isn't necessary to add a statement
> like 'User-Name = "%{Stripped-User-Name}"' in the users or hints file to
> overwrite User-Name attribute supplied in the Request?
Just... stop.
You've been told that 2.0.4 has the bug, and 2.1.3 doesn't. The debug
output you've posted shows this.
If you really know the in-depth explanation as to what the bug was,
what side-effects it had, and how it was fixed, go read the source code.
>> Yes. Stripped-User-Name wasn't created. And as Alan pointed out - it was
>> fixed in later release.
>
> Stripped-User-Name is created in both versions. If I include 'User-Name =
> "%{Stripped-User-Name}"' on the reply, the stripped user name (without prefix
> or suffix) is returned to the client. Just to make sure we're talking about
> the same bug...
>
> So, if User-Name and Stripped-User-Name exists, it isn't obvious to me, that
> Stripped-User-Name is used instead of User-Name to look up the users
> credentials. Is this the wanted behaviour?
Yes.
Alan DeKok.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
