Stripped-User-Name Problems (Re: Unmatched ( or \(, and, more broadly, setting Stripped-User-Name)

[Jacob Dawson]

On 15 Jul 2011, at 02:51, Alan DeKok wrote:

> Jacob Dawson wrote:
>> Further testing suggests that neither of the Perl or Realm modules is applying the Stripped-User-Name in the right scope.
> 
>  I have no idea what that means.  The Stripped-User-Name isn't magic.
> It's just an attribute.  If it exists in the request list, you can refer
> to it via %{Stripped-User-Name}
> 
>  If it's "magically" disappearing, then it's because something in your
> configuration is making it disappear.  The default configuration works,
> and doesn't do this.
In the case of the perl module, it was me doing the boneheaded thing of adding it to RADREPLY and not RADREQUEST.  Given that mistake corrected, and that I got my unlang mangling of the request also functioning properly, I'm making forward progress again.  Thanks to the community for that.

As far as realms goes...I found my error.  I commented out a small chunk of code in rlm_realm.c that I don't think does quite the right thing, but on further reading, I realize that, while it might not do what I think is quite the right thing, it still does something important, and that's actually writing attributes to the request.

Unfortunately, when you set nostrip in the config, it doesn't add a Stripped-User-Name attribute to the request, but when you unset it, rlm_realms adds a Stripped-User-Name attribute and also updates the User-Name attribute to the same value.  Since I need to perform some authorization checks on the stripped user name, if I want to do this with realms, I need to unset nostrip, but if I do that, it rewrites User-Name, and then the wrong username (the stripped one) gets sent to my AD servers, which reject it.  Consequently, I don't think those three lines do quite the right thing, but I'm leery of submitting a patch to change that, because it's a noticeable change to the behavior.

Thanks for making me look it over again.

- Jacob