Can 3Com NETServers be configured to use the Radius Filter-Id attribute? Any experiences good or bad with this? -- Scott Bailey Systems Administrator Epix Internet Services scott@epix.net 570-631-1317 - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.
Yes they work this this. On Fri, 3 Mar 2000, Scott Bailey wrote:
Can 3Com NETServers be configured to use the Radius Filter-Id attribute?
Any experiences good or bad with this?
-- Scott Bailey Systems Administrator Epix Internet Services scott@epix.net 570-631-1317
- To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.
----------------------------------------------------- Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881) - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.
Anyone have an experience in carrying Login information to a Website? Example: Bob logs in he gets an IP address of 202.101.0.5 this is then carried with him in some sort of cookie (or other method) then it is passed onto a website thus allowing him entry. So Bob gets in and others cannot. Also is it possible to pull out the login information such as Username? Can this be done via a filter and proxy? Thanks everyone! -- Ed ----- Original Message ----- From: "Brian" <signal@shreve.net> To: "Total Control List" <usr-tc@lists.xmission.com> Sent: Friday, March 03, 2000 10:40 AM Subject: Re: (usr-tc) Filter-Id Yes they work this this. On Fri, 3 Mar 2000, Scott Bailey wrote:
Can 3Com NETServers be configured to use the Radius Filter-Id attribute?
Any experiences good or bad with this?
-- Scott Bailey Systems Administrator Epix Internet Services scott@epix.net 570-631-1317
- To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.
----------------------------------------------------- Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881) - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message. - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.
Thus spake Ed
Anyone have an experience in carrying Login information to a Website?
Example: Bob logs in he gets an IP address of 202.101.0.5 this is then carried with him in some sort of cookie (or other method) then it is passed onto a website thus allowing him entry.
So Bob gets in and others cannot. Also is it possible to pull out the login information such as Username?
Can this be done via a filter and proxy?
Thanks everyone!
We do this by parsing our RADIUS accounting log files (ugly, I know...I'm trying to come up with a better way of doing it), and then allow on the web server based on the information that was parsed out of the log files. I don't suspect that there is any reason that this same type of setup couldn't be extended to include a proxy server. Should be able to build filters to accomplish about the same thing...though the filters have to be on the NETServer/Arc before the user logs in. RADIUS can only tell the NETServer/Arc which filter already present to use. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456 - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.
Yeah we have thought of that, however it seems like it would be slow and cumbersome. Exactly what do you use to parse the information from the Logs? Anything specific? or is it a custom script? Speed is of the essence in this method... and with 25,000+ users it would be tough to achieve I would think. I was hoping someone had done the Proxy method... but then again it has it's drawbacks as well. Ed ----- Original Message ----- From: "Jeff Mcadams" <jeffm@iglou.com> To: <usr-tc@lists.xmission.com> Sent: Friday, March 03, 2000 11:04 AM Subject: Re: (usr-tc) Holding Login information Thus spake Ed
Anyone have an experience in carrying Login information to a Website?
Example: Bob logs in he gets an IP address of 202.101.0.5 this is then carried with him in some sort of cookie (or other method) then it is passed onto a website thus allowing him entry.
So Bob gets in and others cannot. Also is it possible to pull out the login information such as Username?
Can this be done via a filter and proxy?
Thanks everyone!
We do this by parsing our RADIUS accounting log files (ugly, I know...I'm trying to come up with a better way of doing it), and then allow on the web server based on the information that was parsed out of the log files. I don't suspect that there is any reason that this same type of setup couldn't be extended to include a proxy server. Should be able to build filters to accomplish about the same thing...though the filters have to be on the NETServer/Arc before the user logs in. RADIUS can only tell the NETServer/Arc which filter already present to use. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456 - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message. - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.
Thus spake Ed
Yeah we have thought of that, however it seems like it would be slow and cumbersome. Exactly what do you use to parse the information from the Logs? Anything specific? or is it a custom script? Speed is of the essence in this method... and with 25,000+ users it would be tough to achieve I would think.
Yeah...we've got a custom written perl script that does...essentially...a tail -f on the RADIUS accounting log file, parses and stores each online connection in a directory...one entry per file...the file name is the IP address of the connection. Inside the file is information like userid, ip address, name of the NAS, ip of the NAS, port number on the NAS, caller and called id, time, etc. Then our scripts controlling access (via .htaccess for example) can get the ip address of the connection and quickly find the file they need with the information in it to decide whether to give access or not. Of course, when we see the stop record, we just remove the corresponding file. This'll occasionally get slightly out of sync with the actual connections on the NASen...but never very far...its somewhat self-correcting. If a new connection comes on with an IP address of a connection that didn't get removed when they disconnected, the file for that IP address is overwritten with the new connection, so stale connections don't stay in there for very long. Like I said...there are probably more elegant solutions for this...but so far this has worked fairly well for us. We'll probably have to come up with something different before to long in order to scale better...but this works for now.
I was hoping someone had done the Proxy method... but then again it has it's drawbacks as well.
Depending on the proxy server you use, you might be able to have the proxy server look into a file store like this to determine what sort of access to give...we haven't tried that. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456 - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.
On Fri, 3 Mar 2000, Jeff Mcadams wrote:
Thus spake Ed
Yeah we have thought of that, however it seems like it would be slow and cumbersome. Exactly what do you use to parse the information from the Logs? Anything specific? or is it a custom script? Speed is of the essence in this method... and with 25,000+ users it would be tough to achieve I would think.
Jeff, That whole mess just begs for an SQL database :) Brian
Yeah...we've got a custom written perl script that does...essentially...a tail -f on the RADIUS accounting log file, parses and stores each online connection in a directory...one entry per file...the file name is the IP address of the connection. Inside the file is information like userid, ip address, name of the NAS, ip of the NAS, port number on the NAS, caller and called id, time, etc. Then our scripts controlling access (via .htaccess for example) can get the ip address of the connection and quickly find the file they need with the information in it to decide whether to give access or not. Of course, when we see the stop record, we just remove the corresponding file.
This'll occasionally get slightly out of sync with the actual connections on the NASen...but never very far...its somewhat self-correcting. If a new connection comes on with an IP address of a connection that didn't get removed when they disconnected, the file for that IP address is overwritten with the new connection, so stale connections don't stay in there for very long.
Like I said...there are probably more elegant solutions for this...but so far this has worked fairly well for us. We'll probably have to come up with something different before to long in order to scale better...but this works for now.
I was hoping someone had done the Proxy method... but then again it has it's drawbacks as well.
Depending on the proxy server you use, you might be able to have the proxy server look into a file store like this to determine what sort of access to give...we haven't tried that. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456
- To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.
----------------------------------------------------- Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881) - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.
Thus spake Brian
That whole mess just begs for an SQL database :)
Why, yes it does. :) Gimme some of those tuits (not the square ones) and I just might get that set up. :) -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456 - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.
On Fri, 3 Mar 2000, Jeff Mcadams wrote:
Thus spake Ed
Yeah we have thought of that, however it seems like it would be slow and cumbersome. Exactly what do you use to parse the information from the Logs? Anything specific? or is it a custom script? Speed is of the essence in this method... and with 25,000+ users it would be tough to achieve I would think.
Yeah...we've got a custom written perl script that does...essentially...a tail -f on the RADIUS accounting log file, parses and stores each online connection in a directory...one entry per file...the file name is the IP address of the connection. Inside the file is information like userid, ip address, name of the NAS, ip of the NAS, port number on the NAS, caller and called id, time, etc. Then our scripts controlling access (via .htaccess for example) can get the ip address of the connection and quickly find the file they need with the information in it to decide whether to give access or not. Of course, when we see the stop record, we just remove the corresponding file.
I use a modified version of Cistron RADIUS with the MySQL patches, with the following notable reworks: - keeps active sessions in one table, prior sessions (not start/stop records) in another. - Uses persistent MySQL connection. - Handles database-down condition more gracefully, it queues to a temp file and then when the db comes back up, forks a child to clean up. The original code also forks but then waits for the child, which causes a big pileup of accounting records on the NASen. - Disconnects/reconnects from the database on SIGUSR1 (on Linux, anyway) to make "planned" database downtime a little smoother. The code and table structures could probably stand some cleanup, but it's in production use here with no major problems. I also have a companion script that reads the "online" table and walks through checking each supposedly-online user against the HARC via snmp, and kills off any stale records (which really only ever show up if a HARC gets rebooted unexpectedly.) If anyone wants it I'll clean up a little and put the diffs up for download. - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.
At 01:06 PM 3/4/00 -0600, you wrote:
On Fri, 3 Mar 2000, Jeff Mcadams wrote:
I use a modified version of Cistron RADIUS with the MySQL patches, with the following notable reworks:
- keeps active sessions in one table, prior sessions (not start/stop records) in another.
- Uses persistent MySQL connection.
- Handles database-down condition more gracefully, it queues to a temp file and then when the db comes back up, forks a child to clean up. The original code also forks but then waits for the child, which causes a big pileup of accounting records on the NASen.
- Disconnects/reconnects from the database on SIGUSR1 (on Linux, anyway) to make "planned" database downtime a little smoother.
The code and table structures could probably stand some cleanup, but it's in production use here with no major problems. I also have a companion script that reads the "online" table and walks through checking each supposedly-online user against the HARC via snmp, and kills off any stale records (which really only ever show up if a HARC gets rebooted unexpectedly.)
If anyone wants it I'll clean up a little and put the diffs up for download.
Yes, I would appreciate having a copy. Thanks. Lyle Evans Blacksburg.Net - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.
On Fri, 3 Mar 2000, Ed wrote:
Anyone have an experience in carrying Login information to a Website?
Example: Bob logs in he gets an IP address of 202.101.0.5 this is then carried with him in some sort of cookie (or other method) then it is passed onto a website thus allowing him entry. So Bob gets in and others cannot. Also is it possible to pull out the login information such as Username?
With hiperarcs at least, you can look at the ip they are coming from, which you get as a standard enviroment variable when they hit a web page. You can then cross this with a username in the ARC's snmp. I would caution though, I think its possible for the user hitting your web page to modify the env variable for the ip address and pretend he is someone he is not.
Can this be done via a filter and proxy?
Thanks everyone!
-- Ed
----- Original Message ----- From: "Brian" <signal@shreve.net> To: "Total Control List" <usr-tc@lists.xmission.com> Sent: Friday, March 03, 2000 10:40 AM Subject: Re: (usr-tc) Filter-Id
Yes they work this this.
On Fri, 3 Mar 2000, Scott Bailey wrote:
Can 3Com NETServers be configured to use the Radius Filter-Id attribute?
Any experiences good or bad with this?
-- Scott Bailey Systems Administrator Epix Internet Services scott@epix.net 570-631-1317
- To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.
----------------------------------------------------- Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)
- To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.
- To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.
----------------------------------------------------- Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881) - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.
I believe Radius or Proxy based methods would be better... not directly to the ARC's via SNMP or Telnet. That could be dangerous... Ed ----- Original Message ----- From: "Brian" <signal@shreve.net> To: <usr-tc@lists.xmission.com> Sent: Friday, March 03, 2000 11:57 AM Subject: Re: (usr-tc) Holding Login information On Fri, 3 Mar 2000, Ed wrote:
Anyone have an experience in carrying Login information to a Website?
Example: Bob logs in he gets an IP address of 202.101.0.5 this is then carried with him in some sort of cookie (or other method) then it is passed onto a website thus allowing him entry. So Bob gets in and others cannot. Also is it possible to pull out the login information such as Username?
With hiperarcs at least, you can look at the ip they are coming from, which you get as a standard enviroment variable when they hit a web page. You can then cross this with a username in the ARC's snmp. I would caution though, I think its possible for the user hitting your web page to modify the env variable for the ip address and pretend he is someone he is not. - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.
On Fri, 3 Mar 2000, Brian wrote:
With hiperarcs at least, you can look at the ip they are coming from, which you get as a standard enviroment variable when they hit a web page. You can then cross this with a username in the ARC's snmp. I would
That's what we do here... snmpwalk 1.3.6.1.4.1.429.4.10.1.1.9, find the IP address in there, and that gives us a port number. You can then get 1.3.6.1.4.1.429.4.10.1.1.18.$port_number and get the username. Fairly quick, always accurate. Radius logs stand a chance of getting out of whack in my experience, but that's mostly because we've got two Radius servers and entries could be logged to one of two machines if one goes down... and collecting it all back in one place is a pain -- unless you've got SQL capabilities in your Radius server. (We don't, yet. Haven't gotten around to it. :)
caution though, I think its possible for the user hitting your web page to modify the env variable for the ip address and pretend he is someone he is not.
Are you sure about that... on a standard Apache setup? Things like Squid make it harder to get the real IP address, but not impossible... Mike Andrews (MA12) * mandrews@dcr.net * http://www.bit0.com/ VP, sysadmin, & network guy, Digital Crescent Inc, Frankfort KY Internet services for Frankfort, Lawrenceburg, Owenton, Shelbyville "Don't sweat the petty things, and don't pet the sweaty things." - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.
we do that here for our user portal online users are in an sql table on our radius server(radiator http://www.open.com.au) the webserver just does a simple select username where ip=$remote_address are site is all php so the db bit is fast and users in our network dont need to re auth Steve Lalonde Systems Manager ENTANET International Ltd Most usefull Unix command :- man man Most Dangerous Unix command :- rm -rf / ----- Original Message ----- From: "Ed" <ed@taylors.com> To: <usr-tc@lists.xmission.com> Sent: 03 March 2000 15:55 Subject: (usr-tc) Holding Login information
Anyone have an experience in carrying Login information to a Website?
Example: Bob logs in he gets an IP address of 202.101.0.5 this is then carried with him in some sort of cookie (or other method) then it is passed onto a website thus allowing him entry. So Bob gets in and others cannot. Also is it possible to pull out the login information such as Username?
Can this be done via a filter and proxy?
Thanks everyone!
-- Ed
----- Original Message ----- From: "Brian" <signal@shreve.net> To: "Total Control List" <usr-tc@lists.xmission.com> Sent: Friday, March 03, 2000 10:40 AM Subject: Re: (usr-tc) Filter-Id
Yes they work this this.
On Fri, 3 Mar 2000, Scott Bailey wrote:
Can 3Com NETServers be configured to use the Radius Filter-Id attribute?
Any experiences good or bad with this?
-- Scott Bailey Systems Administrator Epix Internet Services scott@epix.net 570-631-1317
- To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.
----------------------------------------------------- Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)
- To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.
- To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.
- To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.
participants (8)
-
Brian -
Ed -
Jeff Mcadams -
Lyle Evans -
Mike Andrews -
ROC Services -
Scott Bailey -
Steve Lalonde