(RADIATOR) DefaultSimultaneousUse 1 problem

[Hugh Irvine]

Hello Rob -

You are not correct when you say you can't use Handlers.

As mentioned, the problem is with the AuthBy RADIUS clause, which does 
not support DefaultSimultaneousUse.

Depending on what else you are doing, you can either use cascaded 
AuthBy clauses or enclose the AuthBy RADIUS inside an AuthBy GROUP and 
use the DefaultSimultaneousUse inside the AuthBy GROUP.

If you use cascaded AuthBy's, you should do something like this:

# define AuthBy clauses

<AuthBy RADIUS>
	Identifier ForwardToProxy
	.....
</AuthBy>

<AuthBy FILE>
	Identifier CheckSimUse
	Filename %D/users.sim
	DefaultSimultaneousUse 1
</AuthBy>

......

# define Handlers

<Handler ....>
	AuthBy CheckSimUse
	.....
</Handler>


regards

Hugh


On Wednesday, October 2, 2002, at 11:35 AM, Rob Hill wrote:

> On Tue, 2002-10-01 at 16:35, Hugh Irvine wrote:
>>
>> Hello Rob -
>>
>> The problem is not with Realms or Handlers, but rather with the AuthBy
>> RADIUS clause which does not use DefaultSimultaneousUse (the actual
>> code is in Radius/AuthGeneric.pm).
>>
>> Perhaps you could give me a bit more detail on what you want to do?
>>
>> regards
>>
>> Hugh
>>
>
>
> Hi Hugh -
>
> Basically, I want to set a DefaultSimultaneousUse 1 limit for the
> majority of users, while being able to override it on a specific basis,
> with Simultaneous-Use=2 for example.
>
> But all our AuthBy clauses are called from Handlers, so we can't. We
> have to use MaxSessions, which cannot be overridden on a per-user 
> basis.
>
> So in a nutshell, you can only call DefaultSimultaneousUse from a 
> Realm,
> not a Handler, and we only use Handlers ;o)
>
> My original question was 'why is this the case?'
>
> Hope this helps.
>
>
> Regards,
>
> Rob
>
>
>>
>> On Tuesday, October 1, 2002, at 12:45 PM, Rob Hill wrote:
>>
>>>
>>> Hi -
>>>
>>> I've been setting up <SessionsDatabase SQL> and encountered a weird
>>> caveat while doing so - it doesn't seem to be possible to apply
>>> DefaultSimultaneousUse from within an AuthBy which has been called 
>>> by a
>>> Handler.
>>>
>>> The code in AuthGeneric.pm goes as follows (we're using Radiator
>>> 2.18.4):
>>>
>>>
>>>
>>>     # Check the DefaultSimultaneousUse if we did not get a per-user
>>>     # one. Warning, dont do it if we were called by a Handler
>>>     if (!$did_sim_use
>>>         && $self
>>>         && defined $self->{DefaultSimultaneousUse}
>>>         &&
>>> Radius::SessGeneric::find($p->{Handler}->{SessionDatabase})-
>>>> exceeded($self->{DefaultSimultaneousUse}, $username, $p))
>>>     {
>>>         return ($main::REJECT,
>>>                 "DefaultSimultaneousUse of
>>> $self->{DefaultSimultaneousUse}  exceeded");
>>>     }
>>>
>>>
>>> My question is why? We use handles almost exclusively, to 
>>> differenciate
>>> between multiple number ranges and all kinds of funky stuff. We don't
>>> use any Realms (it would work if called from a realm)
>>>
>>> <AuthBy RADIUS>
>>>         Identifier      SPD1
>>>         Secret          xxxxxxxx
>>>
>>>         ### Use sim-use of 1 unless there is a user-specific entry
>>>         ### doesn't work if called by a handler - have to use
>>>         ### MaxSessions instead (in the handler)
>>>         DefaultSimultaneousUse 1
>>>
>>> 	Host xxx.xxx.xxx.xxx
>>>
>>> </AuthBy>
>>>
>>>
>>> So when I call <AuthBy SPD1> from within a handler, the 
>>> SessionDatabase
>>> countQuery is never executed (although the add and delete are).
>>>
>>>
>>> It does work if I set MaxSessions, but we don't want to have to use
>>> MaxSessions, as it can't be overridden by specific Simultaneous-Use
>>> attributes.
>>>
>>>
>>> Regards,
>>>
>>> Rob
>>>
>>> ===
>>> Archive at http://www.open.com.au/archives/radiator/
>>> Announcements on radiator-announce at open.com.au
>>> To unsubscribe, email 'majordomo at open.com.au' with
>>> 'unsubscribe radiator' in the body of the message.
>>>
>>>
>>
>> NB: I am travelling this week, so there may be delays in our
>> correspondence.
>>
>> -- 
>> 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.
> -- 
> +-----------------------------+
>   Rob Hill
>   Systems Manager
>   Dot Communications
>   Tel: (02) 9281 1111 Ext.101
> +-----------------------------+
>
>

NB: I am travelling this week, so there may be delays in our 
correspondence.

-- 
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 radiator-announce at open.com.au
To unsubscribe, email 'majordomo at open.com.au' with
'unsubscribe radiator' in the body of the message.