(RADIATOR) using the class atribute for a special purpose

[Hugh Irvine]

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 --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/enriched
Size: 7939 bytes
Desc: not available
URL: <http://www.open.com.au/pipermail/radiator/attachments/20030429/f77b7950/attachment.bin>