Difference between local and external in inner-tunnel
o/ 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? Best regards, Alberto
Hi,
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?
you can add an attribute (and local one you want) to the request/reply in the inner-tunnel and then see that request in the outer tunnel - so local users can be seen/verified via that local internal attribute as remote auths wouldnt have that attribute alan
On Fri, Jun 15, 2012 at 11:48:56AM +0200, Alberto Martínez wrote:
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?
In some way, that depends on what attributes you have available in the requests to check. Packet-Src-Ip-Address is one way. Or set huntgroups for your own NASes (NAS-IP-Address, etc), then just check for membership of the huntgroup. Just rememeber Packet-Src-Ip-Address can't easily be spoofed, whereas attributed in the incoming packet can be. Matthew -- Matthew Newton, Ph.D. <mcn4@le.ac.uk> Systems Architect (UNIX and Networks), Network Services, I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom For IT help contact helpdesk extn. 2253, <ithelp@le.ac.uk>
Hi,
Packet-Src-Ip-Address is one way. Or set huntgroups for your own NASes (NAS-IP-Address, etc), then just check for membership of the huntgroup.
NAS-IP-Address - dangerous....its something that can clash with remote sites - as its local specific - and therefore the IP addresses used might be the same. alan
I guess I could just use "NAS-Identifier" plus "NAS-IP-Address" and carry on, because I can't see anywhere that Packet-Src-Ip-Address from our NASes. We have just 2 NASes, so I'll skip the huntgroups. Thanks for your answers! 2012/6/15 alan buxey <A.L.M.Buxey@lboro.ac.uk>
Hi,
Packet-Src-Ip-Address is one way. Or set huntgroups for your own NASes (NAS-IP-Address, etc), then just check for membership of the huntgroup.
NAS-IP-Address - dangerous....its something that can clash with remote sites - as its local specific - and therefore the IP addresses used might be the same.
alan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Alberto Martínez wrote:
I guess I could just use "NAS-Identifier" plus "NAS-IP-Address" and carry on, because I can't see anywhere that Packet-Src-Ip-Address from our NASes. We have just 2 NASes, so I'll skip the huntgroups.
Use Packet-Src-IP-Address. It's the source IP of the RADIUS packet. It doesn't show up in the debug output for various reasons. But you can use it. Alan DeKok.
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
participants (5)
-
alan buxey -
Alan DeKok -
Alberto Martínez -
Bob Franklin -
Matthew Newton