(RADIATOR) ContinueWhileReject: but not for ExpirationDate failures

[Hugh Irvine]

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.