Re: (RADIATOR) SnmpgetProg Maxsessions check
Hi I have gone thru' the FAQs, and something still not clear to me. I have a proxy radius server, which proxies the requests based on usr_chassis_call_slot for the Hipers and called_station_id for the as5300. On the proxy radius server config, there is no any check for Maxsessions. My SessionDatabase SQL configuration is on the radius server that recieves requests from the proxy radius server. The only clients this server knows are the proxy_radius servers, and not the Nases themselves. How do i tell that radius server which Nas to query for Max sessions ?. Do I need My SessionDatabase SQL at the proxy radius server level? Rgds TDN - Original Message - From: Hugh Irvine [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: 04-02-2003 10:45 AM Subject: Re: (RADIATOR) SnmpgetProg Maxsessions check Hello - You should add a NasType parameter to your Client clauses and configure the NAS's to accept the corresponding queries. Have a look at section 6.5.5 in the Radiator 3.5 reference manual (doc/ref.html). This topic has also been discussed many times on the mailing list. www.open.com.au/archives/radiator regards Hugh On Tuesday, Feb 4, 2003, at 18:33 Australia/Melbourne, [EMAIL PROTECTED] wrote: Hi I have a number of 3com Hipers as well a a Cisco as5300 and an SQL-based session database to check Max sessions. I am really being troubled by cases of stale sessions, and someone mentioned that I can use SNMP to check whether the sessions are indeed genuine (i.e by querying the Nas). Can someone please tell me how to go about configuring this and whether it will solve my problems. Thanks TDN === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message. -- Radiator: the most portable, flexible and configurable RADIUS server anywhere. Available on *NIX, *BSD, Windows 95/98/2000, NT, MacOS X. - Nets: internetwork inventory and management - graphical, extensible, flexible with hardware, software, platform and database independence. === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message. === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
(RADIATOR) radwho.cgi suggestion
Hi, I use radwho.cgi with SQL DB and was interested on the time online for some users. Script does not sort properly clicking Time On link, so I modified script as below. I'm yet to install 3.5, so I haven't checked whether this is already ok. # diff /sysadmin/Radiator-3.4/goodies/radwho.cgi radwho.cgi 65c65 ['Time On', 'TIME_STAMP', 'interval'], --- ['Time-On', 'TIME_STAMP', 'interval'], Regards, -- Petri Mäenpää Systems Engineer Satakunnan Puhelin Oy === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
RE: (RADIATOR) Auth only on same realm
Yes. You shut put your most detailed match first and work down to more generic ones. -Original Message- From: Tom Swenson [mailto:[EMAIL PROTECTED]] Sent: Tuesday, February 04, 2003 12:14 PM To: [EMAIL PROTECTED] Subject: Re: (RADIATOR) Auth only on same realm Just so I understand correctly. Does the handlers work like a cisco access list in that it will start at the top of the file and the first handler that matches, it is completed? Tom Swenson - CTO NetConX - Internet Access - Client Managed Web Database Applications Wireless - Virus Blocking - Spam Blocking [EMAIL PROTECTED] http://www.netconx.net (641) 421-4170 - Voice (641) 423-3351 - FAX There's a better way to do it. Find it! - Thomas Edison *** REPLY SEPARATOR *** On 1/31/2003 at 10:35 AM Hugh Irvine wrote: Hello Tom - I don't quite understand your question sorry. Could you give me a bit more detail please? If you want usernames without realms to be treated the same way as those with realms, you can add a DefaultRealm parameter to your Client clauses: # define Client clauses Client . DefaultRealm foo.bar /Client . regards Hugh On Friday, Jan 31, 2003, at 10:04 Australia/Melbourne, Tom Swenson wrote: I tried this and I think it will work, but I have to figure out a way to get the default domain in there. Is there an easier way than to put in an identifier for every client and then a handler at the end of my domains to catch all the ones without domains? Thanks again. Tom Swenson - CTO NetConX - Internet Access - Client Managed Web Database Applications Wireless - Virus Blocking - Spam Blocking [EMAIL PROTECTED] http://www.netconx.net (641) 421-4170 - Voice (641) 423-3351 - FAX Your imagination is your preview of life's coming attractions - Albert Einstein *** REPLY SEPARATOR *** On 1/31/2003 at 9:24 AM Hugh Irvine wrote: Hello Tom - You should not mix Realms and Handlers in the same configuration file for exactly this reason - Realms are always evaluated first. Change your Realms to Handlers like this: Realm foo.bar . /Realm becomes Handler Realm = foo.bar . /Handler Note that Handlers are evaluated in the order they appear in the configuration file, so the more specific must appear before the more general, keeping in mind that you want the most hit Handlers as close to the top of the list as possible. regards Hugh On Friday, Jan 31, 2003, at 04:55 Australia/Melbourne, Tom Swenson wrote: I have a newsgroup server that I have told to authenticate with the same realm as my dial in customers. I created special client for this server and then put in an identifier. I thought it would then go to the handler I created to just authenticate only. No accounting or sessions. I'm finding that it is instead of going to the handler, it is going to the realm. The manual says it this is how it will do this. I don't know what to do now. Here is what I have, but I don't think it ever goes to the handler. Is there anything I can specify in the client section to make it go to a specific realm or handler? Client xx.xx.xx.xx DupInterval 0 IgnoreAcctSignature Secret xxx Identifier newsauth /Client # news group authentication Handler Client-Identifier=newsauth AuthBy ID_0 AuthByPolicy ContinueWhileIgnore RewriteUsername s/^([^@]+).*/$1/ /Handler Tom Swenson - CTO NetConX - Internet Access - Client Managed Web Database Applications Wireless - Virus Blocking - Spam Blocking [EMAIL PROTECTED] http://www.netconx.net (641) 421-4170 - Voice (641) 423-3351 - FAX Your imagination is your preview of life's coming attractions - Albert Einstein === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message. -- Radiator: the most portable, flexible and configurable RADIUS server anywhere. Available on *NIX, *BSD, Windows 95/98/2000, NT, MacOS X. - Nets: internetwork inventory and management - graphical, extensible, flexible with hardware, software, platform and database independence. === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message. === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message. -- Radiator: the most portable, flexible and configurable RADIUS server anywhere. Available on *NIX, *BSD, Windows 95/98/2000, NT, MacOS X. - Nets: internetwork inventory and management - graphical, extensible, flexible with hardware, software, platform and database independence. === Archive at
(RADIATOR) Assign IP's or Default
Ok guys, Im trying to finish up my migration off of livingston radius.
Here is what I would like to do.
Currently in radiator I am authing users out of an SQL database.
Some of my users have Static IP address and Framed routes.
For these users I had entries in the Users File in livingston.
For other users I had differnt default entries based on what group they
belong to.
Some users can use 1 port or 2 ports.
Some users have differnt Session Timouts.
What I would like to do is:
AuthSelect select password,gid,replyattr from users where
username='%U' AND isactive 0 ( 0 means locked users in my database )
now if their replyattr is not NULL in the database send it along. This
would be for the static folks.
Now since I don't want a billion (ok not a billion) entries in my
database that are the same:
If replyattr is NULL I would like to go
if($gid == 200 ) {
send this replyattr:
Idle=Timeout = 1220,
Session-Timeout = 86400,
Port-Limit = 2
} elsif ($gid == 201 ) {
send this other replyattr :
Idle=Timeout = 1220,
Session-Timeout = 86400,
Port-Limit = 1
} else {
reject the call because there is no matching gid (maybe it's a
mailbox account)
}
Is this doable?
Also do you know if there is a way to say if they connect with an ISDN
line but they are using a dialup username, reject the call or make it so
they only connect at 56K?
Any help would be great.
Thanks,
William
===
Archive at http://www.open.com.au/archives/radiator/
Announcements on [EMAIL PROTECTED]
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) Auth only on same realm
Hello Tom - Yes. Handlers are evaluated in the order they appear in the configuration file with the first match being the only match. For completeness, you should be aware that mixing Realms and Handlers in the same configuration file is not recommended, as Realms are *always* evaluated before Handlers. regards Hugh On Wednesday, Feb 5, 2003, at 04:14 Australia/Melbourne, Tom Swenson wrote: Just so I understand correctly. Does the handlers work like a cisco access list in that it will start at the top of the file and the first handler that matches, it is completed? Tom Swenson - CTO NetConX - Internet Access - Client Managed Web Database Applications Wireless - Virus Blocking - Spam Blocking [EMAIL PROTECTED] http://www.netconx.net (641) 421-4170 - Voice (641) 423-3351 - FAX There's a better way to do it. Find it! - Thomas Edison *** REPLY SEPARATOR *** On 1/31/2003 at 10:35 AM Hugh Irvine wrote: Hello Tom - I don't quite understand your question sorry. Could you give me a bit more detail please? If you want usernames without realms to be treated the same way as those with realms, you can add a DefaultRealm parameter to your Client clauses: # define Client clauses Client . DefaultRealm foo.bar /Client . regards Hugh On Friday, Jan 31, 2003, at 10:04 Australia/Melbourne, Tom Swenson wrote: I tried this and I think it will work, but I have to figure out a way to get the default domain in there. Is there an easier way than to put in an identifier for every client and then a handler at the end of my domains to catch all the ones without domains? Thanks again. Tom Swenson - CTO NetConX - Internet Access - Client Managed Web Database Applications Wireless - Virus Blocking - Spam Blocking [EMAIL PROTECTED] http://www.netconx.net (641) 421-4170 - Voice (641) 423-3351 - FAX Your imagination is your preview of life's coming attractions - Albert Einstein *** REPLY SEPARATOR *** On 1/31/2003 at 9:24 AM Hugh Irvine wrote: Hello Tom - You should not mix Realms and Handlers in the same configuration file for exactly this reason - Realms are always evaluated first. Change your Realms to Handlers like this: Realm foo.bar . /Realm becomes Handler Realm = foo.bar . /Handler Note that Handlers are evaluated in the order they appear in the configuration file, so the more specific must appear before the more general, keeping in mind that you want the most hit Handlers as close to the top of the list as possible. regards Hugh On Friday, Jan 31, 2003, at 04:55 Australia/Melbourne, Tom Swenson wrote: I have a newsgroup server that I have told to authenticate with the same realm as my dial in customers. I created special client for this server and then put in an identifier. I thought it would then go to the handler I created to just authenticate only. No accounting or sessions. I'm finding that it is instead of going to the handler, it is going to the realm. The manual says it this is how it will do this. I don't know what to do now. Here is what I have, but I don't think it ever goes to the handler. Is there anything I can specify in the client section to make it go to a specific realm or handler? Client xx.xx.xx.xx DupInterval 0 IgnoreAcctSignature Secret xxx Identifier newsauth /Client # news group authentication Handler Client-Identifier=newsauth AuthBy ID_0 AuthByPolicy ContinueWhileIgnore RewriteUsername s/^([^@]+).*/$1/ /Handler Tom Swenson - CTO NetConX - Internet Access - Client Managed Web Database Applications Wireless - Virus Blocking - Spam Blocking [EMAIL PROTECTED] http://www.netconx.net (641) 421-4170 - Voice (641) 423-3351 - FAX Your imagination is your preview of life's coming attractions - Albert Einstein === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message. -- Radiator: the most portable, flexible and configurable RADIUS server anywhere. Available on *NIX, *BSD, Windows 95/98/2000, NT, MacOS X. - Nets: internetwork inventory and management - graphical, extensible, flexible with hardware, software, platform and database independence. === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message. === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message. -- Radiator: the most portable, flexible and configurable RADIUS server anywhere. Available on *NIX, *BSD, Windows 95/98/2000, NT, MacOS X. - Nets: internetwork inventory and management - graphical, extensible, flexible with hardware, software, platform and database independence.
Re: (RADIATOR) SnmpgetProg Maxsessions check
Hello - You are correct, you can only query the NAS's and maintain a session database from the level of the proxy server. As you rightly point out, if you are receiving the requests from a proxy, the only Client clause is for the proxy itself, not the NAS's. regards Hugh On Tuesday, Feb 4, 2003, at 22:00 Australia/Melbourne, [EMAIL PROTECTED] wrote: Hi I have gone thru' the FAQs, and something still not clear to me. I have a proxy radius server, which proxies the requests based on usr_chassis_call_slot for the Hipers and called_station_id for the as5300. On the proxy radius server config, there is no any check for Maxsessions. My SessionDatabase SQL configuration is on the radius server that recieves requests from the proxy radius server. The only clients this server knows are the proxy_radius servers, and not the Nases themselves. How do i tell that radius server which Nas to query for Max sessions ?. Do I need My SessionDatabase SQL at the proxy radius server level? Rgds TDN - Original Message - From: Hugh Irvine [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: 04-02-2003 10:45 AM Subject: Re: (RADIATOR) SnmpgetProg Maxsessions check Hello - You should add a NasType parameter to your Client clauses and configure the NAS's to accept the corresponding queries. Have a look at section 6.5.5 in the Radiator 3.5 reference manual (doc/ref.html). This topic has also been discussed many times on the mailing list. www.open.com.au/archives/radiator regards Hugh On Tuesday, Feb 4, 2003, at 18:33 Australia/Melbourne, [EMAIL PROTECTED] wrote: Hi I have a number of 3com Hipers as well a a Cisco as5300 and an SQL-based session database to check Max sessions. I am really being troubled by cases of stale sessions, and someone mentioned that I can use SNMP to check whether the sessions are indeed genuine (i.e by querying the Nas). Can someone please tell me how to go about configuring this and whether it will solve my problems. Thanks TDN === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message. -- Radiator: the most portable, flexible and configurable RADIUS server anywhere. Available on *NIX, *BSD, Windows 95/98/2000, NT, MacOS X. - Nets: internetwork inventory and management - graphical, extensible, flexible with hardware, software, platform and database independence. === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message. -- Radiator: the most portable, flexible and configurable RADIUS server anywhere. Available on *NIX, *BSD, Windows 95/98/2000, NT, MacOS X. - Nets: internetwork inventory and management - graphical, extensible, flexible with hardware, software, platform and database independence. === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) Assign IP's or Default
Hello William -
All of what you want to do is fairly straightforward, although dealing
with ISDN will probably involve the use of Handlers.
Here is what I would do:
# define AuthBy clauses
AuthBy SQL
Identifier CheckISDN
.
# set up AuthSelect for ISDN only
AuthSelect .
.
AddToReply Service-Type = Framed-User, \
Framed-Protocol = PPP, \
.
.
/AuthBy
AuthBy SQL
Identifier CheckAsync
.
# set up AuthSelect
AuthSelect select PASSWORD, GID, REPLYATTR \
from USERS where USERNAME = '%U' \
and ISACTIVE 0
AuthColumnDef 0, Password, check
AuthColumnDef 1, Group-Id, request
AuthColumnDef 2, GENERIC, reply
.
AddToReply Service-Type = Framed-User, \
Framed-Protocol = PPP, \
...
/AuthBy
# define Handlers
Handler NAS-Port-Type = ISDN
AuthBy CheckISDN
.
/Handler
Handler
AuthBy CheckAsync
PostAuthHook file:%D/postprocess.pl
.
/Handler
The PostAuthHook would add the extra reply attributes according to the
Group-Id pseudo-attribute added to the incoming access request by the
AuthBy clause (it is easier to add the pseudo-attribute to the incoming
request, because the packet is discarded after processing).
You will find some example hooks in the file goodies/hooks.txt in the
Radiator distribution.
regards
Hugh
On Wednesday, Feb 5, 2003, at 06:39 Australia/Melbourne, William Taylor
wrote:
Ok guys, Im trying to finish up my migration off of livingston radius.
Here is what I would like to do.
Currently in radiator I am authing users out of an SQL database.
Some of my users have Static IP address and Framed routes.
For these users I had entries in the Users File in livingston.
For other users I had differnt default entries based on what group they
belong to.
Some users can use 1 port or 2 ports.
Some users have differnt Session Timouts.
What I would like to do is:
AuthSelect select password,gid,replyattr from users where
username='%U' AND isactive 0 ( 0 means locked users in my database
)
now if their replyattr is not NULL in the database send it along. This
would be for the static folks.
Now since I don't want a billion (ok not a billion) entries in my
database that are the same:
If replyattr is NULL I would like to go
if($gid == 200 ) {
send this replyattr:
Idle=Timeout = 1220,
Session-Timeout = 86400,
Port-Limit = 2
} elsif ($gid == 201 ) {
send this other replyattr :
Idle=Timeout = 1220,
Session-Timeout = 86400,
Port-Limit = 1
} else {
reject the call because there is no matching gid (maybe it's a
mailbox account)
}
Is this doable?
Also do you know if there is a way to say if they connect with an ISDN
line but they are using a dialup username, reject the call or make it
so
they only connect at 56K?
Any help would be great.
Thanks,
William
===
Archive at http://www.open.com.au/archives/radiator/
Announcements on [EMAIL PROTECTED]
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.
--
Radiator: the most portable, flexible and configurable RADIUS server
anywhere. Available on *NIX, *BSD, Windows 95/98/2000, NT, MacOS X.
-
Nets: internetwork inventory and management - graphical, extensible,
flexible with hardware, software, platform and database independence.
===
Archive at http://www.open.com.au/archives/radiator/
Announcements on [EMAIL PROTECTED]
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.
(RADIATOR) Different NASes, same realms
We are getting into compatibility problems with different Ascend NASes from our providers, which requires us to run different AuthBy for each. Since we use them with the same realms, what is the best way to differentiate NASes? Rewrite realms to something weird like realm.com-provider in the Clients? Any other way? Thanks. === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) Assign IP's or Default
Hi Hugh,
Thanks for the info. I was doing something similar with the
replaceProfiles hook you were using. I do have a question though.
Below in the AuthColumnDef you say Group-Id, request
Are you sure that is supposed to be request and not reply?
I don't get anything with using request when I do a :
my $rp = ${$_[1]};
$gid = $rp-get_attr('Group-Id');
But if I change it to reply I do.
Thanks again for the help.
On Tue, 2003-02-04 at 14:57, Hugh Irvine wrote:
Hello William -
All of what you want to do is fairly straightforward, although dealing
with ISDN will probably involve the use of Handlers.
Here is what I would do:
# define AuthBy clauses
AuthBy SQL
Identifier CheckISDN
.
# set up AuthSelect for ISDN only
AuthSelect .
.
AddToReply Service-Type = Framed-User, \
Framed-Protocol = PPP, \
.
.
/AuthBy
AuthBy SQL
Identifier CheckAsync
.
# set up AuthSelect
AuthSelect select PASSWORD, GID, REPLYATTR \
from USERS where USERNAME = '%U' \
and ISACTIVE 0
AuthColumnDef 0, Password, check
AuthColumnDef 1, Group-Id, request
AuthColumnDef 2, GENERIC, reply
.
AddToReply Service-Type = Framed-User, \
Framed-Protocol = PPP, \
...
/AuthBy
# define Handlers
Handler NAS-Port-Type = ISDN
AuthBy CheckISDN
.
/Handler
Handler
AuthBy CheckAsync
PostAuthHook file:%D/postprocess.pl
.
/Handler
The PostAuthHook would add the extra reply attributes according to the
Group-Id pseudo-attribute added to the incoming access request by the
AuthBy clause (it is easier to add the pseudo-attribute to the incoming
request, because the packet is discarded after processing).
You will find some example hooks in the file goodies/hooks.txt in the
Radiator distribution.
regards
Hugh
On Wednesday, Feb 5, 2003, at 06:39 Australia/Melbourne, William Taylor
wrote:
Ok guys, Im trying to finish up my migration off of livingston radius.
Here is what I would like to do.
Currently in radiator I am authing users out of an SQL database.
Some of my users have Static IP address and Framed routes.
For these users I had entries in the Users File in livingston.
For other users I had differnt default entries based on what group they
belong to.
Some users can use 1 port or 2 ports.
Some users have differnt Session Timouts.
What I would like to do is:
AuthSelect select password,gid,replyattr from users where
username='%U' AND isactive 0 ( 0 means locked users in my database
)
now if their replyattr is not NULL in the database send it along. This
would be for the static folks.
Now since I don't want a billion (ok not a billion) entries in my
database that are the same:
If replyattr is NULL I would like to go
if($gid == 200 ) {
send this replyattr:
Idle=Timeout = 1220,
Session-Timeout = 86400,
Port-Limit = 2
} elsif ($gid == 201 ) {
send this other replyattr :
Idle=Timeout = 1220,
Session-Timeout = 86400,
Port-Limit = 1
} else {
reject the call because there is no matching gid (maybe it's a
mailbox account)
}
Is this doable?
Also do you know if there is a way to say if they connect with an ISDN
line but they are using a dialup username, reject the call or make it
so
they only connect at 56K?
Any help would be great.
Thanks,
William
===
Archive at http://www.open.com.au/archives/radiator/
Announcements on [EMAIL PROTECTED]
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.
===
Archive at http://www.open.com.au/archives/radiator/
Announcements on [EMAIL PROTECTED]
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) Assign IP's or Default
Hello William -
Yes I do mean request, which you can reference with:
$gid = $p-get_attr('Group-Id');
The reason for doing it this way (as described in my previous mail) is
because you then don't have to bother with any housekeeping as the
request packet is discarded automatically. You can also do it as you
show below, but then you have to remove the Group-Id attribute from
the reply packet before returning it to the NAS, otherwise you will get
an error in your logs.
regards
Hugh
On Wednesday, Feb 5, 2003, at 10:30 Australia/Melbourne, William Taylor
wrote:
Hi Hugh,
Thanks for the info. I was doing something similar with the
replaceProfiles hook you were using. I do have a question though.
Below in the AuthColumnDef you say Group-Id, request
Are you sure that is supposed to be request and not reply?
I don't get anything with using request when I do a :
my $rp = ${$_[1]};
$gid = $rp-get_attr('Group-Id');
But if I change it to reply I do.
Thanks again for the help.
On Tue, 2003-02-04 at 14:57, Hugh Irvine wrote:
Hello William -
All of what you want to do is fairly straightforward, although dealing
with ISDN will probably involve the use of Handlers.
Here is what I would do:
# define AuthBy clauses
AuthBy SQL
Identifier CheckISDN
.
# set up AuthSelect for ISDN only
AuthSelect .
.
AddToReply Service-Type = Framed-User, \
Framed-Protocol = PPP, \
.
.
/AuthBy
AuthBy SQL
Identifier CheckAsync
.
# set up AuthSelect
AuthSelect select PASSWORD, GID, REPLYATTR \
from USERS where USERNAME = '%U' \
and ISACTIVE 0
AuthColumnDef 0, Password, check
AuthColumnDef 1, Group-Id, request
AuthColumnDef 2, GENERIC, reply
.
AddToReply Service-Type = Framed-User, \
Framed-Protocol = PPP, \
...
/AuthBy
# define Handlers
Handler NAS-Port-Type = ISDN
AuthBy CheckISDN
.
/Handler
Handler
AuthBy CheckAsync
PostAuthHook file:%D/postprocess.pl
.
/Handler
The PostAuthHook would add the extra reply attributes according to the
Group-Id pseudo-attribute added to the incoming access request by
the
AuthBy clause (it is easier to add the pseudo-attribute to the
incoming
request, because the packet is discarded after processing).
You will find some example hooks in the file goodies/hooks.txt in
the
Radiator distribution.
regards
Hugh
On Wednesday, Feb 5, 2003, at 06:39 Australia/Melbourne, William
Taylor
wrote:
Ok guys, Im trying to finish up my migration off of livingston
radius.
Here is what I would like to do.
Currently in radiator I am authing users out of an SQL database.
Some of my users have Static IP address and Framed routes.
For these users I had entries in the Users File in livingston.
For other users I had differnt default entries based on what group
they
belong to.
Some users can use 1 port or 2 ports.
Some users have differnt Session Timouts.
What I would like to do is:
AuthSelect select password,gid,replyattr from users where
username='%U' AND isactive 0 ( 0 means locked users in my
database
)
now if their replyattr is not NULL in the database send it along.
This
would be for the static folks.
Now since I don't want a billion (ok not a billion) entries in my
database that are the same:
If replyattr is NULL I would like to go
if($gid == 200 ) {
send this replyattr:
Idle=Timeout = 1220,
Session-Timeout = 86400,
Port-Limit = 2
} elsif ($gid == 201 ) {
send this other replyattr :
Idle=Timeout = 1220,
Session-Timeout = 86400,
Port-Limit = 1
} else {
reject the call because there is no matching gid (maybe it's a
mailbox account)
}
Is this doable?
Also do you know if there is a way to say if they connect with an
ISDN
line but they are using a dialup username, reject the call or make it
so
they only connect at 56K?
Any help would be great.
Thanks,
William
===
Archive at http://www.open.com.au/archives/radiator/
Announcements on [EMAIL PROTECTED]
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.
===
Archive at http://www.open.com.au/archives/radiator/
Announcements on [EMAIL PROTECTED]
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.
--
Radiator: the most portable, flexible and configurable RADIUS server
anywhere. Available on *NIX, *BSD, Windows 95/98/2000, NT, MacOS X.
-
Nets: internetwork inventory and management - graphical, extensible,
flexible with hardware, software, platform and database independence.
===
Archive at http://www.open.com.au/archives/radiator/
Announcements on [EMAIL PROTECTED]
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) Different NASes, same realms
Hello Dan - The best way to do this sort of thing is like this: # define Client clauses Client 1.1.1.1 Identifier Ascend-Type-A . /Client Client 2.2.2.2 Identifier Ascend-Type-A . /Client Client 3.3.3.3 Identifier Ascend-Type-B . /Client Client 4.4.4.4 Identifier Ascend-Type-C . /Client ... # define AuthBy clauses AuthBy ... Identifier Auth-Ascend-Type-A . /AuthBy AuthBy ... Identifier Auth-Ascend-Type-B . /AuthBy AuthBy ... Identifier Auth-Ascend-Type-C . /AuthBy .. # define Handlers Handler Client-Identifier = Ascend-Type-A AuthBy Auth-Ascend-Type-A .. /Handler Handler Client-Identifier = Ascend-Type-B AuthBy Auth-Ascend-Type-B .. /Handler Handler Client-Identifier = Ascend-Type-C AuthBy Auth-Ascend-Type-C .. /Handler .. Hope that helps. regards Hugh On Wednesday, Feb 5, 2003, at 10:08 Australia/Melbourne, Dan Melomedman wrote: We are getting into compatibility problems with different Ascend NASes from our providers, which requires us to run different AuthBy for each. Since we use them with the same realms, what is the best way to differentiate NASes? Rewrite realms to something weird like realm.com-provider in the Clients? Any other way? Thanks. === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message. -- Radiator: the most portable, flexible and configurable RADIUS server anywhere. Available on *NIX, *BSD, Windows 95/98/2000, NT, MacOS X. - Nets: internetwork inventory and management - graphical, extensible, flexible with hardware, software, platform and database independence. === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) Different NASes, same realms
Hugh Irvine wrote: Hello Dan - The best way to do this sort of thing is like this: # define Client clauses Client 1.1.1.1 Identifier Ascend-Type-A . /Client Handler Client-Identifier = Ascend-Type-A AuthBy Auth-Ascend-Type-A .. /Handler Ouch, I missed client identifiers in the documentation. Are there any plans to reorganize documentation into multiple HTML pages? === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) Different NASes, same realms
Hello Dan - The manual is available in several formats (PS, PDF, HTML) in the doc directory. I myself use doc/ref.html constantly. regards Hugh On Wednesday, Feb 5, 2003, at 12:44 Australia/Melbourne, Dan Melomedman wrote: Hugh Irvine wrote: Hello Dan - The best way to do this sort of thing is like this: # define Client clauses Client 1.1.1.1 Identifier Ascend-Type-A . /Client Handler Client-Identifier = Ascend-Type-A AuthBy Auth-Ascend-Type-A .. /Handler Ouch, I missed client identifiers in the documentation. Are there any plans to reorganize documentation into multiple HTML pages? === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message. -- Radiator: the most portable, flexible and configurable RADIUS server anywhere. Available on *NIX, *BSD, Windows 95/98/2000, NT, MacOS X. - Nets: internetwork inventory and management - graphical, extensible, flexible with hardware, software, platform and database independence. === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
