(RADIATOR) ContinueWhileReject: but not for ExpirationDate failures

[Hugh Irvine]

Hi Dave -

You are quite correct - I had neglected to consider all the 
possibilities.

_sigh_

Unfortunately there isn't anything that can be done.

regards

Hugh


On 28 Aug 2004, at 00:49, Dave Kitabjian wrote:

> Thanks for this interesting idea...
>
> However, I'm not seeing how it would accomplish my goal :-\
>
> No matter how I rearrange the logic, Radiator can only ever send back
> the final state, whether Accept, Reject, or Ignore, right? To get the
> "Expiration date has passed" message where applicable, then, I must
> always stop after that AuthBy, or else the Reason will get lost.
>
> Thinking through the various scenarios, here's what the
> ContinueWhileAccept + AcceptIfMissing idea buys me:
>
> 1. A Group 1 user who has Expired will now begin to reject right away
> (rather than failing over to Group 2), fixing the original problem.
>
> 2. Group 2 users who don't exist in Group 1 will continue to work
> perfectly.
>
> 3. Group 2 users who do exist in Group 1 will now cease to work if only
> their Password is wrong; they will now be instantly rejected at Group
> 1's AuthBy.
>
> 4. Conversely, a Group 1 user who types a GOOD password will now roll
> into Group 2 (because he was Accepted) and then fail there!
>
> In short, the problem is that AcceptIfMissing is too narrow. It needs 
> to
> also have AcceptIfMissingOrBadPassword. In fact, that would fit the
> Radiator methodology properly, contrary to my suggestions below of
> ContinueWhileRejectIfBadPasswordOrNoUser and
> ContinueWhileRejectUnlessPastExpirationDate. Perhaps that could be an
> easy implementation?
>
> Am I missing something? That would be entirely possible  :)
>
>
> Dave
>
>> -----Original Message-----
>> From: Hugh Irvine [mailto:hugh at open.com.au]
>> Sent: Wednesday, August 25, 2004 10:04 PM
>> To: Dave Kitabjian
>> Cc: radiator at open.com.au
>> Subject: Re: (RADIATOR) ContinueWhileReject: but not for
> ExpirationDate
>> failures
>>
>>
>> Hello Dave -
>>
>> A more generally useful approach would be something like this:
>>
>> # define Realm or Handler
>>
>> <Handler ....>
>>
>> 	AuthByPolicy ContinueWhileAccept
>>
>> 	<AuthBy ...>
>> 		.....
>> 		AcceptIfMissing
>> 		NoDefault
>> 		.....
>> 	</AuthBy>
>>
>> 	<AuthBy ....>
>> 		.....
>> 	</AuthBy>
>>
>> </Handler>
>>
>>
>> The above of course assumes that you are not using DEFAULT entries in
>> your AuthBy clauses.
>>
>> Please let me know how you get on.
>>
>> regards
>>
>> Hugh
>>
>>
>>
>> On 26 Aug 2004, at 01:01, Dave Kitabjian wrote:
>>
>>> Hello!
>>>
>>> We have a "ContinueWhileReject" AuthByPolicy setup in place. We have
>>> it set up because we have two groups of users with an overlapping
> set
>>> of login names. But we assume they won't also have matching
> passwords,
>>> so the system should work fine, as it has for a couple years now.
>>>
>>> However, we also collect the Reject Reason for our techs to debug
>>> with. And the problem we just noticed is that if someone fails the
>>> first AUTH because of Expiration Date failure, it still fails over
> to
>>> the next AUTH. This in itself isn't really a problem because they
> will
>>> almost certainly fail this second AUTH, too. But the Reject Reason
>>> that goes back is the one from the LAST AUTH, which will be "no such
>>> user" or "bad password" where the real reason they failed was
> because
>>> the first AUTH had "Expiration date has passed".
>>>
>>> Still with me?
>>>
>>> So it would be nice if we could have something like an AuthByPolicy
> of:
>>>
>>> ContinueWhileRejectIfBadPasswordOrNoUser
>>>
>>> or conversely
>>>
>>> ContinueWhileRejectUnlessPastExpirationDate
>>>
>>> That way it doesn't unnecessarily look for a match in the second
> AUTH
>>> and it preserves the reason for rejection. I'm assuming, of course,
>>> that Radiator doesn't check the Exp Date until both the Login and
>>> Password check out successfully.
>>>
>>> Is there a way to do this without jumping through lots of hoops?
>>> Anyone else think this is a good idea?
>>>
>>> Thanks!
>>>
>>> Dave
>>>
>>>
>>
>> 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, MacOS X.
>> -
>> Nets: internetwork inventory and management - graphical, extensible,
>> flexible with hardware, software, platform and database independence.
>> -
>> CATool: Private Certificate Authority for Unix and Unix-like systems.
>>
>> --
>> 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: 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, MacOS X.
-
Nets: internetwork inventory and management - graphical, extensible,
flexible with hardware, software, platform and database independence.
-
CATool: Private Certificate Authority for Unix and Unix-like systems.

--
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.