(RADIATOR) PAP authentication amidst various EAP types

[Hugh Irvine]

Hello Peter -

Another way to do this is as follows:


========================================================

<Handler TunnelledByPEAP=1>
RewriteUsername       s/^([^@]+).*/$1/
AuthBy TestUP (Novell eDirectory passwords)
</Handler>

<Handler TunnelledByTTLS=1>
RewriteUsername       s/^([^@]+).*/$1/
AuthBy TestUP (Novell again)
</Handler>

<Handler realm=lshtm.ac.uk, EAP-Message = /.+/>
# Realm is explicitly set in request, or outer identity of EAP client
AuthBy TUNNEL
</Handler>

<Handler realm=lshtm.ac.uk>
# this Handler will process non-EAP requests
AuthBy WHATEVER
</Handler>

<Handler Realm= >
# Null/empty realm, presumably a local user
AuthBy TUNNEL
</Handler>

<Handler>
# Send everything else remotely
AuthBy RADIUS ...
</Handler>

# TUNNEL AuthBy
<AuthBy FILE>
Identifier TUNNEL
EAPType PEAP,TTLS
<snip assorted certificate configuration>
EAPAnonymous %0
</AuthBy>

# non-EAP AuthBy
<AuthBy ....>
Identifier WHATEVER
.....
</AuthBy>


========================================================


Please let me know if this works for you.

regards

Hugh


On 31 Jan 2007, at 05:07, Peter Bates wrote:

>
> Hello all...
>
>> On 30/01/07 at 06:45, Hugh Irvine <hugh at open.com.au> wrote:
>
>> Your default Handler can do something like this:
>>
>>
>> <Handler>
>>
>> 	AuthByPolicy ContinueUntilAccept
> <snip>
>> </Handler>
>
> I've tried this, but it doesn't really solve the problem.
>
> Basically, I have clients who might be a) using PAP authentication  
> via a Web redirect platform
> or mostly b) clients using EAP/PEAP or EAP/TTLS. It would be nice  
> to support a), the support for b) is working fine.
>
> In addition I have other potential clients (with non-local realms)
> who are authenticated remotely via proxying/chaining to another  
> RADIUS server.
>
> ========================================================
>
> <Handler realm=lshtm.ac.uk>
> # Realm is explicitly set in request, or outer identity of EAP client
> AuthBy TUNNEL
> </Handler>
>
> <Handler Realm= >
> # Null/empty realm, presumably a local user
> AuthBy TUNNEL
> </Handler>
>
> <Handler>
> # Send everything else remotely
> AuthBy RADIUS ...
> </Handler>
>
> # TUNNEL AuthBy
> <AuthBy FILE>
> Identifier TUNNEL
> EAPType PEAP,TTLS
> <snip assorted certificate configuration>
> EAPAnonymous %0
> </AuthBy>
>
> <Handler TunnelledByPEAP=1>
> RewriteUsername       s/^([^@]+).*/$1/
> AuthBy TestUP (Novell eDirectory passwords)
> </Handler>
>
> <Handler TunnelledByTTLS=1>
> RewriteUsername       s/^([^@]+).*/$1/
> AuthBy TestUP (Novell again)
> </Handler>
>
> ========================================================
>
> The EAP stuff is fine.
> A PAP request however coming in (from a fixed group of clients,  
> admittedly)
> matches on the <Handler realm=lshtm.ac.uk> or <Handler realm= >
> and then gets sent down the tunnel, presumed to be an EAP request.
>
> I can use 'AuthByPolicy ContinueUntilAccept'
> and do
>
> AuthBy TUNNEL
> AuthBy TestUP
>
> but then one or the other breaks.
>
> I can uniquely identify the clients the requests might come from,
> but then their requests might be EAP, or might be PAP.
>
> I thought I might be able to do 'Client-Identifier=x,  
> Realm=lshtm.ac.uk, TunnelledByTTLS=0, TunnelledByPEAP=0'
> but of course that isn't the case with those requests.
>
> At the end of the day it's not crucial because the PAP support is  
> for backwards compatibility
> with sites running Web Redirect portals for access to their network  
> (rather than 802.1x)
> but it might be nice to be able to support it, or work out where my  
> convoluted configuration is going wrong!
>
> ...
>
>
> -- 
>
> ---------------------------------------------------------------------- 
> ----------------------------->
> Peter Bates, Systems Support Officer, IT Services.
> London School of Hygiene & Tropical Medicine.
> Telephone:0207-958 8353 / Fax: 0207- 636 9838
>
>
> --
> 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 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.
Includes support for reliable RADIUS transport (RadSec),
and DIAMETER translation agent.
-
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.