(RADIATOR) vista and radiator

Alex Sharaz A.Sharaz at hull.ac.uk
Tue Mar 6 04:12:25 CST 2007


Hi Hugh,

o.k. that would work, but the problem is that we are part of the eduroam
service where participating institutions can gain 
network access at a remote site by having their auth request proxied off
to their home institution. In order for this to work, you need to have
access to the realm they've used when authenticating to the network so
that you can proxy off their auth request to the correct place, in our
case UKERNA.

Without having a realm in the outer userid, the only way I can see of
doing this would be to get to the stage where you have access to the
inner tunnel user-id and then proxy off to the appropriate remote
service. I know it's doable because with our radiator service, once
we've stripped off the outer tunnel we proxy off to a steel belted
radius server for the actual auth part.

What we've got is

<Handler Realm="whatever is in the outer userid that we want to match
with">
AuthBy eapauth
</Handler>
....
<AuthBy FILE>
Identifier  eapauth
...
</AuthBy>

....
<Handler ConvertedFromEAPMSCHAPV2=1>
        # Proxy to a non-EAP capable server
        Identifier eap-mschapv2
        <AuthBy RADIUS>
                RewriteUsername s/^([^@]+).*/$1/
                Host <HOST>
                Secret <YES>
                AuthPort 1812
                AcctPort 1813
                LocalAddress %{GlobalVar:myIp}
                StripFromRequest ConvertedFromEAPMSCHAPV2
                ReplyHook file:"%D/gen_wired_vlans_replyhook.pl"
        </AuthBy>
    AuthLog eaplog
    PostAuthHook file:"%D/calling_station_hook_requests.pl"
</Handler>
....
<Handler TunnelledByPEAP=1>
    Identifier peap-mschapv2
    <AuthBy FILE>
    EAPType MSCHAP-V2
    EAP_PEAP_MSCHAP_Convert 1
    </AuthBy>
</Handler>
....
<Handler TunnelledByTTLS=1>
        Identifier ttls
        <AuthBy RADIUS>
                RewriteUsername s/^([^@]+).*/$1/
                Host <HOST>
                Secret <YES>
                AuthPort 1812
                AcctPort 1813
                LocalAddress %{GlobalVar:myIp}
                ReplyHook file:"%D/gen_wired_vlans_replyhook.pl"
        </AuthBy>
        AuthLog eaplog
        PostAuthHook file:"%D/calling_station_hook_requests.pl"
</Handler>

The above works just fine with our 3rd party supplicants thank you.

The bit I'm confused about is if we have to proxy off to another site,
don;t we have to encapsulate everything back into an outer tunnel again?
I guess in the TunnelledByPeap handler we need to do:-

if (userid has realm ="hull.ac.uk") then 
#
# As usual
#
   <AuthBy FILE>
    EAPType MSCHAP-V2
    EAP_PEAP_MSCHAP_Convert 1
    </AuthBy>
else
#
# Proxy off to UKERNA
#
<AuthBy RADIUS>
....
</AuthBy>

And something similar in the TunnelledByTTLS=1 handler

Can we do that?

Alex


-----Original Message-----
From: Hugh Irvine [mailto:hugh at open.com.au] 
Sent: 05 March 2007 21:32
To: Alex Sharaz
Cc: Radiator at open.com.au
Subject: Re: (RADIATOR) vista and radiator


Hello Alex -

Keep in mind that there is a sequence of EAP exchanges back and forth  
that form the "outer" requests prior to the eventual reception of the  
"inner" request. Therefore it is not possible to "see" the "inner"  
request until after all of the "outer" requests have been processed.  
The patch you mention allows you to "see" the original "inner"  
request when processing the fabricated TunnelledBy... request.

What you could do is add a DefaultRealm to your Client definition(s)  
so that usernames without realm suffixes get one added before the  
Handler is selected.


# define Client clauses

<Client ....>
	......
	DefaultRealm hull.ac.uk
</Client>


Please let me know if this works for you.

regards

Hugh


On 6 Mar 2007, at 01:23, Alex Sharaz wrote:

> Chaps,
>
> Got a small problem here.
>
>
>
> Unfortunately it look as if we're going to have to use the vista  
> native dot1x supplicant as there currently doesn't seem to be a  
> commercial offering available that runs on vista.
>
>
>
> At the moment I've got our Radiator boxes set up so that a handler  
> is selected based upon the presence of a ream in the outer userid.  
> In our case, we autrh locally for realm hull.ac.uk, reject for no  
> realm and proxy  any other requests 9i.e. other realms)  to the  
> UKERNA eduroam service.
>
>
>
> This is shown below.
>
>
>
> #
>
> # Outer userid has realm of hull.ac.uk, auth locally
>
> #
>
> <Handler Client-Identifier=/HP*/i, NAS-IP-Address=/150\.237\.34\.*/ 
> i, Realm=/hull\.ac\.uk/i>
>
>    .....
>
> </Handler>
>
> #
>
> # no realm ....
>
> # reject it
>
> #
>
> <Handler Client-Identifier=/HP*/i, NAS-IP-Address=/150\.237\.34\.*/ 
> i, Realm=>
>
> .....
>
> </Handler>
>
> #
>
> # any other realm proxy of to the UKERNA JRS servers
>
> #
>
> <Handler Client-Identifier=/HP*/i, NAS-IP-Address=/150\.237\.34\.*/i>
>
>    .....
>
> </Handler>
>
>
>
>
>
> This works just fine thank you for the Cisco Secure Services Client  
> and the Odyssey client that I've been using for quite some time.
>
>
>
> Looking at the vista native client, it appears that whatever I do  
> the outer userid is always "anonymous" and I can't change it to be  
> anonymous at hull.ac.uk
>
>
>
> Is there any way at the handler level for me to get at the inner  
> userid and realm so that I can do the above for Vista? ( or any  
> client) ?
>
>
>
> I'm currently using  a hook to save and get hold of the inner  
> userid for accounting purposes.
>
>
>
> I vaguely seem to remember that a patch to 3.16 had something in  
> there that allowed you to use a global variable (?) to get at the  
> inner userid. Was that the case?
>
>
>
> Alex
>
>
>
>
>
> **********************************************************************

> *******************
> To view the terms under which this email is distributed, please go  
> to http://www.hull.ac.uk/legal/email_disclaimer.html
> **********************************************************************

> *******************



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.

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: not available
URL: <http://www.open.com.au/pipermail/radiator/attachments/20070306/70f4fcf1/attachment.ksh>


More information about the radiator mailing list