(RADIATOR) vista and radiator

[Hugh Irvine]

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.



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