Good morning, Thanks to everyone for their interesting suggestions.
The one that I found the most intuitive was to define some logical groups for our NAS's in huntgroups and then reference those in the users file. Something is missing though as IDLE-TIMEOUT is not being handed out as I would expect it to be (as per the setting in the huntgroups files). Perhaps somebody can help us get across the finish line here. So in huntgroups I have: ### RADIUS HUNTGROUP TEST - jg ### MSP7345 NAS-IP-Address =~ /^10\.99\.3\./ SNJ7000 NAS-IP-Address =~ /^10\.3\.99\./ LAB7000 NAS-IP-Address =~ /^192\.168\.0./ ----------------- Then in the users file right at the top I added: ### Testing FreeRADIUS IDLE-TIMEOUT Tweak -jg ### DEFAULT Huntgroup-Name == SNJ7000 Idle-Timeout := 1, Fall-Through := yes DEFAULT Huntgroup-Name == MSP7345 Idle-Timeout := 1800, Fall-Through := yes DEFAULT Huntgroup-Name == LAB7000 Idle-Timeout := 1, Fall-Through := yes -------------- I wasn't timing out so I then stopped radiusd and kicked it into debug mode with a radiusd -X STDOUT shows that I am being handed the IDLE-TIMEOUT of 1800 even though I am coming from the LAB Node with IP of 192.168.0.15 The user (me) does have an IDLE-TIMEOUT set in my user section of 1800 but I thought the above lines would set it and because the IDLE-TIMEOUT in my user section is using the = operator. Here is my User Section: XXXX Cleartext-Password := "XXXXXXX" Idle-Timeout = 1800, Tellabs-UAP-CLI := "A8", Callback-Id := "Admin", Reply-Message += "superuser", Reply-Message += "Administrator" ---------------- Here are the debug logs. If anybody has any insights I sure would appreciate it! Thanks, Jg <SNIP> Listening on authentication address 127.0.0.1 port 18120 as server inner-tunnel Listening on proxy address * port 1814 Ready to process requests. rad_recv: Access-Request packet from host 192.168.0.15 port 65496, id=182, length=80 User-Name = "XXXX" User-Password = "XXXX" Service-Type = Login-User NAS-Identifier = "dot5" Called-Station-Id = "BTI:7000" NAS-Port = 0 NAS-IP-Address = 192.168.0.15 # Executing section authorize from file /usr/local/etc/raddb/sites-enabled/default +- entering group authorize {...} [preprocess] expand: %{NAS-IP-Address} -> 192.168.0.15 [preprocess] expand: %{NAS-IP-Address} -> 192.168.0.15 <--------------- Does this mean that the huntgroups file is being checked? Perhaps a regex thing? [preprocess] expand: %{NAS-IP-Address} -> 192.168.0.15 ++[preprocess] returns ok ++[chap] returns noop ++[mschap] returns noop ++[digest] returns noop [suffix] No '@' in User-Name = "xxxxx", looking up realm NULL [suffix] No such realm "NULL" ++[suffix] returns noop [eap] No EAP-Message, not doing EAP ++[eap] returns noop [files] users: Matched entry xxxx at line 23 ++[files] returns ok ++[expiration] returns noop ++[logintime] returns noop ++[pap] returns updated Found Auth-Type = PAP # Executing group from file /usr/local/etc/raddb/sites-enabled/default +- entering group PAP {...} [pap] login attempt with password "xxxx" [pap] Using clear text password "xxxx" [pap] User authenticated successfully ++[pap] returns ok Login OK: [xxxxxx] (from client Seattle port 0) # Executing section post-auth from file /usr/local/etc/raddb/sites-enabled/default +- entering group post-auth {...} ++[exec] returns noop Sending Access-Accept of id 182 to 192.168.0.15 port 65496 Idle-Timeout = 1800 Tellabs-UAP-CLI := "A8" Callback-Id := "Admin" Reply-Message += "superuser" Reply-Message += "Administrator" Finished request 0. Going to the next request Waking up in 4.9 seconds. Cleaning up request 0 ID 182 with timestamp +41 Ready to process requests. </SNIP> -----Original Message----- From: freeradius-users-bounces+john.giordano=ttmi...@lists.freeradius.org [mailto:freeradius-users-bounces+john.giordano=ttmi...@lists.freeradius.org] On Behalf Of Matthew Newton Sent: Tuesday, April 16, 2013 1:47 PM To: FreeRadius users mailing list Subject: Re: Setting different IDLE-TIMEOUTS based on IP Address Hi, On Tue, Apr 16, 2013 at 02:05:45PM -0500, John Giordano wrote: > So I man’ed unlang and then did some more reading on huntgroups and > the users file. If at all possible I think we would opt for a combo > of the huntgroups/users file approach. I am still not clear as to how > we would do this though…. > > Could you please speak to the interrelationship between the clients > file and the huntgroups file? The clients file lists clients (NASes) that can talk the the server. The huntgroups file (read by the preprocess module, not the files module as in the comments at the top of the file) is used to match incoming request attributes to set the Huntgroup-Name attribute, which can be further used to set other attributes in the reply (for example, in the users file, or by using unlang). The users file (read by the files module) can match on request attributes to set reply attributes. The standard lookup is for User-Name; this can be changed, or a DEFAULT entry can be used to match anything else. > My first question is that every huntgroups file example I have seen on the > Net uses a per NAS definition: > > raleigh NAS-IP-Address == 192.168.1.101 > raleigh NAS-IP-Address == 192.168.1.102 > raleigh NAS-IP-Address == 192.168.1.103 > premium NAS-IP-Address == 192.168.1.101, NAS-Port-Id == 0-4 > Group = premium, > Group = staff > > I would rather not have to define 254 different entries in our > huntgroups file (254 hosts in a Class C obviously). Can I use a > netmask somehow in the huntgroups file? It's a check list, so you should be able to use any standard check operator - so try regex, for example: huntgroups: foo NAS-IP-Address =~ /^10\.2\.3\./ bar NAS-IP-Address =~ /^10\.4\.9\./ users: (add these at the *top* of the file) DEFAULT Huntgroup-Name == foo Idle-Timeout := 600 Fall-Through := yes DEFAULT Huntgroup-Name == bar Idle-Timeout := 1200 Fall-Through := yes > In pseudo parlance this is what I am trying to accomplish in huntgroups: > > MSP 7345’s NAS-IP-Address == 10.99.3.0/24 > IDLE-TIMEOUT = 1800 > > SNJ 7000 NAS-IP-Address == 10.3.99.0/24 > IDLE-TIMEOUT = 60 Note that Client-IP-Address is sometimes better than NAS-IP-Address (it can't be spoofed, which may be the case if you process proxied requests from RADIUS servers out of your own control), but Client-IP-Address can *not* be used in the huntgroups file as it only looks at the incoming request attributes, of which Client-IP-Address is not. If this is a concern there are ways of getting around it. One is to use unlang instead of the huntgroups file, as Alan suggested. Note the above splits the config over two locations. If you want to keep it all in one place, use unlang like Alan said. If it doesn't look tidy, put it in the policy.conf file and then call the policy name instead. Matthew -- Matthew Newton, Ph.D. <m...@le.ac.uk> Systems Specialist, Infrastructure Services, I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom For IT help contact helpdesk extn. 2253, <ith...@le.ac.uk> - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html