(RADIATOR) using the class atribute for a special purpose

Ayotunde Itayemi aitayemi at metrong.com
Wed Apr 30 13:52:20 CDT 2003


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.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.open.com.au/pipermail/radiator/attachments/20030430/c4a31335/attachment.html>


More information about the radiator mailing list