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
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
