eap_ttls not setting 'FreeRADIUS-Proxied-To'
Hi all, I’m porting our config from v2.2.9 to v3.0.11. The problem I’m experiencing is that the eap_peap submodule does set FreeRADIUS-Proxied-To, but eap_ttls does not. In v2, both submodules did. Unfortunately I’m currently relying on this attribute for tunnelling in one server. Time is limited so I’m sticking with the previous architecture, which looks like this (trimmed down): authorize { split_user_realm choose_eduroam_proxy # reject invalid realm, set Proxy-To-Realm to national federation or do nothing so it goes internally eap_eduroam if (“%{%{FreeRADIUS-Proxied-To}:-}” == 127.0.0.1) { # inner tunnel: ensure user exists in LDAP and is permitted access user_search # includes ldap_central and sets auth-type if appropriate } } authenticate { Auth-Type PAP { pap } Auth-Type MS-CHAP { mschap } Auth-Type ldap_central { ldap_central } eap_eduroam } The result is that PEAP and various non-tunnelled EAPs authenticate correctly, but TTLS never enters the if-block and so no Auth-Type is ever set. Has this behaviour been intentionally changed? There’s no mention of it in https://github.com/FreeRADIUS/freeradius-server/blob/v3.0.x/doc/ChangeLog. If my need isn’t utterly terrible, would it be possible to re-add FreeRADIUS-Proxied-To to eap_ttls? Cheers, David Lord
On Tue, Jan 12, 2016 at 04:35:36AM +0000, David Lord wrote:
The problem I’m experiencing is that the eap_peap submodule does set FreeRADIUS-Proxied-To, but eap_ttls does not. In v2, both submodules did. Unfortunately I’m currently relying on this attribute for tunnelling in one server.
I believe the plan is to scrap FreeRADIUS-Proxied-To, which is a left-over from version 1 which didn't have virtual servers.
authorize { split_user_realm choose_eduroam_proxy # reject invalid realm, set Proxy-To-Realm to national federation or do nothing so it goes internally eap_eduroam if (“%{%{FreeRADIUS-Proxied-To}:-}” == 127.0.0.1) { # inner tunnel: ensure user exists in LDAP and is permitted access user_search # includes ldap_central and sets auth-type if appropriate } }
authenticate { Auth-Type PAP { pap } Auth-Type MS-CHAP { mschap } Auth-Type ldap_central { ldap_central }
eap_eduroam }
Is this your outer or inner virtual server? It looks like you're trying to mix the two.
The result is that PEAP and various non-tunnelled EAPs authenticate correctly, but TTLS never enters the if-block and so no Auth-Type is ever set.
If my need isn’t utterly terrible, would it be possible to re-add FreeRADIUS-Proxied-To to eap_ttls?
I don't understand why you need it. If you have an outer (default) virtual server and an inner-tunnel virtual server, then by definition the inner-tunnel will be local traffic only, so you don't need to check for FreeRADIUS-Proxied-To. Matthew -- Matthew Newton, Ph.D. <mcn4@le.ac.uk> Systems Specialist, Infrastructure Services, I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom For IT help contact helpdesk extn. 2253, <ithelp@le.ac.uk>
On Jan 11, 2016, at 11:35 PM, David Lord <d.lord@its.uq.edu.au> wrote:
I’m porting our config from v2.2.9 to v3.0.11.
The problem I’m experiencing is that the eap_peap submodule does set FreeRADIUS-Proxied-To, but eap_ttls does not.
I've pushed a fix.
In v2, both submodules did. Unfortunately I’m currently relying on this attribute for tunnelling in one server.
You shouldn't need to do that. The "inner-tunnel" virtual server handles inner tunnel data. Nothing else does. You don't need to key off of FreeRADIUS-Proxied-To.
Time is limited so I’m sticking with the previous architecture, which looks like this (trimmed down):
authorize { split_user_realm choose_eduroam_proxy # reject invalid realm, set Proxy-To-Realm to national federation or do nothing so it goes internally eap_eduroam if (“%{%{FreeRADIUS-Proxied-To}:-}” == 127.0.0.1) {
And that is *way* too complicated. In v3, just do: if (&FreeRADIUS-Proxied-To == 127.0.0.1) { But you still don't need to do that. Just put the outer policies into the "default" virtual server, and the inner policies into the "inner-tunnel" virtual server. That's why I created virtual servers: to split the policies like this. That's why the default configuration ships with multiple virtual servers. Alan DeKok.
On 13 Jan 2016, at 12:58 AM, Alan DeKok <aland@deployingradius.com<mailto:aland@deployingradius.com>> wrote: On Jan 11, 2016, at 11:35 PM, David Lord <d.lord@its.uq.edu.au<mailto:d.lord@its.uq.edu.au>> wrote: I’m porting our config from v2.2.9 to v3.0.11. The problem I’m experiencing is that the eap_peap submodule does set FreeRADIUS-Proxied-To, but eap_ttls does not. I've pushed a fix. Thanks for that. By the sound of it, we should move away from using it (as is now documented<https://github.com/FreeRADIUS/freeradius-server/commit/d4ad5e71228b788cac76171156a3d5e5034c48cd>, I note ;) ). In v2, both submodules did. Unfortunately I’m currently relying on this attribute for tunnelling in one server. You shouldn't need to do that. The "inner-tunnel" virtual server handles inner tunnel data. Nothing else does. You don't need to key off of FreeRADIUS-Proxied-To. Time is limited so I’m sticking with the previous architecture, which looks like this (trimmed down): authorize { split_user_realm choose_eduroam_proxy # reject invalid realm, set Proxy-To-Realm to national federation or do nothing so it goes internally eap_eduroam if (“%{%{FreeRADIUS-Proxied-To}:-}” == 127.0.0.1) { And that is *way* too complicated. In v3, just do: if (&FreeRADIUS-Proxied-To == 127.0.0.1) { But you still don't need to do that. Just put the outer policies into the "default" virtual server, and the inner policies into the "inner-tunnel" virtual server. That's why I created virtual servers: to split the policies like this. That's why the default configuration ships with multiple virtual servers. Okay, I’d love to do that. Would appreciate input on this architecture. The other branch of this port uses eduroam_inner, eduroam_IDP and eduroam_SP virtual servers, but I’ve been having trouble getting the right attributes forwarded. In theory IDP is exposed to the national roaming operator and SP is for our campus wifi, and SP forwards auth to IDP or the NRO. Is that sensible? However, SP needs a &Group derived from LDAP to set the right VLAN attributes, which is queried from _inner and can be passed to IDP via outer.control but is harder to forward to SP. I experimented with a custom attr_filter and didn’t find a reliable way to forward the Group attribute (putting it in a temporary attribute and extracting it in SP seems unstable). Alternatively, IDP or _inner can set the VLAN attributes off &Group, and strip them if not replying to SP. It may be worth having just two servers, SP&IDP and inner, and having the SP&IDP server conditionally set VLAN attributes based on the client (one of ours or NRO). This RADIUS service does more than just eduroam, hence the prefixes. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On Jan 12, 2016, at 6:22 PM, David Lord <d.lord@its.uq.edu.au> wrote: ... whatever mail software you're using, please fix it. It mangles quoting so it's almost impossible to tell what's going on.
Okay, I’d love to do that. Would appreciate input on this architecture.
I gave input. Just determine which rules belong in the "default" virtual server, and while ones belong in the "inner-tunnel" virtual server. Then... write the appropriate rules in the correct server.
The other branch of this port uses eduroam_inner, eduroam_IDP and eduroam_SP virtual servers, but I’ve been having trouble getting the right attributes forwarded. In theory IDP is exposed to the national roaming operator and SP is for our campus wifi, and SP forwards auth to IDP or the NRO. Is that sensible?
I have no idea. Please explain using english, and not tons of acronyms.
However, SP needs a &Group derived from LDAP to set the right VLAN attributes, which is queried from _inner and can be passed to IDP via outer.control but is harder to forward to SP. I experimented with a custom attr_filter and didn’t find a reliable way to forward the Group attribute (putting it in a temporary attribute and extracting it in SP seems unstable). Alternatively, IDP or _inner can set the VLAN attributes off &Group, and strip them if not replying to SP.
You're explaining what you want in terms of your current architecture. I don't know your current architecture, so your explanation is content-free. Explain using simple english. Alan DeKok.
On 13 Jan 2016, at 9:37 AM, Alan DeKok <aland@deployingradius.com> wrote:
On Jan 12, 2016, at 6:22 PM, David Lord <d.lord@its.uq.edu.au> wrote:
... whatever mail software you're using, please fix it. It mangles quoting so it's almost impossible to tell what's going on.
Sorry, Apple Mail. Switched to plain text and replies look better in outlook web now. Fixed?
Okay, I’d love to do that. Would appreciate input on this architecture.
I gave input.
Just determine which rules belong in the "default" virtual server, and while ones belong in the "inner-tunnel" virtual server.
Then... write the appropriate rules in the correct server.
The other branch of this port uses eduroam_inner, eduroam_IDP and eduroam_SP virtual servers, but I’ve been having trouble getting the right attributes forwarded. In theory IDP is exposed to the national roaming operator and SP is for our campus wifi, and SP forwards auth to IDP or the NRO. Is that sensible?
I have no idea. Please explain using english, and not tons of acronyms.
Oops, too many eduroam acronyms. I’ve seen Alan Buxey use NRO recently but that was a different mailing list.
However, SP needs a &Group derived from LDAP to set the right VLAN attributes, which is queried from _inner and can be passed to IDP via outer.control but is harder to forward to SP. I experimented with a custom attr_filter and didn’t find a reliable way to forward the Group attribute (putting it in a temporary attribute and extracting it in SP seems unstable). Alternatively, IDP or _inner can set the VLAN attributes off &Group, and strip them if not replying to SP.
You're explaining what you want in terms of your current architecture. I don't know your current architecture, so your explanation is content-free.
Explain using simple english.
Okay, rephrasing: If one virtual server (SP) uses Proxy-To-Realm to forward to a 2nd virtual server (IDP), which uses an eap module with peap & ttls “virtual_server” set to a 3rd virtual server (inner), is there a reliable way to forward attributes from #3 to #1? The reason for having 3 may or may not be good architecture (but here isn’t the place to ask). I might just cut it down to inner and outer, which would make the attribute-forwarding irrelevant. Thanks for your time, Alan and Matthew.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On Jan 12, 2016, at 7:04 PM, David Lord <d.lord@its.uq.edu.au> wrote:
If one virtual server (SP) uses Proxy-To-Realm to forward to a 2nd virtual server (IDP), which uses an eap module with peap & ttls “virtual_server” set to a 3rd virtual server (inner), is there a reliable way to forward attributes from #3 to #1?
use_tunneled_reply in the EAP configuration. Then, the server *already* uses the reply from the proxy as the basis for it's reply to the NAS. i.e. it Just Does The Right Thing. Alan DeKok.
Sorry, Apple Mail. Switched to plain text and replies look better in outlook web now. Fixed?
Yes.
The reason for having 3 may or may not be good architecture (but here isn’t the place to ask). I might just cut it down to inner and outer, which would make the attribute-forwarding irrelevant.
Yes. That's the most straight-forward. If you want to restrict some attributes to on-campus only, look at the virtual attributes that describe the client that connects to your server... if it's the national proxy, you don't ship some attributes (because you know they won't be needed there). Whether you key off the national proxy's client info, or whether you key off the info of your own home NAS client info, doesn't really matter, as long as it is easily maintained by yourself (or your successor). :-) Stefan Paetow Moonshot Industry & Research Liaison Coordinator t: +44 (0)1235 822 125 gpg: 0x3FCE5142 xmpp: stefanp@jabber.dev.ja.net skype: stefan.paetow.janet jisc.ac.uk Networkshop44, University of Manchester. Save the date: 22-24 March, 2016. #NWS44 Jisc is a registered charity (number 1149740) and a company limited by guarantee which is registered in England under Company No. 5747339, VAT No. GB 197 0632 86. Jisc’s registered office is: One Castlepark, Tower Hill, Bristol, BS2 0JA. T 0203 697 5800. Jisc Collections and Janet Ltd. is a wholly owned Jisc subsidiary and a company limited by guarantee which is registered in England under Company No. number 2881024, VAT No. GB 197 0632 86. The registered office is: Lumen House, Library Avenue, Harwell, Didcot, Oxfordshire, OX11 0SG. T 01235 822200.
On 12 Jan 2016, at 19:04, David Lord <d.lord@its.uq.edu.au> wrote:
On 13 Jan 2016, at 9:37 AM, Alan DeKok <aland@deployingradius.com> wrote:
On Jan 12, 2016, at 6:22 PM, David Lord <d.lord@its.uq.edu.au> wrote:
... whatever mail software you're using, please fix it. It mangles quoting so it's almost impossible to tell what's going on.
Sorry, Apple Mail. Switched to plain text and replies look better in outlook web now. Fixed?
Okay, I’d love to do that. Would appreciate input on this architecture.
I gave input.
Just determine which rules belong in the "default" virtual server, and while ones belong in the "inner-tunnel" virtual server.
Then... write the appropriate rules in the correct server.
The other branch of this port uses eduroam_inner, eduroam_IDP and eduroam_SP virtual servers, but I’ve been having trouble getting the right attributes forwarded. In theory IDP is exposed to the national roaming operator and SP is for our campus wifi, and SP forwards auth to IDP or the NRO. Is that sensible?
I have no idea. Please explain using english, and not tons of acronyms.
Oops, too many eduroam acronyms. I’ve seen Alan Buxey use NRO recently but that was a different mailing list.
I blame project moonshot :P I know IDP and SP, but what's a NRO? -Arran Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS development team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
I blame project moonshot :P
Oh HELL NO. Don't you be throwin' shade at my project :-)
I know IDP and SP, but what's a NRO?
National RADIUS... O-something-or-other? Alan? *You* birthed that... you explain ;-) NRPS makes sense (National Radius Proxy Server). Stefan Paetow Moonshot Industry & Research Liaison Coordinator t: +44 (0)1235 822 125 gpg: 0x3FCE5142 xmpp: stefanp@jabber.dev.ja.net skype: stefan.paetow.janet jisc.ac.uk Networkshop44, University of Manchester. Save the date: 22-24 March, 2016. #NWS44 Jisc is a registered charity (number 1149740) and a company limited by guarantee which is registered in England under Company No. 5747339, VAT No. GB 197 0632 86. Jisc’s registered office is: One Castlepark, Tower Hill, Bristol, BS2 0JA. T 0203 697 5800. Jisc Collections and Janet Ltd. is a wholly owned Jisc subsidiary and a company limited by guarantee which is registered in England under Company No. number 2881024, VAT No. GB 197 0632 86. The registered office is: Lumen House, Library Avenue, Harwell, Didcot, Oxfordshire, OX11 0SG. T 01235 822200.
On Wed, Jan 13, 2016 at 04:37:38PM +0000, Stefan Paetow wrote:
I know IDP and SP, but what's a NRO?
National RADIUS... O-something-or-other? Alan? *You* birthed that... you explain ;-)
Octopus, of course. If the NRPS is running FreeRADIUS, it's definitely the National RADIUS Octopus. Matthew -- Matthew Newton, Ph.D. <mcn4@le.ac.uk> Systems Specialist, Infrastructure Services, I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom For IT help contact helpdesk extn. 2253, <ithelp@le.ac.uk>
Octopus, of course.
If the NRPS is running FreeRADIUS, it's definitely the National RADIUS Octopus.
Works for me. ;-) Stefan Paetow Moonshot Industry & Research Liaison Coordinator t: +44 (0)1235 822 125 gpg: 0x3FCE5142 xmpp: stefanp@jabber.dev.ja.net skype: stefan.paetow.janet jisc.ac.uk Networkshop44, University of Manchester. Save the date: 22-24 March, 2016. #NWS44 Jisc is a registered charity (number 1149740) and a company limited by guarantee which is registered in England under Company No. 5747339, VAT No. GB 197 0632 86. Jisc¹s registered office is: One Castlepark, Tower Hill, Bristol, BS2 0JA. T 0203 697 5800. Jisc Collections and Janet Ltd. is a wholly owned Jisc subsidiary and a company limited by guarantee which is registered in England under Company No. number 2881024, VAT No. GB 197 0632 86. The registered office is: Lumen House, Library Avenue, Harwell, Didcot, Oxfordshire, OX11 0SG. T 01235 822200.
On 13 Jan 2016, at 11:45, Stefan Paetow <Stefan.Paetow@jisc.ac.uk> wrote:
Octopus, of course.
If the NRPS is running FreeRADIUS, it's definitely the National RADIUS Octopus.
Works for me. ;-)
Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS development team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
Hi,
Oops, too many eduroam acronyms. I’ve seen Alan Buxey use NRO recently but that was a different mailing list.
I blame project moonshot :P
I know IDP and SP, but what's a NRO?
National Roaming Operator - those that look after the eduroam in their federation/jurisdiction - e.g. JISC for UK, DFN for Germany etc etc - as per the eduroam documentation ;-) alan
On 2016-01-13 02:04, David Lord wrote:
[...] If one virtual server (SP) uses Proxy-To-Realm to forward to a 2nd virtual server (IDP), which uses an eap module with peap & ttls “virtual_server” set to a 3rd virtual server (inner), is there a reliable way to forward attributes from #3 to #1?
In other words the default server would be configured to proxy requests to a particular realm to a virtual_server and the EAP module called by that virtual server would point to a third (inner-tunnel) virtual server. I recall that a request can not be proxied more than once to a virtual server, and that is by design. Right?
On Thu, Jan 14, 2016 at 01:05:32AM +0200, Zenon Mousmoulas wrote:
On 2016-01-13 02:04, David Lord wrote: In other words the default server would be configured to proxy requests to a particular realm to a virtual_server and the EAP module called by that virtual server would point to a third (inner-tunnel) virtual server. I recall that a request can not be proxied more than once to a virtual server, and that is by design. Right?
Outer-EAP -> inner-EAP isn't proxying. But still, I'm not entirely sure why you'd do this anyway unless you want a messy/complicated config. The outer can either proxy (if required) or call EAP for local auth, so two virtual-server "layers". If you really wanted to keep the architecture clean I'd just be inclined to set up a second set of proxy-only servers to keep the first layer separate rather than doing it all in the same server. VMs are cheap, and the design is much easier for others to understand. Matthew -- Matthew Newton, Ph.D. <mcn4@le.ac.uk> Systems Specialist, Infrastructure Services, I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom For IT help contact helpdesk extn. 2253, <ithelp@le.ac.uk>
Thanks all for the responses, particularly the National Roaming Octopus. Agreed that the triple-server architecture is excessive. You can enforce the Identity Provider vs Service Provider distinction by stripping SP-only attributes from replies sent outside your network. For anyone curious in future, since I’ve read a lot of the mailing list via Google and this may be helpful: What I’ve ended up with is two virtual servers, inner and outer. Outer will always set all attributes, and then runs a custom attr_filter which keys on %{client:shortname}* and removes the private attributes from the clients with the wrong names. Haven’t looked at the RFCs yet for appropriate attributes to permit. * incidentally, the attr_filter module doesn’t seem to enable the new &format.
What I¹ve ended up with is two virtual servers, inner and outer. Outer will always set all attributes, and then runs a custom attr_filter which keys on %{client:shortname}* and removes the private attributes from the clients with the wrong names.
That's it. :-) *thumbs up* Stefan Paetow Moonshot Industry & Research Liaison Coordinator t: +44 (0)1235 822 125 gpg: 0x3FCE5142 xmpp: stefanp@jabber.dev.ja.net skype: stefan.paetow.janet jisc.ac.uk Networkshop44, University of Manchester. Save the date: 22-24 March, 2016. #NWS44 Jisc is a registered charity (number 1149740) and a company limited by guarantee which is registered in England under Company No. 5747339, VAT No. GB 197 0632 86. Jisc¹s registered office is: One Castlepark, Tower Hill, Bristol, BS2 0JA. T 0203 697 5800. Jisc Collections and Janet Ltd. is a wholly owned Jisc subsidiary and a company limited by guarantee which is registered in England under Company No. number 2881024, VAT No. GB 197 0632 86. The registered office is: Lumen House, Library Avenue, Harwell, Didcot, Oxfordshire, OX11 0SG. T 01235 822200.
Hi,
What I’ve ended up with is two virtual servers, inner and outer. Outer will always set all attributes, and then runs a custom attr_filter which keys on %{client:shortname}* and removes the private attributes from the clients with the wrong names.
not ideal. as what you are doing is a lot of LDAP or scripts etc to find group membership assign VLAN etc etc ....and then stripping them out. for efficiency, use virtual servers.. one pair - lets say 'default and inner-tunnel' for all your inside stuff..... for requests from the outside world, use a new pair eg eduroam and eduroam-inner-tunnel - these can be almost direct copies of the default and inner-tunnel but a different eap config is used by the 'eduroam' to ensure that calls go to eduroam-inner-tunnel for EAP... then you just set virtual_server = eduroam for those 3 clients the efficiencies here 1) you dont need to check the User-Name is valid - the remote proxy only sends good stuff to you - thats a lot of regex etc removed 2) you can block non-EAP for remote auths easily - allowing you to run your server for all internal stuff without clashing with external policies - you can have any internal policy you want 3) avoid checking eg LDAP for group memberships for settings VLAN - as its not going to be used 4) can call eg CUI for these external requests to generate such attributes (if you have no need to do this internally) 5) no need to worry about filtering certain attributes as you havent set them 6) using seperate virtual servers for seperate functions is best common practice and keeps the config far easier with less weird if/else/elsif and dealing with all sorts of strange corner cases - making eg upgrade from 2.x to 3.x a lot easier 7) using a seperate virtual server in cofnig means we can look at providing a 'ready to go template' for eduroam authentications without affecting your own internal config ;-) alan
participants (7)
-
A.L.M.Buxey＠lboro.ac.uk -
Alan DeKok -
Arran Cudbard-Bell -
David Lord -
Matthew Newton -
Stefan Paetow -
Zenon Mousmoulas