Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

TNC19 Radiator Technical Workshop -- Using Radiator to ensure better SP/IdP connections to eduroam/govroam

41 views

Published on

TNC19 Radiator technical workshop presentation about using Radiator to ensure better SP/IdP connections to eduroam/govroam.

Published in: Technology
  • Be the first to comment

  • Be the first to like this

TNC19 Radiator Technical Workshop -- Using Radiator to ensure better SP/IdP connections to eduroam/govroam

  1. 1. TNC19 Radiator technical workshop Using Radiator to ensure better SP/IdP connections to eduroam/govroam
  2. 2. Ensuring compliance with Radiator Radiator has support for several required or useful functionalities: ● Status-Server (for IdP, SP and TLR) ● RadSec ● EAP context preserving load balancing ● Username/realm routing, rewriting and mangling ● Loop prevention ● Multiple database backends to help with dynamic configuration
  3. 3. Status-Server (for IdP, SP and TLR) ● Many RADIUS requests in roaming federation do not receive responses. ● Some reasons for this are: firewalling, configuration errors, TLS errors, Microsoft NPS… ● When some RADIUS servers do not receive response from their neighbour, they mark that neighbour dead, which causes outages for example when top-level RADIUS servers are accidentally marked dead.
  4. 4. Status-Server (for IdP, SP and TLR) ● Status-Server is a standard RADIUS message to test RADIUS connection without relying to access requests ● Unfortunately Status-Server is supported for certain only in Radiator, stand-alone FreeRADIUS and radsecproxy. ● Because of this Radiator now has also support for RADIUS Access Request based availability testing.
  5. 5. Transport Layer Security (TLS) Encryption for RADIUS (RFC 6614) also known as RadSec ● Designed by TNC people: S. Winter (Restena), M. McCauley (OSC/Radiator), S. Venaas (Cisco), K. Wierenga (Cisco) ● Supported by Radiator since early drafts, supported also by FreeRADIUS and radsecproxy. ● Secures plain RADIUS traffic with TLS for added privacy
  6. 6. ● We work together with eduroam people to develop RadSec support in Radiator further. Thanks especially to Paul Dekkers and Stefan Winter for their feedback and bug reports. ● Please note that in afternoon after Radiator workshop there will be a presentation in Mobility Day track about NRO/TLR RADIUS servers adopting RadSec connections.
  7. 7. EAP context preserving load balancing ● Not many load balancers understand RADIUS protocol and even fewer can preserve EAP context needed for WPA2 enterprise (eduroam/govroam) authentication. ● Extra attention must be focused in configuring load balancing so that RADIUS packets belonging to same authentication end up to the same EAP endpoint.
  8. 8. EAP context preserving load balancing ● Most common way to solve this is to fix load balancing decision to the RADIUS client source IP address. This may not be enough to spread the traffic efficiently. ● Radiator supports load balancing with features like HASHBALANCE. EAPBALANCE considered harmful nowadays. ● HASHBALANCE can be done based on for example Called-Station-Id/Calling-Station-Id resulting more even distribution.
  9. 9. Username/realm routing, rewriting and mangling ● Using federated RADIUS roaming requires that RADIUS server can do sometimes complex username and realm based RADIUS request routing. ● Often and especially when using backends like Active Directory, username/realm rewriting and mangling needs to be done by RADIUS server to ensure roaming and authentication functionality.
  10. 10. Username/realm routing ● Radiator already has advanced username/realm routing features such as storing realm routing information into SQL/SQLite databases. ● We are constantly improving Radiator’s username/realm routing capabilities. Next on our development list is RealmTable.
  11. 11. Govroam(UK) example with Radiator ● Windows domain LOCAL is not unique => it is not routable in govroam ● Windows cannot set outer EAP realm to differ from the inner realm ● Microsoft NPS RADIUS cannot manipulate usernames/realms properly
  12. 12. Govroam(UK) example with Radiator ● User terminals are configured to use unique realm for organisation => govroam routing works ● Radiator uses AuthBy LSA to communicate directly with Active Directory ● Radiator switches the realm to local value and authenticates the user against Active Directory. ● Radiator AuthBy LSA makes MSCHAP(v2)/PEAP work whatever the internal AD domain would be. Microsoft NPS was replaced with Radiator running on top of Windows. Linux with Radiator and ntlm_auth is likely to work as well.
  13. 13. Loop prevention ● A loop forms e.g. when organisation proxies back a RADIUS request, which higher level RADIUS server has sent to it. ● Additional configuration and functionality is needed in the regional/federation RADIUS proxies to detect and prevent loops. ● All this adds more complexity to the federation, when there are ways for IdPs to prevent loops from their end.
  14. 14. Loop prevention ● eduroam community has already provided configurations for example for Radiator to prevent loops and empty realms to be forwarded: https://wiki.geant.org/display/H2eduroam/radiator-flr ● Please follow eduroam configuration recommendations if your RADIUS software supports them -- and consider using more compliant RADIUS software as a proxy, if your IdP RADIUS cannot follow or configure them.
  15. 15. Dynamic configuration ● Manipulating RADIUS clients and realms within text configuration is error-prone and requires usually restarts creating at least short outages. ● Text configuration in Radiator is also slower than for example having realm information in SQL(ite).
  16. 16. Dynamic configuration ● Radiator can retrieve a major part of its configuration information from for example SQL(ite) databases. ● Those databases can then be managed separately from Radiator configuration and processes. ● Dynamically retrieved configuration from SQL(ite) databases, reduces the need for editing configuration files or restarting processes.
  17. 17. Wrap-up -- Radiator advantage Radiator has support for several required or useful functionalities: ● Status-Server (for IdP, SP and TLR) ● RadSec ● EAP context preserving load balancing ● Username/realm routing, rewriting and mangling ● Loop prevention ● Multiple database backends to help with dynamic configuration
  18. 18. Thank you. Questions, comments? For more information, remember to check out ... Radiator Cookbook blog.radiatorsofware.com And Twitter @OSCRadiator

×