(RADIATOR) ContinueWhileReject: but not for ExpirationDate failures

[Dave Kitabjian]

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.

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