FreeRADIUS 2.0.4, Prefix/Suffix

[Robert Borz]

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.de at lists.freeradius.org [mailto:freeradius-users-bounces+robert.borz=web.de at 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