Re: (RADIATOR) Managing multiple realms.

2000-11-10 Thread Hugh Irvine


Hello Chris -

At 0:54 +1100 00/11/10, Chris Keladis wrote:
>Hi folks,
>
>I am configuring my Radiator systems (2.16.1) with many realms as i have
>different "business units" i want to authenticate from the same
>database. (Oracle). (I also have many different  clauses,
>whereby i want certain realms logging in from a certain place, to only
>have successfull access, bearing in mind all NASs are registered
>'s and i want to avoid someone hopping onto another network
>using their login to access other networks they may not be supposed to).
>
>I am using usernames of [EMAIL PROTECTED] and i have handlers
>configured to authenticate the user when a 'hit' occurs on one of my
>handler statements.
>
>I would like the added security of dictating which NAS the user connects
>from before i will give an Access-Accept response, otherwise generate an
>Access-Reject.
>
>I've got "NAS-IP-Address = 1.2.3.4" in my , which i havent
>tested yet, but i assume will do what i want.
>
>What i am wondering is, would i have to do this if i have 50 NASs, all
>in the Handler line?
>
>Looking through the docs there is the Identifier keyword, but that says
>it's not supported in the standard Radiator code, only in hooks, so i
>cant 'group' them and refer to them by a keyword.
>
>I guess this begs the question, if i can have multiline Handlers, and if
>so, what would be the correct syntax for them?
>
>Commas/Newline and/or backslashes?
>
>Also, out of curiosity, how would i specify a wildcard in a handler
>statement? Does it have the smarts to parse a network/bitmask? (or a
>derivative thereof)
>

I think the simplest, easiest and clearest way to do this is with a 
session database in SQL and an AuthBy PORTLIMITCHECK to query the 
database for the Realm/NAS matrix.

hth

Hugh
-- 
--
Radiator: the most portable, flexible and configurable RADIUS server
anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald,
Platypus, Freeside, Interbiller, TACACS+, PAM, external, etc, etc.
Available on Unix, Linux, FreeBSD, Windows 95/98/2000, NT, MacOS X.

===
Archive at http://www.starport.net/~radiator/
Announcements on [EMAIL PROTECTED]
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.



(RADIATOR) Managing multiple realms.

2000-11-09 Thread Chris Keladis

Hi folks,

I am configuring my Radiator systems (2.16.1) with many realms as i have
different "business units" i want to authenticate from the same
database. (Oracle). (I also have many different  clauses,
whereby i want certain realms logging in from a certain place, to only
have successfull access, bearing in mind all NASs are registered
's and i want to avoid someone hopping onto another network
using their login to access other networks they may not be supposed to).

I am using usernames of [EMAIL PROTECTED] and i have handlers
configured to authenticate the user when a 'hit' occurs on one of my
handler statements.

I would like the added security of dictating which NAS the user connects
from before i will give an Access-Accept response, otherwise generate an
Access-Reject.

I've got "NAS-IP-Address = 1.2.3.4" in my , which i havent
tested yet, but i assume will do what i want.

What i am wondering is, would i have to do this if i have 50 NASs, all
in the Handler line?

Looking through the docs there is the Identifier keyword, but that says
it's not supported in the standard Radiator code, only in hooks, so i
cant 'group' them and refer to them by a keyword.

I guess this begs the question, if i can have multiline Handlers, and if
so, what would be the correct syntax for them?

Commas/Newline and/or backslashes?

Also, out of curiosity, how would i specify a wildcard in a handler
statement? Does it have the smarts to parse a network/bitmask? (or a
derivative thereof)




Thanks in advance,


Chris.


===
Archive at http://www.starport.net/~radiator/
Announcements on [EMAIL PROTECTED]
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.