(RADIATOR) using the class atribute for a special purpose
Hugh Irvine
hugh at open.com.au
Wed Apr 30 17:09:09 CDT 2003
Hello Tunde -
You should have a look at a trace 4 debug to see what attributes are
actually present in the request. I suspect there is no NAS-IP-Address
in the packet which is why you are not finding anything.
regards
Hugh
On Thursday, May 1, 2003, at 04:52 Australia/Melbourne, Ayotunde
Itayemi wrote:
>
> Hi Hugh,
>
> Please I am actually in a hurry at the moment but I will explain
> everything and possibly offer a new
> AuthBY to the list - (AuthNASIPPOOLS.pm :-)
>
> My main problem now is that I can seem to be able to retrieve the NAS
> IP address from the authby.
> I based the authby on the generic XYZ file that comes with radiator.
>
> I have tried $p->getAttrByNum($Radius::Radius::NAS_IP_ADDRESS)
> and $p->get_attr('NAS-IP-Address') but neither returned anything.
>
>
> Well, I also
> tried $self->getAttrByNum($Radius::Radius::NAS_IP_ADDRESS) by the way!
>
> Please help - I need to retrieve the NAS-IP-Address. Hope to hear
> from you soon.
>
> Regards,
> Tunde Itayemi.
>
>
> Some relevant parts of the AuthBY module:
>
> #=================================================================
>
> %Radius::AuthGeneric::ConfigKeywords =
> ('NASIPsAndPoolHints' => 'string',
> );
> sub initialize
> {
> my ($self) = @_;
> $self->SUPER::initialize;
> $self->{NASIPsAndPoolHints} = '';
> }
>
> sub handle_request
> {
> my ($self, $p, $dummy, $extra_checks) = @_;
>
>
>
> ----- Original Message -----
> From: Hugh Irvine
> To: Ayotunde Itayemi
> Cc: radiator at open.com.au
> Sent: Tuesday, April 29, 2003 4:47 AM
> Subject: Re: (RADIATOR) using the class atribute for a special purpose
>
>
> Hello Tunde -
>
> I am afraid I don't quite understand what you are trying to do.
>
> It seems logically inconsistent to me that you are allowing calls for
> users you don't want to connect?
>
> Perhaps if you give me a more detailed description of your
> requirements I will be able to help.
>
> regards
>
> Hugh
>
>
> On Monday, Apr 28, 2003, at 21:21 Australia/Melbourne, Ayotunde
> Itayemi wrote:
>
> Hi Hugh, Hi All,
>
> Ok. It seems that approach won't work then. I was hoping
> radiator would do a check on the Class field before selecting
> an Handler and thus match it to the Handler Class="EmailOnly".
>
> My (new) idea is something like this:
>
> Given the following scenario:
> the 18002 access number is connected to a group of NASes. If the
> user trying to connect has the Class attribute set to "emailonly",
> REJECT (deny) the connection attempt with the <AuthBy
> EmailNoAccessauth>
> otherwise allow access i.e., return accept so that the other AuthBys
> may
> be considered. All other access requests (on other numbers) fall
> naturally to <Handler Client-Identifier=mypattonrases>.
>
> Please I need the code to implement the <AuthBy EmailNoAccessauth>
> given that Class = "emailonly" is set in the replyattr field of the
> "emailonly" user records - which would have been retrieved via
> <AuthBy SQLClientauth> - that is why I put <AuthBy SQLClientauth>
> before
> <AuthBy EmailNoAccessauth>
> Of course if anyone reads this mail before Hugh does and you can
> provide
> me with the code for the <AuthBy EmailNoAccessauth> please go right
> ahead :-)
>
> Thanks.
> Tunde Itayemi.
>
> ===============================================================
>
> <AuthBy EmailNoAccessauth>
> if Class = "emailonly" return REJECT
> </AuthBy>
>
> <Handler Called-Station-Id="18002">
> AuthByPolicy ContinueUntilReject
> RewriteUsername s/^([^@]+).*/$1/
> RewriteUsername tr/A-Z/a-z/
> UsernameCharset a-zA-Z0-9\._ at -
> AcctLogFileName %L/account.log
> PasswordLogFileName %L/password.log
> SessionDatabase SDB1
> AuthBy SQLClientauth
> AuthBy EmailNoAccessauth
> AuthBy pattonIPADDRESSauth
> AuthBy ACCESSAccountingStart
> AuthBy ACCESSAccountingStop
> </Handler>
>
> <Handler Client-Identifier=mypattonrases>
> # AuthByPolicy ContinueUntilReject
> RewriteUsername s/^([^@]+).*/$1/
> RewriteUsername tr/A-Z/a-z/
> UsernameCharset a-zA-Z0-9\._ at -
> AcctLogFileName %L/account.log
> PasswordLogFileName %L/password.log
> SessionDatabase SDB1
> AuthBy SQLClientauth
> AuthBy pattonIPADDRESSauth
> AuthBy ACCESSAccountingStart
> AuthBy ACCESSAccountingStop
> </Handler>
>
> ----- Original Message -----
> From: Hugh Irvine
> To: Ayotunde Itayemi
> Cc: radiator at open.com.au
> Sent: Friday, April 25, 2003 10:54 PM
> Subject: Re: (RADIATOR) using the class atribute for a special purpose
>
>
> Hello Tunde -
>
> The Class attribute is added to an access accept that is returned to
> the NAS and it will be included in all subsequent accounting requests
> from the NAS for the session.
>
> There will never be a Class attribute in an access request.
>
> The Called-Station-Id can be matched either on the exact string or on
> a regular expression. Regular expressions are delimited by "/.../".
> Check the Radiator reference manual and your Perl book for details.
>
> regards
>
> Hugh
>
>
> On Friday, Apr 25, 2003, at 23:07 Australia/Melbourne, Ayotunde
> Itayemi wrote:
>
> Hi Hugh,
>
> Still no luck. I noticed from the (attached) trace 4 debug log that
> the authentication request
> somehow skips the Class="EmailOnly" Handler and ends up being
> authenticated by the
> next handler (Client-Identifier=pattonrases) - please see attached
> radius.cfg
> The strange thing is that the accounting requests are then handled by
> the (correct) Handler !?
>
> I hope to hear from you soon.
> Please note that I have tried both
> Class="EmailOnly", Called-Station-Id=/15000/
> and
> Class="EmailOnly", Called-Station-Id="15000"
> Which is actually the correct way of specifying the the
> Called-Station-id by the way
>
> Regards,
> Tunde I.
>
>
> ----- Original Message -----
> From: Hugh Irvine
> To: Ayotunde Itayemi
> Cc: radiator at open.com.au
> Sent: Friday, April 25, 2003 12:42 AM
> Subject: Re: (RADIATOR) using the class atribute for a special purpose
>
>
> Hello Tunde -
>
> Yes this the correct approach and this is what the Class attribute is
> designed for.
>
> You will find quite a bit of discussion on the Class attribute on the
> mailing list archive.
>
> www.open.com.au/archives/radiator
>
> regards
>
> Hugh
>
>
> On Friday, Apr 25, 2003, at 05:52 Australia/Melbourne, Ayotunde
> Itayemi wrote:
>
> Hi All, Hi Hugh,
>
> I need a special variable that I can set in a particular group of
> users (email-only) records in my
> user database (an oracle table). Can I use the class atribute?
>
> I was thinking of something along the line of:
>
> Replyattr = ' Framed-Protocol = PPP,Session-Timeout="until Time",
> Class="Email-Only"'
>
>
> Then in the Handler section of my radiator config file:
>
> <Handler Class="Email-Only", Called-Station-Id=2001024>
> .... do something ...
> </Handler>
>
> .... other handlers ...
>
> The idea is to process this group of users specially before the
> general users who connect to
> the same set of NASes. Also I won't set the Class attribute for my
> other class(es) of users.
>
> Do you think this will work? Do I lose anything by using the class
> attribute this way? Thanks.
>
> Regards,
> Tunde Itayemi.
>
>
>
> NB: have you included a copy of your configuration file (no secrets),
> together with a trace 4 debug showing what is happening?
>
> --
> 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.
>
> <logfile.txt><radius.cfg>
>
>
> NB: have you included a copy of your configuration file (no secrets),
> together with a trace 4 debug showing what is happening?
>
> --
> 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.
>
>
>
> NB: have you included a copy of your configuration file (no secrets),
> together with a trace 4 debug showing what is happening?
>
> --
> 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.
>
>
NB: have you included a copy of your configuration file (no secrets),
together with a trace 4 debug showing what is happening?
--
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/enriched
Size: 9442 bytes
Desc: not available
URL: <http://www.open.com.au/pipermail/radiator/attachments/20030501/4e88a25c/attachment.bin>
More information about the radiator
mailing list