Difference between local and external in inner-tunnel

[Bob Franklin]

On Fri, 15 Jun 2012, Alberto Martínez wrote:

> Our FR is doing EAP most of the time, and it's working fine. However, we 
> would want our NAS to see the inner true User-Name, not the outer one. I 
> know this can be set in the inner-tunnel post-auth section uncommenting 
> the update outer.reply lines, but that exposes our users' inner 
> User-Name to proxied-to-us authentications.
>
> So my question is: Which attributes should I check to tell apart local 
> and external auths?

We do exactly this and use Client-Shortname to control whether the inner 
username is revealed: we set Client-Shortname to be in the format 
'<server>@<domain>' - so we might have 'radius0 at botolphs.cam.ac.uk' for 
server 'radius0.botolphs.cam.ac.uk', or 'roaming0 at ja.net' for 
'roaming0.ja.net'.  This attribute is under our control with how we 
configure things in clients.conf, so we can ensure it isn't something 
bogus.

We can then parse this with a regexp such as:

   if ("%{Client-Shortname}" =~ /\.cam\.ac\.uk$/) {
     # client is inside Cambridge - reveal the ID
     update reply {
       User-Name := "..."
     }
   } else {
     # client is not - set it back to the requested one (see note below)
     update reply {
       User-Name := "%{request:User-Name}"
     }
   }

We do various other tricks with this - e.g. set Operator-Name depending on 
the college or department which forwards requests to us (since we act as a 
proxy to various groups inside the University, before passing things up to 
the UK national eduroam proxy service).


Incidentally, on this matter, when I try and enable the relevant bit in 
inner-tunnel, post-auth - uncommenting:

   	#update outer.reply {
 	#	User-Name = "%{request:User-Name}"
 	#}

... I get a weird error when handling logins about the User-Name not 
matching (I haven't tried recently and haven't got something to test on). 
Instead, I use 'use_tunneled_reply = yes' in eap.conf and then use the 
above test in the default, post-auth section to reset it to something 
anonymous, if the client is outside Cambridge.

I've never got to the bottom of why this is - I did search the archives 
and found other people with the same problem but never resolved it.

   - Bob


-- 
  Bob Franklin <rcf34 at cam.ac.uk>              +44 1223 748479
  Network Division, University of Cambridge Computing Service