Re: (RADIATOR) MaxSessions override
Hi James. On Jun 10, 10:00pm, James H. Thompson wrote: Subject: (RADIATOR) MaxSessions override If you specify: MaxSessions 1 for a realm, does a Simultaneous-Use item for a particular user override this? No. Of those 2, the _most_restrictive_ one applies. The patched version of AuthGeneric.pm in the 2.13.1 patches area has a new DefaultSimultaneousUse parameter. That one _does_ get overridden by a per user Simultaneous-Use. You might want to try that? Hope that helps. Cheers. Jim [EMAIL PROTECTED] === Archive at http://www.thesite.com.au/~radiator/ To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message. -- End of excerpt from James H. Thompson -- Mike McCauley [EMAIL PROTECTED] Open System Consultants Pty. LtdUnix, Perl, Motif, C++, WWW 24 Bateman St Hampton, VIC 3188 Australia http://www.open.com.au Phone +61 3 9598-0985 Fax +61 3 9598-0955 Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, Platypus, Freeside, TACACS+, PAM, external, etc etc on Unix, Win95/8, NT, Rhapsody === Archive at http://www.thesite.com.au/~radiator/ To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
(RADIATOR) finger problem
Hi, We are using Radiator 2.13.1 on Solaris with Oracle v8. There are several POP's and we use finger for ghost sessions. We use Ascend TNTs. Radiator is in location Istanbul for example, and one of the POP's are in other city e.g. Ankara. When the line goes down between Istanbul-Ankara, and the user tries to logon in Istanbul, since the user information still on RADONLINE, it tries to check it thru finger and since the line is down, finger WAITS! a longtime thus Radiator does not respond other requests till the finger request is finished (single process that is). Then eventually finger timeouts and the session is deleted from RADONLINE and user is permitted. However this has two problems: 1- User may be still online in Ankara (thus simultanous sessions) 2- finger waits too long and no user auth is accepted till timeout of finger Any solutions to finger problem when the line is down? How can we automatically cancel finger requests if the line is down between POP and Radiator-Host location? Thanks very much, Ferhat === Archive at http://www.thesite.com.au/~radiator/ To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) Simultaneous use
Hi James. For complicated reasons, that wont work the way you expect, even if you use the DefaultSimultaneousUse parameter I mentioned recently. I think you will have to set up a full set of check and reply items for each special user. There are other ways to tackle this, involving chaining FILE authentication. Do you want to talk about that? Cheers. On Jun 10, 10:38pm, James H. Thompson wrote: Subject: (RADIATOR) Simultaneous use I have only a handful of users that are allowed to do 2 simultaneous logins. I want to restrict them to two logins, and everyone else to one. Will this work? In the realm: MaxSessions 1 In the users file: #users with dual login priv user1 Simultaneous-Use = 2 Fall-Through = yes user2 Simultaneous-Use = 2 Fall-Through = yes # Shiva DEFAULT NAS-Identifier = "LRD56_82BE00", Auth-Type = ljnet_sql Service-Type = Framed-User, Framed-Protocol = PPP, Framed-Compression = Van-Jacobson-TCP-IP Idle-Timeout = 400 # Nortel DEFAULT NAS-Identifier = "las-nortel", Auth-Type = ljnet_sql Service-Type = Framed-User, Framed-Protocol = PPP, Framed-Compression = Van-Jacobson-TCP-IP Idle-Timeout = 200 # TCR DEFAULT Auth-Type = ljnet_sql Service-Type = Framed-User, Framed-Protocol = PPP, Idle-Timeout = 900 Jim [EMAIL PROTECTED] === Archive at http://www.thesite.com.au/~radiator/ To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message. -- End of excerpt from James H. Thompson -- Mike McCauley [EMAIL PROTECTED] Open System Consultants Pty. LtdUnix, Perl, Motif, C++, WWW 24 Bateman St Hampton, VIC 3188 Australia http://www.open.com.au Phone +61 3 9598-0985 Fax +61 3 9598-0955 Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, Platypus, Freeside, TACACS+, PAM, external, etc etc on Unix, Win95/8, NT, Rhapsody === Archive at http://www.thesite.com.au/~radiator/ To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) finger problem
Hello Ferhat. What NasType are you using, and what does your finger say when it times out? Try running it by hand, to see. With that information, we might be able add a patch that will detect a timeout and not delete the user. Cheers. On Jun 11, 10:30am, Ferhat Dilman wrote: Subject: (RADIATOR) finger problem Hi, We are using Radiator 2.13.1 on Solaris with Oracle v8. There are several POP's and we use finger for ghost sessions. We use Ascend TNTs. Radiator is in location Istanbul for example, and one of the POP's are in other city e.g. Ankara. When the line goes down between Istanbul-Ankara, and the user tries to logon in Istanbul, since the user information still on RADONLINE, it tries to check it thru finger and since the line is down, finger WAITS! a longtime thus Radiator does not respond other requests till the finger request is finished (single process that is). Then eventually finger timeouts and the session is deleted from RADONLINE and user is permitted. However this has two problems: 1- User may be still online in Ankara (thus simultanous sessions) 2- finger waits too long and no user auth is accepted till timeout of finger Any solutions to finger problem when the line is down? How can we automatically cancel finger requests if the line is down between POP and Radiator-Host location? Thanks very much, Ferhat === Archive at http://www.thesite.com.au/~radiator/ To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message. -- End of excerpt from Ferhat Dilman -- Mike McCauley [EMAIL PROTECTED] Open System Consultants Pty. LtdUnix, Perl, Motif, C++, WWW 24 Bateman St Hampton, VIC 3188 Australia http://www.open.com.au Phone +61 3 9598-0985 Fax +61 3 9598-0955 Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, Platypus, Freeside, TACACS+, PAM, external, etc etc on Unix, Win95/8, NT, Rhapsody === Archive at http://www.thesite.com.au/~radiator/ To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
RE: (RADIATOR) finger problem
Hi, NasType Ascend and the log: Wed Jun 9 01:13:20 1999: ERR: The internal finger client failed with: Can't con nect to 195.x.x.x: Connection timed out Wed Jun 9 01:13:20 1999: NOTICE: Session for xx at 195.x.x.x:90 has gone away (I have deleted user information and NAS identifier IP address) Thanks, Ferhat -Original Message- From: Mike McCauley [mailto:[EMAIL PROTECTED]] Sent: Saturday, June 12, 1999 1:51 AM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Cc: 'Tuncay Margilic'; 'Lutfi Yunusoglu' Subject: Re: (RADIATOR) finger problem Hello Ferhat. What NasType are you using, and what does your finger say when it times out? Try running it by hand, to see. With that information, we might be able add a patch that will detect a timeout and not delete the user. Cheers. On Jun 11, 10:30am, Ferhat Dilman wrote: Subject: (RADIATOR) finger problem Hi, We are using Radiator 2.13.1 on Solaris with Oracle v8. There are several POP's and we use finger for ghost sessions. We use Ascend TNTs. Radiator is in location Istanbul for example, and one of the POP's are in other city e.g. Ankara. When the line goes down between Istanbul-Ankara, and the user tries to logon in Istanbul, since the user information still on RADONLINE, it tries to check it thru finger and since the line is down, finger WAITS! a longtime thus Radiator does not respond other requests till the finger request is finished (single process that is). Then eventually finger timeouts and the session is deleted from RADONLINE and user is permitted. However this has two problems: 1- User may be still online in Ankara (thus simultanous sessions) 2- finger waits too long and no user auth is accepted till timeout of finger Any solutions to finger problem when the line is down? How can we automatically cancel finger requests if the line is down between POP and Radiator-Host location? Thanks very much, Ferhat === Archive at http://www.thesite.com.au/~radiator/ To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message. -- End of excerpt from Ferhat Dilman -- Mike McCauley [EMAIL PROTECTED] Open System Consultants Pty. LtdUnix, Perl, Motif, C++, WWW 24 Bateman St Hampton, VIC 3188 Australia http://www.open.com.au Phone +61 3 9598-0985 Fax +61 3 9598-0955 Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, Platypus, Freeside, TACACS+, PAM, external, etc etc on Unix, Win95/8, NT, Rhapsody === Archive at http://www.thesite.com.au/~radiator/ To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) Simultaneous use
Since the NAS reply items are different for each NAS, I'd have to setup 3 full sets of check/reply items for each user. That sounds like too much work. How would I do it by chaining the File authentications? Since I'm using SQL Auth, Would this work? Set DefaultSimultaneousUse to 1 Create a new sql table containing 2 fields: username check item And use a LEFT OUTER JOIN to reference this table in the Auth SQL stmt. This way the check item would be null for everyone except for users that have an row in this table. The row for these users would have thier 'check item' column set to 'Simultaneous-Use = 2' On Fri, 11 Jun 1999, Mike McCauley wrote: Hi James. For complicated reasons, that wont work the way you expect, even if you use the DefaultSimultaneousUse parameter I mentioned recently. I think you will have to set up a full set of check and reply items for each special user. There are other ways to tackle this, involving chaining FILE authentication. Do you want to talk about that? Cheers. On Jun 10, 10:38pm, James H. Thompson wrote: Subject: (RADIATOR) Simultaneous use I have only a handful of users that are allowed to do 2 simultaneous logins. I want to restrict them to two logins, and everyone else to one. Will this work? In the realm: MaxSessions 1 In the users file: #users with dual login priv user1 Simultaneous-Use = 2 Fall-Through = yes user2 Simultaneous-Use = 2 Fall-Through = yes # Shiva DEFAULT NAS-Identifier = "LRD56_82BE00", Auth-Type = ljnet_sql Service-Type = Framed-User, Framed-Protocol = PPP, Framed-Compression = Van-Jacobson-TCP-IP Idle-Timeout = 400 # Nortel DEFAULT NAS-Identifier = "las-nortel", Auth-Type = ljnet_sql Service-Type = Framed-User, Framed-Protocol = PPP, Framed-Compression = Van-Jacobson-TCP-IP Idle-Timeout = 200 # TCR DEFAULT Auth-Type = ljnet_sql Service-Type = Framed-User, Framed-Protocol = PPP, Idle-Timeout = 900 Jim [EMAIL PROTECTED] === Archive at http://www.thesite.com.au/~radiator/ To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message. -- End of excerpt from James H. Thompson -- Mike McCauley [EMAIL PROTECTED] Open System Consultants Pty. LtdUnix, Perl, Motif, C++, WWW 24 Bateman St Hampton, VIC 3188 Australia http://www.open.com.au Phone +61 3 9598-0985 Fax +61 3 9598-0955 Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, Platypus, Freeside, TACACS+, PAM, external, etc etc on Unix, Win95/8, NT, Rhapsody Jim [EMAIL PROTECTED] === Archive at http://www.thesite.com.au/~radiator/ To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) finger problem
On Fri, 11 Jun 1999, Mike McCauley wrote: Hello Ferhat. What NasType are you using, and what does your finger say when it times out? Try running it by hand, to see. With that information, we might be able add a patch that will detect a timeout and not delete the user. The BIG problem isn't deleting the user, it is the HUGE delay that occurs while Radiator is trying to verify the user. This stops all other authentications, and when you are running a lot of ports it is disastrous. Steve --- Steve Roderick ProAxis Communications, Inc. [EMAIL PROTECTED] Internet Access Provider (541) 757-0248 === Archive at http://www.thesite.com.au/~radiator/ To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
(RADIATOR) Probs with AccountingHandled
Hi, at my setup each customer group has his own Realm. I use 'RewriteUsername' to control this. Now, from time to time (no reboot or anything like this is done), my NAS (Livingston PM3) send the following Accounting Request out: Acct-Session-Id = "" NAS-IP-Address = IP-Number Acct-Status-Type = Start Acct-Delay-Time = 6 Timestamp = 929071869 As you can see, no username is in this request, so my rewriting doesn't work and the request doesn't end up in one of my Realms. It is ignored by Radiator an die NAS keeps retransmitting. Therefor I created a "special Handler": Handler Acct-Session-Id="" AcctLogFileName %L/stupid.detail AccountingHandled /Handler But Radiator (version 2.13.1) still ignore the Request. Inserting a simple AuthBy TEST /AuthBy in the above Realm fixes the Problem. Is this normal? Is there a better solution for my problem? Regards, Bernd === Archive at http://www.thesite.com.au/~radiator/ To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) finger problem
One quick solution would be to write your own finger client for Radiator to run. It could do things like: use a shorter timeout remember the state of the line from previous calls etc. On Fri, 11 Jun 1999, Stephen Roderick wrote: On Fri, 11 Jun 1999, Mike McCauley wrote: Hello Ferhat. What NasType are you using, and what does your finger say when it times out? Try running it by hand, to see. With that information, we might be able add a patch that will detect a timeout and not delete the user. The BIG problem isn't deleting the user, it is the HUGE delay that occurs while Radiator is trying to verify the user. This stops all other authentications, and when you are running a lot of ports it is disastrous. Steve --- Steve Roderick ProAxis Communications, Inc. [EMAIL PROTECTED] Internet Access Provider (541) 757-0248 === Archive at http://www.thesite.com.au/~radiator/ To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message. Jim [EMAIL PROTECTED] === Archive at http://www.thesite.com.au/~radiator/ To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
