FreeRADIUS 2.0.4, Prefix/Suffix

[Alan DeKok]

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.