Re: Difference between local and external in inner-tunnel

15 Jun 2012

      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@botolphs.cam.ac.uk' for 
server 'radius0.botolphs.cam.ac.uk', or 'roaming0@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@cam.ac.uk>              +44 1223 748479
  Network Division, University of Cambridge Computing Service