RE: configuration for realm with prefix and suffix
well... so what we get is in the form prefix/[EMAIL PROTECTED]
I'm having trouble wrapping my head around how to configure our server
to
with these.
You'll need to use the hints file. The realm module won't run twice.
e.g. one way to strip the prefix/ and drop it would be:
DEFAULT User-Name =~ .*/([EMAIL PROTECTED])
User-Name := %{1}
Thanks Phil, I'll give that a try and see if it does the trick.
Cheers,
Mike
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
configuration for realm with prefix and suffix
Running FreeRADIUS 1.1.3, usernames are in 'username' format in a unix passwd file. Our dialup users are proxied to us in '[EMAIL PROTECTED]' format and to this point everything has been working just fine. Now the tougher part... We've gained access to some additional POPs and although the suffix is the same, we are proxied these with a prefix as well... so what we get is in the form prefix/[EMAIL PROTECTED] I'm having trouble wrapping my head around how to configure our server to deal with these. Any thoughts or pointers are appreciated. Cheers, Mike - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Configuration of users file
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? - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Accounting replies missing
I have been trying to troubleshoot a RADIUS issue with my upstream provider. We've recently started seeing places in our accounting logs where we are receiving 5 start and 5 stop packets for each caller. They have told us... ... This proves, at least now, we are not receiving multiple accounting packets from the NAS. We checked our radius logs for any clues, and saw that we have multiple missedaccounting to your server. This happens when we never receive a response from your radius when sending multiple instances of an accounting record. It seems that you do not reply to incoming accounting data. By doing this, it should resolve the issue. Since my configuration has not changed, and the problem has been on and off during the course of the past week or two... I am assuming that I am indeed sending responses to accounting packets, but they are getting lost in transit since if I weren't sending at all, then the problem should be consistant all of the time rather than just having popped up. Could their be any other cause of them not seeing a response? Any suggestions/hints/tips on troubleshooting are appreciated as always. Cheers, Mike - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: Anyone using radzap?
The latest CVS snapshot should contain fixed radwho radzap. They should work if you copy them to a 1.0.2 distribution, and re-build. Thanks Alan, I'll grab them and give it a try. Cheers, Mike - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: Anyone using radzap?
Hi Alan, So far as I can tell, radzap hasn't worked for a while. If so, I'll poke it, and see if I can't get it to work. This may, however, involve changing the command-line options... Can't say as I've been using it, for the obvious reasons... but I've wanted to several times in the past couple months :-) Cheers, Mike - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
counter by group
Just wondering if there's a way to set up a counter based on a user's (unix) group rather than their username? Essentially I have a user currently under the control of a counter based on which I limit him to 100 hours of connect time during the month. There are times when the user might be connected simultaneously from two locations, previously this has not been a problem... however due to provider changes, our new provider enforces a single (soft) concurrent login, and based on automated policies can end up locking the user out for 8 hours if they connect concurrently too many times. Unfortunately we can't exempt the user from that concurrency nor lockout policy. The solution to the first problem is easy, 2 separate logins. However it gets complicated in that the total time limit must be only 100 hours per month (long story... a solution for a good customer in a bad divorce with his kids stuck in the middle, go figure :-). I can't do two 50 hour accounts, because we might run out of time on one or the other before the total reaches 100. Sooo, long story short... if I could set up a group based counter, assign the two users to that group, and configure that group for a maximum of 100 hours per month. Each user could dial in as much as required up to the cumulative total hours configured. Can this be done? Cheers, Mike - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: MTU Settings
Hi Kirti, I experienced a similar problem a month or so ago, and talked to 4 or 5 people at the time who had all just fixed the problem. It seems that the default users file shipped with FreeRADIUS includes a Framed-MTU=576 setting in one of the default sections. Simply removing that line was enough to get me up and running (I suppose I could have set it to 1514 or whatever, but not explicitly setting it seems to let it float with what the NAS is happy with anyway). Note to Alan... just a thought but given that MTU can be such a tricky problem to track down... might it be better to ship FreeRADIUS without a forced MTU setting in the sample config file... or at least have it commented out instead of active by default? Cheers, Mike -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kirti S. Bajwa Messenger, www.riteaid.net, and many many other web sites. One the 3COM user site, I am told that MTU setting should be 1514 both on 3COM freeRADIUS. I am a newbie to freeRADIUS so I need help. Please help with following: (1) How do I change the MTU settings in freeRADIUS to 1514? - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Freeradius w/ Cisco AP
Hi All, Just wondering if anyone has had any experience with or has a link to a good FAQ on setting up a Cisco (AP352) access point with Freeradius (doing other than MAC authentication, ie. EAP)? I've been playing and googling around a bit also but have not been able to accomplish anything concrete except a pure MAC authentication against Freeradius (which works just great). My knowledge of EAP is about -1 which is hindering my progress significantly. And as would naturally be the case when I try enabling EAP I get rlm_eap: UserIdentity Unknown errors, to which I have found a couple of mentions on the list in the past but no solutions. The eap.conf file recommends against using against EAP-MD5 for wireless connections, what would be preferred instead that would be compatible with the Cisco (Windows XP clients I would assume primarily, but if someone walks in with a mac or some sort of PDA I'd be real happy to have it just work also). Specifically against the Cisco AP is the question of what is the difference between Open authentication, with EAP and Network EAP, and which should I be using here? The AP is in a shared-office environment and what we'd like to accomplish is essentially providing wireless Internet connectivity to the other tenants. Prior to this point we have been using just a cheap (and flakey) old linksys router, but since it is on death's door, and since we use radius for our dialup user authentication it made sense to pick up a true access point and to integrate our wireless clients into the radius as well. Because of skill levels of these users (they are used to username/password and not much more) I would prefer any approach that is zero/minimal configuration on the client side... poke the mouse at the wireless connection is available dialog when it pops up is just perfect :-) If we can get this working smoothly then the next plan is to hotspot to those people who are visiting in the building, and just coincidentally GRIN our wireless coverage is great at the restaurant across the street... obviously zero-config is even more important in those hotspot scenarios. As usual thanks in advance for any hints, tips and pointers. Cheers, Mike - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: Custom attributes in dictionary...
DEFAULT Group == slipstream Slipstream-Auth = true, Fall-Through = 1 You have to define what true is. Or, just do Slipstream-Auth = 1 Thanks Alan, seems to be sending the attributes as I expect, have to wait for them to get the service turned on for me at the back end to check 100%. Since they've defined the attribute to be a string I have to figure out whether 1/0 (ie. binary true/false) is what they are looking for or if they want an actual true/false (ie. a string)... but that will be easy enough to determine once they get the service turned up for me. Cheers, Mike - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Custom attributes in dictionary...
This one is a bit above my head, trying to set up accelleration and our vendor has advised that I need to do the following... your radius must be setup with the custom authentication reply. Defining this attribute in your dictionary may vary depending on your radius software. The attribute is: VENDORATTR 7000 Slipstream-Auth 1 string The value must be set as true How would I set that up in Freeradius... would I create a dictionary.slipstream containing the following??? VENDOR slipstream7000 BEGIN-VENDOR slipstream ATTRIBUTESlipstream-Auth 1 string END-VENDOR slipstream then add a Slipstream-Auth = false in the main default section of users so it is off by default, and then turn it on thusly in the users file for the users in the slipstream group? DEFAULT Group == slipstream Slipstream-Auth = true, Fall-Through = 1 Thanks much for any pointers! Cheers, Mike - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Exec-Program
Another simple one (hopefully)... this server is running on FreeRadius 0.9.0 (new server coming in 3 weeks will have newest version of FreeRadius, for now this version is what I have to work with). To summarize what I am trying to accomplish... - When an accounting start packet is received I need to pass that username and user's IP address to the startscript - When an accounting stop packet is received I need to pass that username and user's IP address to the stopscript With the goal of allowing the IP address (and user) access to certain resources only when they are logged in (so I will have to pass that info to the script eventually... baby steps... get freeradius to call the scripts first, then worry about perfecting them :-) ... for testing purposes, based on some vague examples I found whilst Googling, I have tried the following in the users file (below my outright deny access lines but above everything else of substance in the file). Users are able to log on and off as normal, but the scripts don't seem to trigger (running with -xx I get no errors, nor any reference to either script mentioned). DEFAULT Acct-Status-Type == Start Exec-Program = /usr/local/bin/stopscript DEFAULT Acct-Status-Type == Stop Exec-Program = /usr/local/bin/startscript The scripts are both owner/group to the radius user, have read/execute permissions, and otherwise work when executed manually when su'd to the radius user. Is there something that needs to be configured in radiusd.conf in addition for this to work, perhaps some compile-time option? I get the impression that the above method may have been superceded by doing such things via exec stanzas in radiusd.conf, but I wasn't able to Google up any examples of that particular scenario that were a close enough fit to what I am trying to do. Any examples, pointers to docs, hints or other means to that end, in whatever manner is currently accepted as being preferred are appreciated. Thanks, Mike - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: Exec-Program
Try putting those exact 2 lines in acct_users file instead. That should make them work as intended. =) ooo you mean that little config file there hidden right at the start of the ls DOH!!! :-) Thanks to both you and Thor for that solution. The scripts seem to be triggering ok now, but am getting the following in radius.log... appears to be once for each time the script gets called... Tue Dec 28 16:14:12 2004 : Error: Thread 2 failed waiting for semaphore: Interrupted system call: Exiting However, I've found an old message in the archives from Thor which I believe addresses that particular issue. Cheers, Mike -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Nate M Sent: Tuesday, December 28, 2004 2:20 PM To: freeradius-users@lists.freeradius.org Subject: RE: Exec-Program Importance: Low - Nathan Miller -Original Message- From: [EMAIL PROTECTED] [mailto:freeradius- [EMAIL PROTECTED] On Behalf Of Mike Cisar Sent: Tuesday, December 28, 2004 12:49 PM To: freeradius-users@lists.freeradius.org Subject: Exec-Program Another simple one (hopefully)... this server is running on FreeRadius 0.9.0 (new server coming in 3 weeks will have newest version of FreeRadius, for now this version is what I have to work with). To summarize what I am trying to accomplish... - When an accounting start packet is received I need to pass that username and user's IP address to the startscript - When an accounting stop packet is received I need to pass that username and user's IP address to the stopscript With the goal of allowing the IP address (and user) access to certain resources only when they are logged in (so I will have to pass that info to the script eventually... baby steps... get freeradius to call the scripts first, then worry about perfecting them :-) ... for testing purposes, based on some vague examples I found whilst Googling, I have tried the following in the users file (below my outright deny access lines but above everything else of substance in the file). Users are able to log on and off as normal, but the scripts don't seem to trigger (running with -xx I get no errors, nor any reference to either script mentioned). DEFAULT Acct-Status-Type == Start Exec-Program = /usr/local/bin/stopscript DEFAULT Acct-Status-Type == Stop Exec-Program = /usr/local/bin/startscript The scripts are both owner/group to the radius user, have read/execute permissions, and otherwise work when executed manually when su'd to the radius user. Is there something that needs to be configured in radiusd.conf in addition for this to work, perhaps some compile-time option? I get the impression that the above method may have been superceded by doing such things via exec stanzas in radiusd.conf, but I wasn't able to Google up any examples of that particular scenario that were a close enough fit to what I am trying to do. Any examples, pointers to docs, hints or other means to that end, in whatever manner is currently accepted as being preferred are appreciated. Thanks, Mike - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: Using groups to configure access based on particular requesting radius server.
Thanks Alan Denying from a group I can do... but how to deny from a group conditionally on which radius server the request is coming from is what I can't quite figure. DEFAULT Group == poola, Client-IP-Address == ip.of.pool.a., Auth-Type := Reject I was sure it'd be something simple like that :-) If I'm understanding the syntax (if group and client-ip match, then reject)... shouldn't it be ip.of.pool.b in the example above... since I want to deny poola users from accessing if they dial in on a poolb number and vice versa? So the users file would get a stanza like below... DEFAULT Group == poola, Client-IP-Address == ip1.of.pool.b., Auth-Type := Reject DEFAULT Group == poola, Client-IP-Address == ip2.of.pool.b., Auth-Type := Reject DEFAULT Group == poolb, Client-IP-Address == ip1.of.pool.a., Auth-Type := Reject DEFAULT Group == poolb, Client-IP-Address == ip2.of.pool.a., Auth-Type := Reject DEFAULT Group == poolb, Client-IP-Address == ip3.of.pool.a., Auth-Type := Reject Likewise is != valid here? Such that the following would be a valid representation... DEFAULT Client-IP-Address == ip1.of.pool.a., Group != poola, Auth-Type := Reject DEFAULT Client-IP-Address == ip2.of.pool.a., Group != poola, Auth-Type := Reject DEFAULT Client-IP-Address == ip1.of.pool.b., Group != poolb, Auth-Type := Reject DEFAULT Client-IP-Address == ip2.of.pool.b., Group != poolb, Auth-Type := Reject DEFAULT Client-IP-Address == ip3.of.pool.b., Group != poolb, Auth-Type := Reject With only two pools I suppose it wouldn't really make much difference, but if a 3rd or more were added the latter would result in fewer configuration lines required, correct? Thanks again! Cheers, Mike - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Using groups to configure access based on particular requesting radius server.
I'm hoping someone may be able to give me some pointers or thoughts. I have a scenario where we have two separate external organizations who provide service to our dialup customers. Each of these companies has their own RADIUS servers which accept the request from whichever of the 1000's of NAS' is handling the customer and they proxy the request to our RADIUS server for authentication. One of these providers provides coverage in additional regions not covered by the other, but it's an additional cost to us when our customer uses it. My problem/question is this... is it possible to set up somehow so that I can create a couple of Unix groups (call them poola and poolb) and then control whether the login is denied partially on the RADIUS server that is asking. So if I set all users to have a membership in poola by default, and then only added users to the poolb group if they've paid the upcharge on their account... if an authentication request came from the poolb provider's RADIUS server but the user were not a member of the poolb group, the request would be denied. This may be insanely simple, but I've been staring at the problem for a couple of days and it's not sinking in (maybe I need more... or less eggnog). Denying from a group I can do... but how to deny from a group conditionally on which radius server the request is coming from is what I can't quite figure. Any tips, hints, pointers or workarounds gratefully accepted. Seasons greetings to all! Cheers, Mike - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Radwho questions
I have a couple of radwho questions... First, I seem to remember seeing a patch somewhere for radwho that expanded the width of the from field but now that I want it, can't find it anywhere :-) Anybody have it floating around? And second, regarding the name field... my system is configured using the passwd, shadow and group parameters in radiusd.conf to use files other than the system password files... is there any way to get radwho to use those same files to populate the name field in the radwho output instead of the default? Cheers, Mike - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
