(RADIATOR) using the class atribute for a special purpose

Ayotunde Itayemi aitayemi at metrong.com
Fri May 2 06:32:08 CDT 2003


Hi Hugh, Hi All,

Here is an explanation of what I was trying to do.

A client has a set of patton RASes connected to a number of e1s to which the phone numbers are 
in a hunt group. The client wanted email-only clients to be able to call ONLY one particular phone
number in the hunt group and to be denied access if they call the main hunt number say 18002

In the process I came up with the AuthNASIPPOOLS.pm which actually solves a long standing
problem I had - desciption.

I have a set of patton RASES at different locations that normally hand out public-ips to clients.
Later I wanted email-only clients to be able to dial any of those pattons and get private-ips.
This wasn't possible with the standard method of adding a particular poolhint attribute to the
email-only-user database record. I needed to be able to dynamically assign a poolhint attribute
to a reply to an access-request-reply packet based on the NAS that the email-only client
connects to.

Pls find attached the AuthNASIPPOOLS.pm

BTW, for the particular client I mentioned earlier I wrote a little AuthBY that sends back a REJECT
if the client has the class attribute set to "emailonly". I then call this AuthBy from the Handler for 
calls to the hunt number.

Regards,
Tunde Itayemi.


sample radius.cfg file (usage)

<AddressAllocator SQL>
        Identifier mySQLallocator
        DBSource
        DBUsername
        DBAuth
        <AddressPool mypool1>
                Range 192.168.60.1 192.168.60.10
        </AddressPool>
        <AddressPool mypool2>
                Range 192.168.65.1 192.168.65.10
        </AddressPool>
        <AddressPool mypool3>
                Range 192.168.70.1 192.168.70.10
        </AddressPool>
</AddressAllocator>

<AuthBy DYNADDRESS>
        Identifier pattonIPADDRESSauth
        Allocator mySQLallocator
        MapAttribute   yiaddr, Framed-IP-Address
        MapAttribute   subnetmask, Framed-IP-Netmask
        StripFromReply PoolHint
        DefaultSimultaneousUse 1
</AuthBy>

<AuthBy NASIPPOOLS>
        Identifier ippools
        NASIPsAndPoolHints 212.192.142.8 mypool1 212.192.142.18 mypool2 \
                                        217.193.140.41 mypool3 17.194.145.20 mypool4
</AuthBy>
 
<Handler Called-Station-Id=/18002/>
 AuthByPolicy ContinueUntilReject
        RewriteUsername s/^([^@]+).*/$1/
        RewriteUsername tr/A-Z/a-z/
        UsernameCharset a-zA-Z0-9\._ at -
        RejectHasReason
        AcctLogFileName         %L/account.log
        PasswordLogFileName     %L/password.log
        SessionDatabase SDB1
        AuthBy SQLClientauth
        AuthBy ippools
        AuthBy pattonIPADDRESSauth
        AuthBy ACCESSAccountingStart
        AuthBy ACCESSAccountingStop
</Handler>


  ----- Original Message ----- 
  From: Hugh Irvine 
  To: Ayotunde Itayemi 
  Cc: radiator at open.com.au 
  Sent: Wednesday, April 30, 2003 11:09 PM
  Subject: Re: (RADIATOR) using the class atribute for a special purpose



  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 --------------
An HTML attachment was scrubbed...
URL: <http://www.open.com.au/pipermail/radiator/attachments/20030502/7ab59575/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: AuthNASIPPOOLS.pm
Type: application/octet-stream
Size: 2899 bytes
Desc: not available
URL: <http://www.open.com.au/pipermail/radiator/attachments/20030502/7ab59575/attachment.obj>


More information about the radiator mailing list