Govroam

The Roaming solution for the public sector

User Tools

Site Tools

You are here: start » public » implementing_govroam
public:implementing_govroam

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
public:implementing_govroam [2019/02/22 11:43] – [Govroam network] adminpublic:implementing_govroam [2025/03/28 14:53] (current) – ↷ Links adapted because of a move operation admin
Line 54: Line 54:
 Recommended viewing -  video of James Hooper's presentation overview of the Govroam deployment at Bristol, '[[https://webmedia.company.ja.net/content/presentations/shared/networkshop300310/hooper_challengesofwidescaledeployment/hooper_challengesofwidescaledeployment.html|Challenges for wide scale 802.1X deployment]]' Recommended viewing -  video of James Hooper's presentation overview of the Govroam deployment at Bristol, '[[https://webmedia.company.ja.net/content/presentations/shared/networkshop300310/hooper_challengesofwidescaledeployment/hooper_challengesofwidescaledeployment.html|Challenges for wide scale 802.1X deployment]]'
 <note warning>Eduroam specific. Can we do a Govroam version? Mark?</note> <note warning>Eduroam specific. Can we do a Govroam version? Mark?</note>
-. For slideset, see 'Resources' at bottom of this [[section]]. Although showing it's age now, this is a comprehensive overview of Govroam deployment and can be viewed in parallel with the notes below. Govroam CAT is not covered and references to 'Janet' and 'JRS' should now be understood as 'Jisc' and 'Govroam'.+. For slideset, see [[:public:implementing_govroam#resources1|Resources]] at bottom of this section. Although showing it's age now, this is a comprehensive overview of Govroam deployment and can be viewed in parallel with the notes below. Govroam CAT is not covered and references to 'Janet' and 'JRS' should now be understood as 'Jisc' and 'Govroam'.
  
 ==== Consider Wi-Fi and Network Architecture if offering Visited Service ==== ==== Consider Wi-Fi and Network Architecture if offering Visited Service ====
  
-All Govroam services require you to deploy a RADIUS service. Ideally this should be a resilient service and comprise two servers, which may be physical boxes or virtual machines. Selection of the RADIUS server software is covered in the following [[section]].+All Govroam services require you to deploy a RADIUS service. Ideally this should be a resilient service and comprise two servers, which may be physical boxes or virtual machines. Selection of the [[:public:implementing_govroam#choice_of_platform|RADIUS server software]] is covered in the following section.
  
 Consider the technological aspects of the network you wish to offer Govroam over. To provide a reasonably standard experience for users and to try reduce the amount of changes to supplicant and application settings required from site to site, the Tech Spec currently defines a single sets of network parameters based on WPA2 'enterprise' authentication with AES encryption. Consider the technological aspects of the network you wish to offer Govroam over. To provide a reasonably standard experience for users and to try reduce the amount of changes to supplicant and application settings required from site to site, the Tech Spec currently defines a single sets of network parameters based on WPA2 'enterprise' authentication with AES encryption.
Line 129: Line 129:
   * [[https://www.juniper.net/us/en/products-services/ipc/|Juniper Funk Steel-Belted Radius website]]   * [[https://www.juniper.net/us/en/products-services/ipc/|Juniper Funk Steel-Belted Radius website]]
   * [[https://radsecproxy.github.io/|Radsecproxy]]   * [[https://radsecproxy.github.io/|Radsecproxy]]
-Your ORPS may be [[jisc:frequently_asked_questions#qwhat_hardware_software_is_required_for_govroam|physical machines or may be VM-based]]+Your ORPS may be [[public:frequently_asked_questions#qwhat_hardware_software_is_required_for_govroam|physical machines or may be VM-based]]
  
 ===== Network Architecture ===== ===== Network Architecture =====
Line 228: Line 228:
 ====== Support Server Section ====== ====== Support Server Section ======
  
 +<note important>Add some information about the various tools we have</note>
 ====== Install Your RADIUS Server (ORPS) ====== ====== Install Your RADIUS Server (ORPS) ======
  
Line 335: Line 336:
 ====== Add your ORPS to the Govroam RADIUS Infrastructure and Add NRPS to your ORPS RADIUS config ====== ====== Add your ORPS to the Govroam RADIUS Infrastructure and Add NRPS to your ORPS RADIUS config ======
  
-You now need to peer your ORPS(s) with the NRPSs so that they can exchange RADIUS communications. This requires the addition of your RADIUS servers as clients in the relevant RADIUS server configurations together with the shared secrets that will establish trust. As stated in [[section 6]], your ORPS needs to have a public facing IP address and a fully qualified domain name (an address record in DNS). Your ORPS will be configured in the NRPS clients tables with their IP addresses, but you need to provide us with the FQDNs. This reduces scope for error, facilitates IPv4 and v6 support and enables you to change the IP address in the future without needing to update Support.+You now need to peer your ORPS(s) with the NRPSs so that they can exchange RADIUS communications. This requires the addition of your RADIUS servers as clients in the relevant RADIUS server configurations together with the shared secrets that will establish trust. As stated in [[public:implementing_govroam#install_your_radius_server_orps]|Install Your RADIUS Server]], your ORPS needs to have a public facing IP address and a fully qualified domain name (an address record in DNS). Your ORPS will be configured in the NRPS clients tables with their IP addresses, but you need to provide us with the FQDNs. This reduces scope for error, facilitates IPv4 and v6 support and enables you to change the IP address in the future without needing to update Support.
  
 Since a there are two ends of the RADIUS conversations there are two operations: Since a there are two ends of the RADIUS conversations there are two operations:
Line 366: Line 367:
 Additional ORPS can be added to the clients config of the NRPS by following the same steps as described above.  It is now quite common practice for organisations to deploy multiple ORPSs, which they may do for resilience or load sharing. You can add as many ORPS as you wish.  Additional ORPS can be added to the clients config of the NRPS by following the same steps as described above.  It is now quite common practice for organisations to deploy multiple ORPSs, which they may do for resilience or load sharing. You can add as many ORPS as you wish. 
  
-Once an ORPS has been added the NRPSs will automatically communicate with it. NRPS send all traffic to the first ORPS in their config list until it stops responding, the NRPS then try the next ORPS in the list. The order of preference is the order which the ORPS were added to the Support server.  If you want any particular ORPS to be your primary server, set the 'High priority' option on its config on the Support server, as indicated in [[section 9.1]].  +Once an ORPS has been added the NRPSs will automatically communicate with it. NRPS send all traffic to the first ORPS in their config list until it stops responding, the NRPS then try the next ORPS in the list. 
  
 Shared secrets for your additional ORPS: Normally every ORPS has a unique set of shared secrets for peering with the NRPS. This is best practice and the most secure way of employing shared secrets. This remains true even in scenarios in which peered realms contain multiple RADIUS servers.  When an organisation registers a second ORPS, by default a further unique set of shared secrets is generated, different from those for the first ORPS. Govroam administrators must be aware that in deployments where the ORPS form fail-over clusters you cannot simply use the original four shared secrets on both ORPSs. Shared secrets for your additional ORPS: Normally every ORPS has a unique set of shared secrets for peering with the NRPS. This is best practice and the most secure way of employing shared secrets. This remains true even in scenarios in which peered realms contain multiple RADIUS servers.  When an organisation registers a second ORPS, by default a further unique set of shared secrets is generated, different from those for the first ORPS. Govroam administrators must be aware that in deployments where the ORPS form fail-over clusters you cannot simply use the original four shared secrets on both ORPSs.
Line 454: Line 455:
 The next stage is to configure the handling of RADIUS Access-Request packets from your network NAS systems (APs, WLCs and [if you support wired .1X connection] switches) by your ORPS. The aim is to handle Access-Request packets arising from your users authentication requests locally while Access-Requests arising from visiting users need to be forwarded to the NRPS servers. How you go about achieving this is dependent on the RADIUS platform you have deployed. FreeRADIUS and Radiator use unlang script language/PERL and in the case of FR, virtual servers which are dedicated to particular tasks and which can be tuned for best performance, whilst Microsoft NPS and Cisco ISE require policies to be defined and configuration carried via GUI.  The next stage is to configure the handling of RADIUS Access-Request packets from your network NAS systems (APs, WLCs and [if you support wired .1X connection] switches) by your ORPS. The aim is to handle Access-Request packets arising from your users authentication requests locally while Access-Requests arising from visiting users need to be forwarded to the NRPS servers. How you go about achieving this is dependent on the RADIUS platform you have deployed. FreeRADIUS and Radiator use unlang script language/PERL and in the case of FR, virtual servers which are dedicated to particular tasks and which can be tuned for best performance, whilst Microsoft NPS and Cisco ISE require policies to be defined and configuration carried via GUI. 
  
-Authentication of your own users should be considered as a separate logical process from Access-Request packet handling/'proxying'. This is covered later in [[adminonly:section_13]].+Authentication of your own users should be considered as a separate logical process from Access-Request packet handling/'proxying'. This is covered later in [[public:implementing_govroam#radius_server_configuration_for_home_service_-_interoperation_with_user_database|RADIUS server configuration for Home service]].
  
 To save having to revisit this part of your configuration at a later stage, it is worthwhile tackling the issue of dealing with badly-formed usernames during this setup stage. Due to the huge number of users of Govroam and explosive growth over recent years, this is an important topic. Dealing with badly formed usernames applies to both local authentication of your own users and forwarding of auth requests for visitors. The object of filtering invalid realms is covered in the separate advisory document [[https://community.ja.net/library/janet-services-documentation/filtering-invalid-realms|Filtering of Invalid Realms]]. How put this into [[public:implementing_govroam#configure_rejection_of_malformed_usernames|practice with FreeRADIUS]] and for [[https://community.ja.net/library/janet-services-documentation/microsoft-nps-2008r2-config-avoid-bad-usernames-flooding-nrps|Microsoft NPS the Microsoft NPS 2008R2 config to avoid bad usernames flooding NRPS]] document and in the [[:public:govroam_nps_implemention_guide]] to be published shortly. To save having to revisit this part of your configuration at a later stage, it is worthwhile tackling the issue of dealing with badly-formed usernames during this setup stage. Due to the huge number of users of Govroam and explosive growth over recent years, this is an important topic. Dealing with badly formed usernames applies to both local authentication of your own users and forwarding of auth requests for visitors. The object of filtering invalid realms is covered in the separate advisory document [[https://community.ja.net/library/janet-services-documentation/filtering-invalid-realms|Filtering of Invalid Realms]]. How put this into [[public:implementing_govroam#configure_rejection_of_malformed_usernames|practice with FreeRADIUS]] and for [[https://community.ja.net/library/janet-services-documentation/microsoft-nps-2008r2-config-avoid-bad-usernames-flooding-nrps|Microsoft NPS the Microsoft NPS 2008R2 config to avoid bad usernames flooding NRPS]] document and in the [[:public:govroam_nps_implemention_guide]] to be published shortly.
Line 501: Line 502:
 Shared secrets check. In scenarios involving multiple ORPSs, it is advisable to test each ORPS independently for correct configuration. Shared secrets can be checked by simply running a command line test on each of the ORPS. Note that whilst FreeRADIUS, Radiator and MS NPS include utilities for cleartext password based authentication methods such as PAP, this is no longer supported by the Govroam infrastructure, so please do not attempt to use radtest, radpwtst or ntradping. Shared secrets check. In scenarios involving multiple ORPSs, it is advisable to test each ORPS independently for correct configuration. Shared secrets can be checked by simply running a command line test on each of the ORPS. Note that whilst FreeRADIUS, Radiator and MS NPS include utilities for cleartext password based authentication methods such as PAP, this is no longer supported by the Govroam infrastructure, so please do not attempt to use radtest, radpwtst or ntradping.
  
-a) If you have not hooked your Wi-Fi service in to your RADIUS server, the simplest test involves using a command line tool to try to send Access-Request packets to the NRPS for forwarding to the Govroam Support IdP for a test user belonging to the Govroam realm. (This is a command line variation of the standard visitor authentication simulation test - see [[section 12]] below). +a) If you have not hooked your Wi-Fi service in to your RADIUS server, the simplest test involves using a command line tool to try to send Access-Request packets to the NRPS for forwarding to the Govroam Support IdP for a test user belonging to the Govroam realm. (This is a command line variation of the standard visitor authentication simulation test - [[:public:implementing_govroam#visitor_authentication_simulation_test|Visitor Authentication Simulation Test]]). 
  
 eapol_test is included in wpa_supplicant which is an opensource supplicant that can be acquired from [[http://w1.fi/wpa_supplicant/|http://w1.fi/wpa_supplicant/]] eapol_test is included in wpa_supplicant which is an opensource supplicant that can be acquired from [[http://w1.fi/wpa_supplicant/|http://w1.fi/wpa_supplicant/]]
Line 744: Line 745:
 ====Govroam network==== ====Govroam network====
  
-Visited organisations must implement one (or more) dedicated network/VLAN(s) to provide Govroam network services. All Govroam networks must comply with the Govroam Tech Spec (access to the Internet permitting use of (at least) the defined key ports and protocols - see [[Firewall section]]). Any Govroam network/VLAN must not be shared with any other network service, including eduroam. Authenticated Visitors must be connected to such an Govroam network service.+Visited organisations must implement one (or more) dedicated network/VLAN(s) to provide Govroam network services. All Govroam networks must comply with the Govroam Tech Spec (access to the Internet permitting use of (at least) the defined key ports and protocols - see [[:public:implementing_govroam#firewall_configuration_to_support_govroam_network_service|Firewall Configuration]]). Any Govroam network/VLAN must not be shared with any other network service, including eduroam. Authenticated Visitors must be connected to such an Govroam network service.
  
 Most participating organisations permit their own users to connect via the organisation's Govroam Wi-Fi service. If this is not permitted, this must be clearly stated on the organisation's Govroam Service Information web page. Organisations may connect local users to the mandatory Visitors' Govroam network service, but alternatively may connect them to a more appropriate local network. This can be achieved through 'dynamic VLAN assignment' (which is the more efficient alternative to the fixed SSID-VLAN mapped solution). Such local networks may be used to for example satisfy the following requirements: Most participating organisations permit their own users to connect via the organisation's Govroam Wi-Fi service. If this is not permitted, this must be clearly stated on the organisation's Govroam Service Information web page. Organisations may connect local users to the mandatory Visitors' Govroam network service, but alternatively may connect them to a more appropriate local network. This can be achieved through 'dynamic VLAN assignment' (which is the more efficient alternative to the fixed SSID-VLAN mapped solution). Such local networks may be used to for example satisfy the following requirements:
Line 770: Line 771:
   * WEP must not be implemented on the Govroam Wi-Fi service that connects to the Govroam network service   * WEP must not be implemented on the Govroam Wi-Fi service that connects to the Govroam network service
   * TLS interception proxies/filters must not be employed on the Govroam network service for visitors   * TLS interception proxies/filters must not be employed on the Govroam network service for visitors
-Visited organisations may implement IPv4 and IPv6 filtering between the visitor VLAN and other external networks, providing that this permits the forwarding protocols detailed in the [[Firewall Configuration section]].+Visited organisations may implement IPv4 and IPv6 filtering between the visitor VLAN and other external networks, providing that this permits the forwarding protocols detailed in the [[:public:implementing_govroam#firewall_configuration_to_support_govroam_network_service|Firewall Configuration]].
  
 ==== Resources: ==== ==== Resources: ====
Line 1054: Line 1055:
   * testuser@realm - handled locally and NOT forwarded to NRPS   * testuser@realm - handled locally and NOT forwarded to NRPS
   * invalidtestuser@realm - rejected locally and NOT forwarded to NRPS   * invalidtestuser@realm - rejected locally and NOT forwarded to NRPS
-The following section focusses on expands on invalid User-Name (ie those that do not conform to the Network Access Identifier standard).+The following section focusses on invalid User-Name (ie those that do not conform to the Network Access Identifier standard).
  
 **Username Handling Conformance Check** - of particular importance in deployments where a single SSID 'Govroam' is implemented at an orgnisation, usernames MUST be in the form user@myorganisationname.uk (.net and .org.uk are also acceptable as is .subrealm.uk etc.) This ensures that users are able to utilise Govroam in a seamless manner when they travel. **Username Handling Conformance Check** - of particular importance in deployments where a single SSID 'Govroam' is implemented at an orgnisation, usernames MUST be in the form user@myorganisationname.uk (.net and .org.uk are also acceptable as is .subrealm.uk etc.) This ensures that users are able to utilise Govroam in a seamless manner when they travel.
Line 1066: Line 1067:
   * testuser@anyrealm. (ends with a dot) - authentication should be dropped (User-Name realm MUST NOT end with '.')   * testuser@anyrealm. (ends with a dot) - authentication should be dropped (User-Name realm MUST NOT end with '.')
   * testuser@myorganisationname..ac.uk (contains double dot) - authentication should be dropped (User-Name realm MUST NOT contain double '..')   * testuser@myorganisationname..ac.uk (contains double dot) - authentication should be dropped (User-Name realm MUST NOT contain double '..')
-**Govroam Information Web Site** - you must have an information web site as detailed in the {{ :public:20171212_govroam_tech_spec_v2.pdf |Tech Spec}} and described in section 18 below promoting Govroam at your organisation +**Govroam Information Web Site** - you must have an information web site as detailed in the {{ :public:20171212_govroam_tech_spec_v2.pdf |Tech Spec}} and described in below [[public:implementing_govroam#promoting_govroam_at_your_organisation|promoting Govroam at your organisation]].
-<note important>Internal link</note> +
-.+
  
   * Govroam information page on organisation web site - yes   * Govroam information page on organisation web site - yes
Line 1112: Line 1111:
 We would suggest that information on how to get started with campus network services includes information about Govroam. You might want to provide an open access captive portal network service for first time users that simply provides information about Govroam, links to your preferred Govroam setup tools and guidance on how to get IT support. We would suggest that information on how to get started with campus network services includes information about Govroam. You might want to provide an open access captive portal network service for first time users that simply provides information about Govroam, links to your preferred Govroam setup tools and guidance on how to get IT support.
  
-===== Mapping App =====+====== Mapping App ======
  
 +<note important>Add information about the mapping app, how to obtain credentials, how to add sites, how to use it etc.</note>
public/implementing_govroam.1550835834.txt.gz · Last modified: 2019/02/22 11:43 by admin