Unmatched ( or \(, and, more broadly, setting Stripped-User-Name
So, one of my last things here is making sure I can get at the stripped usernames for my domain users, as they're authorized by their stripped name, not the name w/ which they're authenticating. Forex, if I'm using my AD credentials to log in, User-Name = hokies\dawson, but I'm authorized for WLAN access as 'dawson,' not 'hokies\dawson.' That's all well and good, as I should just be able to use Stripped-User-Name in my queries and it'll be fine (assuming it exists, using the :- operator and doing a little logic there, which I have working fine). However, I haven't found a way, or maybe just the right way, to get the realms module to create that stripped user name at the right time, and when I use the perl module to create it and add it to the list, it doesn't seem to come out the other side, like so: rlm_perl: Added pair User-Name = hokies\\dawson ... rlm_perl: Added pair Stripped-User-Name = dawson (1) [perl] = updated (1) ? if ("%{Stripped-User-Name}" == "dawson") (1) expand: %{Stripped-User-Name} -> (1) ? Evaluating ("%{Stripped-User-Name}" == "dawson") -> FALSE (1) ? if ("%{Stripped-User-Name}" == "dawson") -> FALSE I uncommented the func_authorize = authorize line in modules/perl, and the script to which the perl module points has this for its authorize function: sub authorize { # For debugging purposes only # &log_request_attributes; # Logic to add stripped user name to request if our realms are recognized my $fullUserName = $RAD_REQUEST{'User-Name'}; #If we have a prefix-determined domain if ( $fullUserName =~/^.*\\(\\)?/i){ $RAD_REPLY{'Stripped-User-Name'} = $'; return RLM_MODULE_UPDATED; } #If we have a suffix-determined domain elsif ( $fullUserName =~/\@.*$/){ $RAD_REPLY{'Stripped-User-Name'} = $`; return RLM_MODULE_UPDATED; } return RLM_MODULE_OK; } Obviously, the regexps are working and the logic is working, based on the debug output, but since in the very next line, Stripped-User-Name is blank again, something's not working here. I _tried_ getting this working in unlang, but that got mess pretty fast, and started complaining about unmatched parens: (1) ? elsif ("%{User-Name}" =~ /^(.*\\)(.*)$/) (1) expand: %{User-Name} -> hokies\dawson ERROR: Failed compiling regular expression: Unmatched ( or \( (1) - if ("%{User-Name}" !~ /^.*\/.*$/) returns updated where the relevant part of sites-enabled/default authorize section looks thus: elsif("%{User-Name}" =~ /^(.*\\)(.*)$/){ update request{ Stripped-User-Name := "%{$`}" } } (I can't tell if the assignment is working or not, since it never gets that far, but I wouldn't be surprised if it shouldn't work in that state) One of these ought to be writing the Attribute correctly, but not a one of them has worked. Manually writing to the attribute works (Stripped-User-Name:="dawson") but that's hardly the right answer. I'm out of ideas here. I can't tell if I'm getting unexpected behavior out of FreeRADIUS, or I'm just missing something. Thoughts? Thanks much, - Jacob
In article <795D5EE4-7536-431E-926A-98E70EFA1771@vt.edu> you wrote:
So, one of my last things here is making sure I can get at the stripped usernames for my domain users, as they're authorized by their stripped name, not the name w/ which they're authenticating. Forex, if I'm using my AD credentials to log in, User-Name = hokies\dawson, but I'm authorized for WLAN access as 'dawson,' not 'hokies\dawson.'
Although to prevent down the road severe levels of pain when enabling eduroam you should be using something like 'dawson@hokies.vt.edu', could you not just use 'ntdomain' (a built in module that will do this for you)? 'ntdomain' should create Realm and Stripped-User-Name in the manner you want.
That's all well and good, as I should just be able to use Stripped-User-Name in my queries and it'll be fine (assuming it exists, using the :- operator and doing a little logic there, which I have working fine). However, I haven't found a way, or maybe just the right way, to get the realms module to create that stripped user name at the right time, and when I use the perl module to create it and add it to the list, it doesn't seem to come out the other side, like so:
[snipped]
I _tried_ getting this working in unlang, but that got mess pretty fast, and started complaining about unmatched parens:
I was going to ask why you were not doing the perl stuff in unlang. :)
(1) ? elsif ("%{User-Name}" =~ /^(.*\\)(.*)$/) (1) expand: %{User-Name} -> hokies\dawson ERROR: Failed compiling regular expression: Unmatched ( or \( (1) - if ("%{User-Name}" !~ /^.*\/.*$/) returns updated
where the relevant part of sites-enabled/default authorize section looks thus:
elsif("%{User-Name}" =~ /^(.*\\)(.*)$/){ update request{ Stripped-User-Name := "%{$`}" } }
$' and $` is a perlism. You want something like (look at policy.conf rewrite.calling_station_id and rewrite.called_station_id as an example): ---- if (User-Name =~ /^[^\\]\\?(.*)$/) { update request { Stripped-User-Name := "%{1}" } } ---- Untested, but hopefully you get the idea. :) Cheers -- Alexander Clouter .sigmonster says: Sauron is alive in Argentina!
On 14 Jul 2011, at 03:42, Alexander Clouter wrote:
In article <795D5EE4-7536-431E-926A-98E70EFA1771@vt.edu> you wrote: Although to prevent down the road severe levels of pain when enabling eduroam you should be using something like 'dawson@hokies.vt.edu', could you not just use 'ntdomain' (a built in module that will do this for you)? 'ntdomain' should create Realm and Stripped-User-Name in the manner you want. Are you suggesting that using a prefix domain like that will cause problems, or that I should be using the realms module? I have no problem with using the module, as it's worked well for the proxying side of things, but I need to be able to authorize the users on our domain, and that means I need to get a stripped username and pass it to the DB. I'll poke at it and see if I can get that side working.
I was going to ask why you were not doing the perl stuff in unlang. :)
It seemed like a good idea at the time.
(1) ? elsif ("%{User-Name}" =~ /^(.*\\)(.*)$/) (1) expand: %{User-Name} -> hokies\dawson ERROR: Failed compiling regular expression: Unmatched ( or \( (1) - if ("%{User-Name}" !~ /^.*\/.*$/) returns updated
where the relevant part of sites-enabled/default authorize section looks thus:
elsif("%{User-Name}" =~ /^(.*\\)(.*)$/){ update request{ Stripped-User-Name := "%{$`}" } }
$' and $` is a perlism. You want something like (look at policy.conf rewrite.calling_station_id and rewrite.called_station_id as an example): ---- if (User-Name =~ /^[^\\]\\?(.*)$/) { update request { Stripped-User-Name := "%{1}" } } ----
Untested, but hopefully you get the idea. :) This works a little better: elsif("%{User-Name}" =~ /^(.*)\\\\?(.*)$/){ update request{ Stripped-User-Name := "%{2}" } }
But gives this: (5) ? Evaluating ("%{User-Name}" =~ /^(.*)\\\\?(.*)$/) -> TRUE (5) ? elsif ("%{User-Name}" =~ /^(.*)\\\\?(.*)$/) -> TRUE (5) elsif ("%{User-Name}" =~ /^(.*)\\\\?(.*)$/) { (5) - entering elsif ("%{User-Name}" =~ /^(.*)\\\\?(.*)$/) {...} (5) update request { (5) expand: %{2} -> (5) } # update request = updated (5) - elsif ("%{User-Name}" =~ /^(.*)\\\\?(.*)$/) returns updated (5) - if ("%{User-Name}" !~ /^.*\/.*$/) returns updated .... (5) sql : expand: %{Stripped-User-Name} -> (5) sql : sql_set_user escaped user --> '' Not sure what I should be doing there. Changed it to %{0} and also to %{1} and both gave me hokies\dawson, which was at least successfully written into Stripped-User-Name. Would love some more insight into how unlang handles these things, as I'm sure we'll run into a use for it in the future, even if I manage a realms-based solution to this. Thanks much, - Jacob
So I played with my copy of the code to change what nostrip being unset means (now, it writes the Stripped-User-Name attribute, but no longer rewrites the User-Name attribute with the stripped username), and I'm still running into problems: (0) HOKIES : Looking up realm "hokies" for User-Name = "hokies\dawson" (0) HOKIES : Found realm "~HOKIES" (0) HOKIES : Adding Stripped-User-Name = "dawson" (0) HOKIES : Adding Realm = "hokies" (0) HOKIES : Proxying request from user dawson to realm ~HOKIES (0) HOKIES : Preparing to proxy authentication request to realm "~HOKIES" (0) [HOKIES] = updated (0) guest : Request already proxied. Ignoring. (0) [guest] = ok (0) - if ("%{User-Name}" !~ /^.*\/.*$/) returns updated (0) ... skipping elsif for request 0: Preceding "if" was taken (0) eap : Request is supposed to be proxied to Realm ~HOKIES. Not doing EAP. (0) [eap] = noop (0) sql : expand: %{Stripped-User-Name} -> (0) sql : sql_set_user escaped user --> '' There at the end, what's ending up in the sql module just does NOT have Stripped-User-Name set, and that's driving me batty. The only way I've ever had that working was to manually, in unlang, set it to a fixed string (Stripped-User-Name := dawson). Any ideas what's causing this difficulty? -Jacob On 14 Jul 2011, at 08:49, Jacob Dawson wrote:
On 14 Jul 2011, at 03:42, Alexander Clouter wrote:
In article <795D5EE4-7536-431E-926A-98E70EFA1771@vt.edu> you wrote: Although to prevent down the road severe levels of pain when enabling eduroam you should be using something like 'dawson@hokies.vt.edu', could you not just use 'ntdomain' (a built in module that will do this for you)? 'ntdomain' should create Realm and Stripped-User-Name in the manner you want. Are you suggesting that using a prefix domain like that will cause problems, or that I should be using the realms module? I have no problem with using the module, as it's worked well for the proxying side of things, but I need to be able to authorize the users on our domain, and that means I need to get a stripped username and pass it to the DB. I'll poke at it and see if I can get that side working.
I was going to ask why you were not doing the perl stuff in unlang. :)
It seemed like a good idea at the time.
(1) ? elsif ("%{User-Name}" =~ /^(.*\\)(.*)$/) (1) expand: %{User-Name} -> hokies\dawson ERROR: Failed compiling regular expression: Unmatched ( or \( (1) - if ("%{User-Name}" !~ /^.*\/.*$/) returns updated
where the relevant part of sites-enabled/default authorize section looks thus:
elsif("%{User-Name}" =~ /^(.*\\)(.*)$/){ update request{ Stripped-User-Name := "%{$`}" } }
$' and $` is a perlism. You want something like (look at policy.conf rewrite.calling_station_id and rewrite.called_station_id as an example): ---- if (User-Name =~ /^[^\\]\\?(.*)$/) { update request { Stripped-User-Name := "%{1}" } } ----
Untested, but hopefully you get the idea. :) This works a little better: elsif("%{User-Name}" =~ /^(.*)\\\\?(.*)$/){ update request{ Stripped-User-Name := "%{2}" } }
But gives this: (5) ? Evaluating ("%{User-Name}" =~ /^(.*)\\\\?(.*)$/) -> TRUE (5) ? elsif ("%{User-Name}" =~ /^(.*)\\\\?(.*)$/) -> TRUE (5) elsif ("%{User-Name}" =~ /^(.*)\\\\?(.*)$/) { (5) - entering elsif ("%{User-Name}" =~ /^(.*)\\\\?(.*)$/) {...} (5) update request { (5) expand: %{2} -> (5) } # update request = updated (5) - elsif ("%{User-Name}" =~ /^(.*)\\\\?(.*)$/) returns updated (5) - if ("%{User-Name}" !~ /^.*\/.*$/) returns updated .... (5) sql : expand: %{Stripped-User-Name} -> (5) sql : sql_set_user escaped user --> ''
Not sure what I should be doing there. Changed it to %{0} and also to %{1} and both gave me hokies\dawson, which was at least successfully written into Stripped-User-Name.
Would love some more insight into how unlang handles these things, as I'm sure we'll run into a use for it in the future, even if I manage a realms-based solution to this.
Thanks much, - Jacob
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Further testing suggests that neither of the Perl or Realm modules is applying the Stripped-User-Name in the right scope. Perl does that first thing, when a request comes in, and my output says that as soon as perl is done, it's unset. Similarly, as soon as the hokies realm module is done applying a stripped username, it's unset when it returns, as evidenced by the new output below: (0) HOKIES : Looking up realm "hokies" for User-Name = "hokies\dawson" (0) HOKIES : Found realm "~HOKIES" (0) HOKIES : Adding Stripped-User-Name = "dawson" (0) HOKIES : Adding Realm = "hokies" (0) HOKIES : Proxying request from user dawson to realm ~HOKIES (0) HOKIES : Preparing to proxy authentication request to realm "~HOKIES" (0) [HOKIES] = updated (0) guest : Request already proxied. Ignoring. (0) [guest] = ok (0) ? if ("%{User-Name}" =~ /.*/) (0) expand: %{User-Name} -> hokies\dawson (0) ? Evaluating ("%{User-Name}" =~ /.*/) -> TRUE (0) ? if ("%{User-Name}" =~ /.*/) -> TRUE (0) if ("%{User-Name}" =~ /.*/) { (0) - entering if ("%{User-Name}" =~ /.*/) {...} (0) - if ("%{User-Name}" =~ /.*/) = notfound (0) - if ("%{User-Name}" !~ /^.*\/.*$/) returns notfound (0) ? if ("%{Stripped-User-Name}" =~ /.*/) (0) expand: %{Stripped-User-Name} -> (0) ? Evaluating ("%{Stripped-User-Name}" =~ /.*/) -> TRUE (0) ? if ("%{Stripped-User-Name}" =~ /.*/) -> TRUE (0) if ("%{Stripped-User-Name}" =~ /.*/) { (0) - entering if ("%{Stripped-User-Name}" =~ /.*/) {...} (0) - if ("%{Stripped-User-Name}" =~ /.*/) = notfound (0) - if ("%{User-Name}" !~ /^.*\/.*$/) returns notfound (0) - if ("%{User-Name}" !~ /^.*\/.*$/) returns updated Am I missing something, and just have something blindingly obvious misconfigured, or is it misbehaving? The only way I've successfully written the Stripped-User-Name attribute onto the Access-Request has been in unlang itself with a static string, as I was unable to get the regexp parsing to play nice. -Jacob On 14 Jul 2011, at 13:31, Jacob Dawson wrote:
So I played with my copy of the code to change what nostrip being unset means (now, it writes the Stripped-User-Name attribute, but no longer rewrites the User-Name attribute with the stripped username), and I'm still running into problems: (0) HOKIES : Looking up realm "hokies" for User-Name = "hokies\dawson" (0) HOKIES : Found realm "~HOKIES" (0) HOKIES : Adding Stripped-User-Name = "dawson" (0) HOKIES : Adding Realm = "hokies" (0) HOKIES : Proxying request from user dawson to realm ~HOKIES (0) HOKIES : Preparing to proxy authentication request to realm "~HOKIES" (0) [HOKIES] = updated (0) guest : Request already proxied. Ignoring. (0) [guest] = ok (0) - if ("%{User-Name}" !~ /^.*\/.*$/) returns updated (0) ... skipping elsif for request 0: Preceding "if" was taken (0) eap : Request is supposed to be proxied to Realm ~HOKIES. Not doing EAP. (0) [eap] = noop (0) sql : expand: %{Stripped-User-Name} -> (0) sql : sql_set_user escaped user --> ''
There at the end, what's ending up in the sql module just does NOT have Stripped-User-Name set, and that's driving me batty. The only way I've ever had that working was to manually, in unlang, set it to a fixed string (Stripped-User-Name := dawson).
Any ideas what's causing this difficulty?
-Jacob
On 14 Jul 2011, at 08:49, Jacob Dawson wrote:
On 14 Jul 2011, at 03:42, Alexander Clouter wrote:
In article <795D5EE4-7536-431E-926A-98E70EFA1771@vt.edu> you wrote: Although to prevent down the road severe levels of pain when enabling eduroam you should be using something like 'dawson@hokies.vt.edu', could you not just use 'ntdomain' (a built in module that will do this for you)? 'ntdomain' should create Realm and Stripped-User-Name in the manner you want. Are you suggesting that using a prefix domain like that will cause problems, or that I should be using the realms module? I have no problem with using the module, as it's worked well for the proxying side of things, but I need to be able to authorize the users on our domain, and that means I need to get a stripped username and pass it to the DB. I'll poke at it and see if I can get that side working.
I was going to ask why you were not doing the perl stuff in unlang. :)
It seemed like a good idea at the time.
(1) ? elsif ("%{User-Name}" =~ /^(.*\\)(.*)$/) (1) expand: %{User-Name} -> hokies\dawson ERROR: Failed compiling regular expression: Unmatched ( or \( (1) - if ("%{User-Name}" !~ /^.*\/.*$/) returns updated
where the relevant part of sites-enabled/default authorize section looks thus:
elsif("%{User-Name}" =~ /^(.*\\)(.*)$/){ update request{ Stripped-User-Name := "%{$`}" } }
$' and $` is a perlism. You want something like (look at policy.conf rewrite.calling_station_id and rewrite.called_station_id as an example): ---- if (User-Name =~ /^[^\\]\\?(.*)$/) { update request { Stripped-User-Name := "%{1}" } } ----
Untested, but hopefully you get the idea. :) This works a little better: elsif("%{User-Name}" =~ /^(.*)\\\\?(.*)$/){ update request{ Stripped-User-Name := "%{2}" } }
But gives this: (5) ? Evaluating ("%{User-Name}" =~ /^(.*)\\\\?(.*)$/) -> TRUE (5) ? elsif ("%{User-Name}" =~ /^(.*)\\\\?(.*)$/) -> TRUE (5) elsif ("%{User-Name}" =~ /^(.*)\\\\?(.*)$/) { (5) - entering elsif ("%{User-Name}" =~ /^(.*)\\\\?(.*)$/) {...} (5) update request { (5) expand: %{2} -> (5) } # update request = updated (5) - elsif ("%{User-Name}" =~ /^(.*)\\\\?(.*)$/) returns updated (5) - if ("%{User-Name}" !~ /^.*\/.*$/) returns updated .... (5) sql : expand: %{Stripped-User-Name} -> (5) sql : sql_set_user escaped user --> ''
Not sure what I should be doing there. Changed it to %{0} and also to %{1} and both gave me hokies\dawson, which was at least successfully written into Stripped-User-Name.
Would love some more insight into how unlang handles these things, as I'm sure we'll run into a use for it in the future, even if I manage a realms-based solution to this.
Thanks much, - Jacob
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
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. Alan DeKok.
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
Jacob Dawson <dawson@vt.edu> wrote:
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. I am 90% sure that's not what rlm_realm does. We use unlang to process realms now, but I am certain we used it with nostrip and it left the original User-Name intact and populated Stripped-User-Name. -- Sent from my phone. Please excuse brevity and typos.
Phil Mayers <p.mayers@imperial.ac.uk> wrote:
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.
I am 90% sure that's not what rlm_realm does. We use unlang to process realms now, but I am certain we used it with nostrip and it left the original User-Name intact and populated Stripped-User-Name.
You are right, we use rlm_realm and it leaves User-Name unadulterated. This sounds like maybe the *inner* auth User-Name is realmless and making it's way out into outer.reply. When you use 'User-Name' in post-auth{} you will get reply:User-Name rather than request:User-Name if I remember correctly. The fix is to *reject* inner-authentications that are realm-less. Cheers -- Alexander Clouter .sigmonster says: You are the only person to ever get this message.
participants (4)
-
Alan DeKok -
Alexander Clouter -
Jacob Dawson -
Phil Mayers