Hoping someone can give me some hints/ideas. We have 2 modem pools available to our users, the availability of which is controlled by the user's unix group and the Radius Client IP. We also offer dialup accelleration which is available to members of either modem pool, and is also controlled by a Unix group membership. The accelleration is provided by the providers of the "poola" services, and thus the authentication requests for acceleration come from the "poola" radius servers. This is currently set up in our users file thusly... DEFAULT Group == "slipstream" Slipstream-Auth = "true", Fall-Through = 1 <...> DEFAULT Client-IP-Address == 65.167.179.3, Group != "poola", Auth-Type :=Reject Reply-Message = "Your account is not authorized for this modem pool." DEFAULT Client-IP-Address == 65.167.179.4, Group != "poola", Auth-Type :=Reject Reply-Message = "Your account is not authorized for this modem pool." <... more poola ...> DEFAULT Client-IP-Address == 207.102.99.65, Group != "poolb", Auth-Type :=Reject Reply-Message = "Your account is not authorized for this modem pool." DEFAULT Client-IP-Address == 207.102.99.81, Group != "poolb", Auth-Type :=Reject Reply-Message = "Your account is not authorized for this modem pool." <... more poolb ...> <whole bunch more group checks w/ fallthroughs, usage checks, session timeout & parameter setting, etc> <...> This is working just fine for users of "poola" either with or without accelleration. Dialup requests are working just fine for "poolb" users, but they are being rejected accelleration because the accelleration request is coming from the "poola" radius server, and they do not have "poola" membership. A temporary workaround has been made by simply adding them to the "poola" group as well. At that point they are able to dial in to a "poolb" number and still have accelleration, however they could also dial in to "poola" if they were so inclined, and this would cause them/us other issues. I have spoken to the provider and they have provided me with the NAS-IP's of the accelleration servers so I should be able to use the NAS-IP-Address attribute to identify when the radius requests coming from the "poola" radius server is a dialup request or an authentication request. I can't quite figure out the best way to integrate this into the users file though. So the first part I presume ends up looking like DEFAULT NAS-IP-Address == 64.136.173.17, Group == "slipstream" Slipstream-Auth = "true", Fall-Through = 1 DEFAULT NAS-IP-Address == 64.136.164.67, Group == "slipstream" Slipstream-Auth = "true", Fall-Through = 1 <...> But beyond that, how can I then skip over the 20 or so poola/poolb checks which do not apply for accelleration requests? Maybe there's a cleaner way of doing this? There is the possibility that down the road our provider will be radius-authenticating our clients for permission to use their NNTP server, so this will nessesitate a 3rd branch of processing. So I'd like to kind of be prepared for that when it happens. So essentially what I need to do is an initial determination of whether the request is dialup, accelleration, or NNTP (well basically if it's accelleration or nntp, with dialup being the default path if it's neither of the former). Go down a particular branch of processing depending on which of the three flavors of request it is, and then drop back out of those checks into a common branch where I'm checking for such things as their account being over limits, time of day checks, expired account checks, etc, etc processing through to the end of the file. Any hints, tips, suggestions, and brainstorms are greatly appreciated. Thanks,
Mike <<<<<
P.S. Is there a syntax by which I can specify something like... DEFAULT Client-IP-Address == (207.102.99.65 or 207.102.99.66 or 207.102.99.67), Group != "poolb", Auth-Type :=Reject or somehow pre-define a group of NAS' to use in place such as... clientpoola = 207.102.99.65, 207.102.99.66, 207.102.99.67 DEFAULT Client-IP-Address == clientpoola, Group != "poolb", Auth-Type :=Reject rather than specifiying a separate stanza for each Client-IP-Address as I have in my existing config?
"Mike Cisar" <mlists@starmania.net> wrote:
But beyond that, how can I then skip over the 20 or so poola/poolb checks which do not apply for accelleration requests? Maybe there's a cleaner way of doing this?
The "users" file isn't really mean for complex processing like that. You're running into it's limitations, which are pretty severe.
So essentially what I need to do is an initial determination of whether the request is dialup, accelleration, or NNTP (well basically if it's accelleration or nntp, with dialup being the default path if it's neither of the former).
My suggestion is to use rlm_passwd. Define server-side attributes like "Where-From" with values like "dialup", "acceleration", and "nntp". Use rlm_passwd to match the client IP's to Where-From.
Go down a particular branch of processing depending on which of the three flavors of request it is, and then drop back out of those checks into a common branch
The "users" file can do that.
P.S. Is there a syntax by which I can specify something like...
DEFAULT Client-IP-Address == (207.102.99.65 or 207.102.99.66 or 207.102.99.67), Group != "poolb", Auth-Type :=Reject
Nope.
or somehow pre-define a group of NAS' to use in place such as...
clientpoola = 207.102.99.65, 207.102.99.66, 207.102.99.67 DEFAULT Client-IP-Address == clientpoola, Group != "poolb", Auth-Type :=Reject
rather than specifiying a separate stanza for each Client-IP-Address as I have in my existing config?
rlm_passwd. Map the client IP's to a common "where-from", and key off of that in the "users" file. Alan DeKok.
participants (2)
-
Alan DeKok -
Mike Cisar