(RADIATOR) Denying Auth based on Part of a Called-Station-ID
This is what I am trying to do: I need to deny authentication to any number in the 865 area code 'other than' 865-999-. My current configuration does not include any Handler's yet, but this seems to me like a good place for one. Problem is, I want it based on a 'piece' of the Called-Station-ID (area code), and not the whole thing. Basically I just want all subscribers, regardless of realm, not to be able to connect to any other 865 POP but the one number we give them. Please let me know if I am going in the right direction with this, and possibly how to get around the 'part of the Called-Station-ID' issue. Much thanks in advance for the clues! -Mike Walker US Express.net, Inc. === 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) Using SQL statemens inside a PostAuthHook
Hi Hugh,
What happens if I want to use the database connection from somewhere
'outside' the AuthBy? For example, in a PostAuthHook?
I have tried the following:
--
PostAuthHook sub { \
my $p = ${$_[0]}; \
my $rp = ${$_[1]}; \
my $op = ${$_[2]}; \
my $identifier = $p-{Client}-{Identifier}; \
main::log($main::LOG_DEBUG, Using Identifier $identifier); \
}
--
And that didn't work. I have also tried the example in goodies/hooks.txt
file, meaning I have replaced the line:
my $identifier = $p-{Client}-{Identifier}; \
with
my $identifier = Radius::Util::format_special('%{Handler:Identifier}', $op,
$rp);
But that didn't work either. I imagine it doesn't work because it's
outside the 'scope' of the AuthBy block.
Thanks,
bogdan
iCom Media AG
Kirchweg 36
Koln, 50858
Germany
Phone: +49-(0)221-485-689-16
Fax : +49-(0)221-485-689-20
Mobile:+49-(0)173-906-46-01
On Wed, 12 Feb 2003, Hugh Irvine wrote:
Hello Bogdan -
Yes you can use all of the Radiator internal routines on an existing
connection to the database established in an AuthBy SQL clause. You
just need to get a handle to the AuthBy clause (using find()) and use
that handle for your calls.
You will find an example of how to get a handle to an AuthBy clause in
the hook AllocateIPAddressFromProxy in the file goodies/hooks.txt. You
will also find lots of examples of how to use the SQL calls in the code
in the Radius directory.
regards
Hugh
On Tuesday, Feb 11, 2003, at 21:56 Australia/Melbourne, Bogdan TARU
wrote:
Hi everyone,
I have noticed the following phrase in the Radiator documentation:
6.16.14 PostAuthHook:
-skip- PostAuthHook can be an arbitrarily complicated Perl function,
that might run external processes, consult databases, change the
contents
of the current request or many other things. -skip-
My question is how can I consult a database from inside a
PostAuthHook? I
am tring to use the same SQL database as the one configured in AuthBy
SQL. So, do I have to connect once again using perl functions, or can
I
somehow 're-use' the existing SQL connection to make some queries?
Could I get some examples of how to do this? I have already checked
the
'hooks.txt' file, but no database examples are there.
Thank you,
bogdan
iCom Media AG
Kirchweg 36
Koln, 50858
Germany
Phone: +49-(0)221-485-689-16
Fax : +49-(0)221-485-689-20
Mobile:+49-(0)173-906-46-01
===
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) Duplicate kinda requests
Title: RE: (RADIATOR) Duplicate kinda requests If you don't want to use a 'trapped' IP, consider giving them (say) 127.3.3.3, or something else on the loopback range ... dunno if the NAS etc. will accept it, but if they will your user will be sandboxed onto sending pakcets loopbacj, so they won't even be sending out onto your network (note - this is an idea, not a recommendation; YMMV) -Original Message- From: Hugh Irvine [mailto:[EMAIL PROTECTED]] Sent: Wednesday, February 19, 2003 6:22 AM To: Craig Gittens Cc: Radiator Subject: Re: (RADIATOR) Duplicate kinda requests Hello Craig - Unfortunately, just ignoring the request is only likely to make things worse, as your NAS equipment will then mark the radius server as down and then nothing will work (not to mention the retries that will happen as well). I like the trapped IP address idea better. regards Hugh On Wednesday, Feb 19, 2003, at 01:08 Australia/Melbourne, Craig Gittens wrote: I understand but I still think it would make a great feature! Craig. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Monday, February 17, 2003 6:37 PM To: Hugh Irvine Cc: Craig Gittens; Radiator Subject: Re: (RADIATOR) Duplicate kinda requests Why not let them authenticate, but give them an IP that won't get them anywhere but to one web page that says they've been disabled for billing reasons. On Tue, 18 Feb 2003, Hugh Irvine wrote: Hello Craig - I understand the problem - unfortunately there is nothing Radiator can do to rate-limit a mis-behaving client device. Perhaps you could put a filter on one of your routers to drop the bad requests? regards Hugh On Tuesday, Feb 18, 2003, at 01:02 Australia/Melbourne, Craig Gittens wrote: I know Radiator isn't the problem. I just want a way to rate-limit the amount of failed authentication attempts. e.g. If the user/pass fails twice in three seconds = ignore the user request for another x seconds. Is this possible? If not would it be a good idea for a feature? You should see my console it just scrolls by on trace 3 with one username failing 2-3 times a second. Craig. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Hugh Irvine Sent: Sunday, February 16, 2003 5:33 PM To: Craig Gittens Cc: Radiator Subject: Re: (RADIATOR) Duplicate kinda requests Hello Craig - The problem here is that Radiator is not the source of the problem. The correct answer would be to remove power from the ADSL modem. What do you want Radiator to do? regards Hugh On Monday, Feb 17, 2003, at 05:07 Australia/Melbourne, Craig Gittens wrote: I have a problem with ADSL users we authenticate here. They pound the server right now with 2-3 requests every second if their account has expired. How would you handle this? They are not duplicate requests. TIA, Craig. === 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. -- Jon Lewis *[EMAIL PROTECTED]*| I route System Administrator | therefore you are Atlantic Net | _ http://www.lewis.org/~jlewis/pgp for PGP public key_ -- 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
RE: (RADIATOR) AuthBy NT returning IP address
Title: Message I also thought about this idea. Another optioncould beConfinueWhileAccept policy that combines authby NT and authby FILE. I just though maybe someone has realy nice idea how to avoid managing users in two places. Eli Tovbeyn [EMAIL PROTECTED] -Original Message-From: Hugh Irvine [mailto:[EMAIL PROTECTED]] Sent: Wednesday, 19 February, 2003 08:17To: Eli TovbeynCc: [EMAIL PROTECTED]Subject: Re: (RADIATOR) AuthBy NT returning IP address Hello Eli - One way of doing this is with cascaded AuthBy clauses, like this: # define AuthBy clauses AuthBy FILE Identifier CheckUsers Filename %D/users /AuthBy AuthBy NT Identifier CheckNT . /AuthBy # define Realms or Handlers Realm AuthBy CheckUsers . /Realm The "users" file would contain something like this: # users file someuser Auth-Type = CheckNT Framed-IP-Address = n.n.n.n anotheruser Auth-Type = CheckNT Framed-IP-Address = m.m.m.m . You will need to maintain your users in two places however. regards Hugh On Tuesday, Feb 18, 2003, at 23:57 Australia/Melbourne, Eli Tovbeyn wrote: Hi, I'm looking for nice solution for working with AuthBy NT and returning static IP address to every client. I'm working with Radiator 3.5. Any ideas arewelcome. Eli Tovbeyn [EMAIL PROTECTED] -- 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.
(RADIATOR) AuthBy in an Accounting-Request
Given the following: Handler Request-Type = Accounting-Request ... AuthBy LDAP_SERVER_1 /Handler am I correct in assuming that the AuthBy specifier would be completely ignored and irrelevant since no Access-Requests will ever be handled here? Dave === 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) AuthBy in an Accounting-Request
Title: RE: (RADIATOR) AuthBy in an Accounting-Request I believe you still need something to return a packet to register the logging; we just use an AuthBy TEST clause to do so. There may be a cleaner way to do this (since TEST generates a line in the logfile every time); if there is, would someone care to enlighten me? -Original Message- From: Dave Kitabjian [mailto:[EMAIL PROTECTED]] Sent: Wednesday, February 19, 2003 4:43 PM To: [EMAIL PROTECTED] Subject: (RADIATOR) AuthBy in an Accounting-Request Given the following: Handler Request-Type = Accounting-Request ... AuthBy LDAP_SERVER_1 /Handler am I correct in assuming that the AuthBy specifier would be completely ignored and irrelevant since no Access-Requests will ever be handled here? Dave === 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) Using SQL statemens inside a PostAuthHook
Below is an example for you:
Note the example contains some Oracle specifics (bind variables).
hth
Paul
sub {
# OBJECT REF
my $p = ${$_[0]};
my $r = ${$_[1]};
# RETURN VOID
return unless ($p-code() eq 'Access-Request')
(${$_[2]} == $main::ACCEPT);
my $handler = $p-{Handler};
my $identifier = $handler-{SessionDatabase};
main::log($main::LOG_DEBUG, Running PostAuthHook: Using Identifier
$identifier);
my $username=
$p-getAttrByNum($Radius::Radius::USER_NAME);
my $nasaddress =
$p-getAttrByNum($Radius::Radius::NAS_IP_ADDRESS);
my $nasport =
$p-getAttrByNum($Radius::Radius::NAS_PORT);
my $framedipaddress =
$r-getAttrByNum($Radius::Radius::FRAMED_IP_ADDRESS);
$framedipaddress = $r-get_attr('Framed-IP-Address') if
!$framedipaddress;
my $callingstation =
$p-getAttrByNum($Radius::Radius::CALLING_STATION_ID);
my $sess_handle = Radius::SessGeneric::find($identifier);
my $query = undef;
my $rt = $p-{RecvTime};
my $lower = 1000;
my $upper = 200;
my $random = int(rand( $upper-$lower+1 ) ) + $lower;
my $reallyrandom= $random.$rt;
if (defined($framedipaddress) $framedipaddress ne ''
defined($callingstation) $callingstation ne '') {
# prepare
$query = delete from some_db_tbl where .
IP_ADDR= ? or .
MSISDN= ? ;
my $sth = $sess_handle-prepareAndExecute($query,
$framedipaddress, $callingstation);
# prepare
$query = insert into some_db_tbl .
(IP_ADDR, MSISDN, NET_TYPE, DATE_CREATED,
SESSION_ID, ACTIVE, NAS_ID) .
values ( ? , ? , .
'GSMSMS', SYSDATE, $reallyrandom, 'y',
'$nasaddress');
$sth= $sess_handle-prepareAndExecute($query,
$framedipaddress, $callingstation);
} elsif (defined($framedipaddress) $framedipaddress ne ''
!defined($callingstation) || $callingstation eq '' ) {
# prepare
$query = delete from some_db_tbl where .
IP_ADDR= ? ;
my $sth = $sess_handle-prepareAndExecute($query,
$framedipaddress);
} elsif (defined($callingstation) $callingstation ne ''
!defined($framedipaddress) || $framedipaddress eq '' ) {
# prepare
$query = delete from some_db_tbl where .
MSISDN= ? ;
my $sth = $sess_handle-prepareAndExecute($query,
$callingstation);
}
}
- Original Message -
From: Bogdan TARU [EMAIL PROTECTED]
To: Hugh Irvine [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Wednesday, February 19, 2003 10:44 AM
Subject: Re: (RADIATOR) Using SQL statemens inside a PostAuthHook
Hi Hugh,
What happens if I want to use the database connection from somewhere
'outside' the AuthBy? For example, in a PostAuthHook?
I have tried the following:
--
PostAuthHook sub { \
my $p = ${$_[0]}; \
my $rp = ${$_[1]}; \
my $op = ${$_[2]}; \
my $identifier = $p-{Client}-{Identifier}; \
main::log($main::LOG_DEBUG, Using Identifier $identifier); \
}
--
And that didn't work. I have also tried the example in goodies/hooks.txt
file, meaning I have replaced the line:
my $identifier = $p-{Client}-{Identifier}; \
with
my $identifier = Radius::Util::format_special('%{Handler:Identifier}',
$op,
$rp);
But that didn't work either. I imagine it doesn't work because it's
outside the 'scope' of the AuthBy block.
Thanks,
bogdan
iCom Media AG
Kirchweg 36
Koln, 50858
Germany
Phone: +49-(0)221-485-689-16
Fax : +49-(0)221-485-689-20
Mobile:+49-(0)173-906-46-01
On Wed, 12 Feb 2003, Hugh Irvine wrote:
Hello Bogdan -
Yes you can use all of the Radiator internal routines on an existing
connection to the database established in an AuthBy SQL clause. You
just need to get a handle to the AuthBy clause (using find()) and use
that handle for your calls.
You will find an example of how to get a handle to an AuthBy clause in
the hook AllocateIPAddressFromProxy in the file goodies/hooks.txt. You
will also find lots of examples of how to use the SQL calls in the code
in the Radius directory.
regards
Hugh
On Tuesday, Feb 11, 2003, at 21:56 Australia/Melbourne, Bogdan TARU
wrote:
Hi everyone,
I have noticed the following phrase in the Radiator documentation:
6.16.14
RE: (RADIATOR) AuthBy in an Accounting-Request
Title: Message If that's truly all it does in this scenario, I would think that we can get rid of the AuthBy and replace it with: AccountingHandled http://www.open.com.au/radiator/ref.html#pgfId=363868 Am I right? Dave -Original Message-From: Matthew Trout [mailto:[EMAIL PROTECTED]] Sent: Wednesday, February 19, 2003 12:19 PMTo: Dave Kitabjian; [EMAIL PROTECTED]Subject: RE: (RADIATOR) AuthBy in an Accounting-Request I believe you still need something to return a packet to register the logging; we just use an AuthBy TEST clause to do so. There may be a cleaner way to do this (since TEST generates a line in the logfile every time); if there is, would someone care to enlighten me? -Original Message- From: Dave Kitabjian [mailto:[EMAIL PROTECTED]] Sent: Wednesday, February 19, 2003 4:43 PM To: [EMAIL PROTECTED] Subject: (RADIATOR) AuthBy in an Accounting-RequestGiven the following: Handler Request-Type = Accounting-Request ... AuthBy LDAP_SERVER_1 /Handler am I correct in assuming that the AuthBy specifier would be completely ignored and irrelevant since no Access-Requests will ever be handled here? Dave === 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) AuthBy External Reply-Message Duplication
Heya, I've got an AuthBy External block that's running an external program that, if the login fails, returns a Reply-Message indicating why it failed (lowbalance, nouser, etc). Somewhere in the process of sending the response back from radiator to the requesting server, another Reply-Message of Request Denied appears to be being added. Assuming this is correct, how would I get Radiator to supress the second Reply-Message? It's causing problems for the other end, which is getting confused as to which Reply-Message to use, and consequently not displaying reason for failure properly. KevinL -- Senior Consultant Obsidian Consulting Group Phone: +613 9355 7844Fax: +613 9350 4097 http://www.obsidian.com.au/[EMAIL PROTECTED] === 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) AuthBy in an Accounting-Request
Hello Dave, Hello Matthew - Actually Dave's first example will work fine, as all of the standard AuthBy clauses will acknowledge accounting requests even if they do nothing with them. If you do want to have an AuthBy to just do the accounting response (and you do need an AuthBy in any Handler or Realm), then you should use an AuthBy INTERNAL. # define AuthBy clauses AuthBy INTERNAL> Identifier AccountingResponse AcctResult ACCEPT /AuthBy> # define Handlers Handler Request-Type = Accounting-Request> AuthBy AccountingResponse . /Handler> regards Hugh On Thursday, Feb 20, 2003, at 09:06 Australia/Melbourne, Dave Kitabjian wrote: If that's truly all it does in this scenario, I would think that we can get rid of the AuthBy and replace it with: AccountingHandled http://www.open.com.au/radiator/ref.html#pgfId=363868 Am I right? Dave -Original Message- From: Matthew Trout [mailto:[EMAIL PROTECTED]] Sent: Wednesday, February 19, 2003 12:19 PM To: Dave Kitabjian; [EMAIL PROTECTED] Subject: RE: (RADIATOR) AuthBy in an Accounting-Request I believe you still need something to return a packet to register the logging; we just use an AuthBy TEST clause to do so. There may be a cleaner way to do this (since TEST generates a line in the logfile every time); if there is, would someone care to enlighten me? > -Original Message- > From: Dave Kitabjian [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, February 19, 2003 4:43 PM > To: [EMAIL PROTECTED] > Subject: (RADIATOR) AuthBy in an Accounting-Request > > > Given the following: > > Handler Request-Type = Accounting-Request> > > ... > > AuthBy LDAP_SERVER_1 > > /Handler> > > am I correct in assuming that the AuthBy specifier would be completely > ignored and irrelevant since no Access-Requests will ever be handled > here? > > Dave > === > 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) BindAddr problem?
Hello Terry - The problem here is that you are trying to open the same port number twice. When running multiple instances of Radiator you normally have to specify different port numbers for each one. This is because there is only one IP stack and one set of port numbers, even if you have multiple IP addresses. . # define port numbers in first Radiator instance AuthPort 1645 AcctPort 1646 .. # define port numbers in second Radiator instance AuthPort 1812 AcctPort 1813 . You can generally use any unused port numbers you like. regards Hugh On Thursday, Feb 20, 2003, at 02:48 Australia/Melbourne, [EMAIL PROTECTED] wrote: I'm trying to get a second instance of radiator running on a second IP serviced by a particular server. I changed the default servers config so that it BindAddr's to one IP, and the config file for the second specifies another. I restarted the first server, but I'm still getting an already in use . OS is FreeBSD 4.6.2-RELEASE-p5, radiator is 3.3.1. Any thoughts? == /usr/local/etc/radius.cfg == # Radiartor config file for ccis BindAddr209.195.224.6 == /usr/local/etc/radius_ikano.cfg == # Radiartor config file for ikano BindAddr209.195.201.7 === 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) AuthBy NT returning IP address
Hello Eli - The only other thing I can think of is to perhaps look at the AuthBy ADSI module? regards Hugh On Wednesday, Feb 19, 2003, at 22:48 Australia/Melbourne, Eli Tovbeyn wrote: I also thought about this idea. Another option could be ConfinueWhileAccept policy that combines authby NT and authby FILE. I just though maybe someone has realy nice idea how to avoid managing users in two places. Eli Tovbeyn [EMAIL PROTECTED] -Original Message- From: Hugh Irvine [mailto:[EMAIL PROTECTED]] Sent: Wednesday, 19 February, 2003 08:17 To: Eli Tovbeyn Cc: [EMAIL PROTECTED] Subject: Re: (RADIATOR) AuthBy NT returning IP address Hello Eli - One way of doing this is with cascaded AuthBy clauses, like this: # define AuthBy clauses AuthBy FILE> Identifier CheckUsers Filename %D/users /AuthBy> AuthBy NT> Identifier CheckNT . /AuthBy> # define Realms or Handlers Realm > AuthBy CheckUsers . /Realm> The "users" file would contain something like this: # users file someuser Auth-Type = CheckNT Framed-IP-Address = n.n.n.n anotheruser Auth-Type = CheckNT Framed-IP-Address = m.m.m.m . You will need to maintain your users in two places however. regards Hugh On Tuesday, Feb 18, 2003, at 23:57 Australia/Melbourne, Eli Tovbeyn wrote: Hi, I'm looking for nice solution for working with AuthBy NT and returning static IP address to every client. I'm working with Radiator 3.5. Any ideas are welcome. Eli Tovbeyn [EMAIL PROTECTED] -- 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. -- 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) Denying Auth based on Part of a Called-Station-ID
Hello Mike - There are two ways to do this (at least :-)). The first and simplest is to use cascaded AuthBy's. # define AuthBy clauses AuthBy FILE Identifier CheckCalledStationId Filename %D/calledstations /AuthBy AuthBy ... Identifier YourNormalAuthBy . /AuthBy . # define Realms Realm AuthBy CheckCalledStationId /Realm ... The file %D/calledstations would contain this: # calledstations DEFAULT Called-Station-Id = 865999, Auth-Type = YourNormalAuthBy DEFAULT Auth-Type = Reject From your description below I am not sure whether the above will work? I suspect I may need to see your existing configuration file (no secrets) and a bit more detail on exactly what you want to do with the Called-Station-Id's. regards Hugh On Wednesday, Feb 19, 2003, at 20:09 Australia/Melbourne, Mike Walker wrote: This is what I am trying to do: I need to deny authentication to any number in the 865 area code 'other than' 865-999-. My current configuration does not include any Handler's yet, but this seems to me like a good place for one. Problem is, I want it based on a 'piece' of the Called-Station-ID (area code), and not the whole thing. Basically I just want all subscribers, regardless of realm, not to be able to connect to any other 865 POP but the one number we give them. Please let me know if I am going in the right direction with this, and possibly how to get around the 'part of the Called-Station-ID' issue. Much thanks in advance for the clues! -Mike Walker US Express.net, Inc. === 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) AuthBy External Reply-Message Duplication
Hi Kevin - Nice to hear from you. Yes, Radiator adds the Reply-Message when a reject occurs. You can try using a StripFromReply Reply-Message to see which one is removed. You can also try using RejectHasReason in the Realm or Handler. regards Hugh On Thursday, Feb 20, 2003, at 10:08 Australia/Melbourne, KevinL wrote: Heya, I've got an AuthBy External block that's running an external program that, if the login fails, returns a Reply-Message indicating why it failed (lowbalance, nouser, etc). Somewhere in the process of sending the response back from radiator to the requesting server, another Reply-Message of Request Denied appears to be being added. Assuming this is correct, how would I get Radiator to supress the second Reply-Message? It's causing problems for the other end, which is getting confused as to which Reply-Message to use, and consequently not displaying reason for failure properly. KevinL -- Senior Consultant Obsidian Consulting Group Phone: +613 9355 7844Fax: +613 9350 4097 http://www.obsidian.com.au/[EMAIL PROTECTED] === 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) RewriteUser in AuthBy?
I am transitioning a bunch of dialup users from one authserver to another. I want to first check the new AuthBy LDAP2 and then check the old AuthBy RADIUS. My problem is that the LDAP2 directory uses a different username encoding scheme than the legacy server. Is ther a way to RewriteUser inside an AuthBy clause or can I set up two Handlers with the same selection conditions but different RewriteUser statements? Thanks -- Chris Fedde === 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) RewriteUser in AuthBy?
Hello Chris - If you can recognise the different usernames, you can do this: # define Handlers for different cases Handler User-Name = /../ RewriteUsername . AuthBy LDAP2 . /AuthBy /Handler Handler User-Name = /../ RewriteUsername . AuthBy RADIUS /AuthBy /Handler regards Hugh On Thursday, Feb 20, 2003, at 12:14 Australia/Melbourne, Chris Fedde wrote: I am transitioning a bunch of dialup users from one authserver to another. I want to first check the new AuthBy LDAP2 and then check the old AuthBy RADIUS. My problem is that the LDAP2 directory uses a different username encoding scheme than the legacy server. Is ther a way to RewriteUser inside an AuthBy clause or can I set up two Handlers with the same selection conditions but different RewriteUser statements? Thanks -- Chris Fedde === 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) Radwho.cgi won't connect to MySQL
Hello Dave - The error shown below is from the radwho.cgi script telling you that it can't find DBI. You will have to check the differences in the environments between the user that you are using to test Radiator and buildsql, and the user that Apache is running as when it executes a cgi script. Perhaps you have two different versions of Perl running? Perhaps the PATH for Apache is finding Solaris Perl, not ActivePerl. regards Hugh On Thursday, Feb 20, 2003, at 00:20 Australia/Melbourne, Dave Walters wrote: Hi, I'm just setting up Radiator 3.5 (with patches) to connect to MySQL Ver 3.23.51-max for sun-solaris2.8 on sparc. We're using ActivePerl 5.6.1 and have installed DBI 1.32 and we're using DBD-mysqlPP (Pure Perl driver as ActivePerl's DBD-mysql doesn't work!) Radiator itself connects fine, as does buildsql, however radwho.cgi refuses to work and we get the following message in our apache error-log: Can't locate loadable object for module DBI in @INC (@INC contains: /usr/local/ActivePerl-5.6/lib/5.6.1/sun4-solaris-thread-multi /usr/local/ActivePerl-5.6/lib/5.6.1 /usr/local/ActivePerl-5.6/lib/site_perl/5.6.1/sun4-solaris-thread-multi /usr/local/ActivePerl-5.6/lib/site_perl/5.6.1 /usr/local/ActivePerl-5.6/lib/site_perl .) at /usr/local/ActivePerl-5.6/lib/site_perl/5.6.1/sun4-solaris-thread- multi/ DBI.pm line 250 BEGIN failed--compilation aborted at /usr/local/ActivePerl-5.6/lib/site_perl/5.6.1/sun4-solaris-thread- multi/ DBI.pm line 250. Compilation failed in require at /path/to/web/site/htdocs/cgi-bin/radwho.cgi line 217. Any help you can give would be very helpful, Many thanks, Dave Walters === 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.
