(RADIATOR) AuthByPolicy ContinueUntilAccept problems

[Hugh Irvine]

Hello Robin -

What I tend to do in my consulting practice for complex requirements  
like this is use an AuthBy INTERNAL with a hook, and select the  
appropriate AuthBy clause in the hook code.

I don't know whether this will work in your case, but you can try it.  
There are numerous example hooks showing how to do various things in  
"goodies/hooks.txt".

Something like this:


# define AuthBy clauses

<AuthBy ....>
	Identifier MethodA
	.....
</AuthBy>

<AuthBy ....>
	Identifier MethodB
	.....
</AuthBy>

<AuthBy ....>
	Identifier MethodC
	.....
</AuthBy>

.....

<Handler TunnelledByPEAP = 1>
	<AuthBy INTERNAL>
		RequestHook file:"%D/chooseAuthBy.pl"
	</AuthBy>
</Handler>

<Handler TunnelledByTTLS = 1>
	<AuthBy INTERNAL>
		RequestHook file:"%D/chooseAuthBy.pl"
	</AuthBy>
</Handler>

<Handler>
	.....
</Handler>


Please let me know how you get on.

regards

Hugh



On 27 May 2006, at 20:03, Robin Breathe wrote:

> On 27 May 2006, at 05:49, Hugh Irvine wrote:
>> Why not do the Realm check in the Handlers?
>
> We need to authenticate users based upon the outer-realm and the  
> inner-username. The problem becomes passing the outer-realm to the  
> TunnelledBy.... Handler. In the EAP case, we can use "EAPAnonymous  
> anonymous@%R" in AuthBy TUNNEL and follow your suggestion (this is  
> what we did initially). Unfortunately this breaks down with non-EAP  
> inner authentication methods (e.g. TTLS/MSCHAPv2), thus my somewhat  
> convoluted attempt at choosing an appropriate AuthBy via a sequence  
> of AuthBy GROUP and INTERNAL clauses.
> We need to pick the inner handler based upon the outer Realm.
>
>> <Handler Realm = cis.brookes.ac.uk, TunnelledByPEAP=1>
>>     ....
>> </Handler>
>>
>> <Handler Realm = cis.brookes.ac.uk, TunnelledByTTLS=1>
>>     ....
>> </Handler>
>>
>> <Handler>
>>     AuthByPolicy ContinueWhileAccept
>>     AuthBy TUNNEL
>>     AuthBy AUTHORIZE
>>     StripFromReply Inner-User,Inner-Realm,Outer-User,Outer-Realm
>> </Handler>
>
>> I'm afraid I don't understand what exactly you are wanting to do  
>> so it makes it a bit hard to make sensible suggestions.
>
> I can appreciate that :)
> The crux of the issue is this section:
>
>>> <AuthBy GROUP>
>>>     Identifier AUTHENTICATE
>>>     AuthByPolicy ContinueUntilAccept
>>>     AuthBy AUTH-CIS
>>>     AuthBy AUTH-DEFAULT
>>> </AuthBy>
>
> We don't want the AUTH-DEFAULT AuthBy to be called unless AUTH-CIS  
> returns something other than Access-Accept. In the non-EAP case,  
> the logic works perfectly. But in the EAP case, both initiate  
> MSCHAP-V2 challenges, and AUTH-DEFAULT runs even after AUTH-CIS has  
> returned Access-Accept - seemingly violating the  
> "ContinueUntilAccept" logic.
>
> Is there a hook we could use to modify the User-Name in the inner  
> request before it reaches the "Realm=...,TunnelledBy...." Handlers,  
> while leaving the original request untouched?
>
> Best regards,
> Robin
> --
> Robin Breathe, Computer Services, Oxford Brookes University,  
> Oxford, UK
> rbreathe at brookes.ac.uk                          Tel: +44 (0)1865  
> 483685
>
>


NB:

Have you read the reference manual ("doc/ref.html")?
Have you searched the mailing list archive (www.open.com.au/archives/ 
radiator)?
Have you had a quick look on Google (www.google.com)?
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.