How to Set Up Registration

The Extreme Networks ExtremeControl Solution provides support for Registration which forces any new end-system connected on the network to provide the user's identity in a web page form before being permitted access to the network. Registration utilizes Registration Web Server functionality installed on an ExtremeControl engine to enable end users to register their end-systems and automatically obtain network access without requiring the intervention of network operations. For more information on Registration and an overview of how it works, see the Registration section of the Concepts help file.

  NOTE: For important information on web browser requirements for end-systems connecting through ExtremeCloud IQ Site Engine, refer to the ExtremeControl Configuration Considerations Help topic.

This Help topic describes the specific steps that must be performed when deploying Registration on your network. The steps vary depending on whether you are using ExtremeControl Gateway engines and/or Layer 2 ExtremeControl Controller engines on your network. (Registration is not supported on the Layer 3 ExtremeControl Controller engines.)

For ExtremeControl Gateway engines you must:

  • Identify the location in your network topology for the ExtremeControl Gateway installation.
  • Define the access policy for authorizing unregistered end-systems.
  • Configure policy-based routing on your network.
  • Configure Registration parameters in ExtremeCloud IQ Site Engine.

For Layer 2 ExtremeControl Controller engines you must:

  • Configure Registration parameters in ExtremeCloud IQ Site Engine.

The Registration Web Server is pre-installed on the ExtremeControl engine. For instructions on installing and configuring a ExtremeControl engine, refer to your engine Installation Guide.

  NOTE: It is important to add a DNS entry from the Fully Qualified Domain Name (FQDN) of the ExtremeControl engine (both ExtremeControl Gateways and ExtremeControl Controllers) into the DNS servers deployed on the network so that the device running ExtremeCloud IQ Site Engine is able to resolve queries to these DNS servers. Otherwise, a short delay occurs in returning the Registration web page to end users on the network.

Information and instructions on:

ExtremeControl Gateway Configuration

Perform the following steps when you are deploying Registration in a network that utilizes ExtremeControl Gateway engines. These steps are not necessary if you are utilizing only ExtremeControl Controller engines on your network.

Identifying ExtremeControl Gateway Location

Although several ExtremeControl Gateways can be deployed on the entire network depending on the number of connecting end-systems, only one ExtremeControl Gateway is required to serve as the Registration Web Server. The location of this ExtremeControl Gateway is important for the implementation of web redirection for unregistered end-systems on the network. The ExtremeControl Gateway serving as the Registration Web Server must be installed on a network segment directly connected to a router or routers that exist in the forwarding path of HTTP traffic from unregistered end-systems. This is because policy-based routing is configured on this router or routers to redirect the web traffic sourced from unregistered end-systems to this ExtremeControl Gateway. It is important to note that only the ExtremeControl Gateway that you wish to serve as the Registration Web Server needs to be positioned in such a manner. All other ExtremeControl Gateways can be positioned at any location on the network, with the only requirement being that access layer switches are able to communicate to the gateways.

Typically, the ExtremeControl Gateway serving as the Registration Web Server is positioned on a network segment directly connected to the distribution layer routers on the enterprise network, so that any HTTP traffic sourced from unregistered end-systems that are connected to the network's access layer can be redirected to that ExtremeControl Gateway. As an alternative, the ExtremeControl Gateway can be positioned on a network segment directly connected to the router providing connectivity to the Internet or internal web server farm. In this scenario, the HTTP traffic sourced from unregistered end-systems would be redirected to the ExtremeControl Gateway before reaching the Internet or internal web servers.

Defining the Unregistered Access Policy

When you implement Registration, you assign the Unregistered ExtremeControl Profile defined in ExtremeCloud IQ Site Engine (ExtremeCloud IQ Site Engine) as the Default Profile for all end-systems connected to the engine group. The Unregistered ExtremeControl Profile specifies that end-systems are not assessed for security posture compliance (at this time) and authorizes end-systems on the network with the "Unregistered" access policy. With this configuration, end-systems are first forced to register to the network, and after successful registration, can be assessed for security posture compliance and subsequently quarantined or permitted network access.

Note that an end-system group can be configured to exempt certain devices from having to register to the network, based on authentication type, MAC address, or user name. For example, an end-system group for the MAC OUI of the printer vendor for the network can be configured to exempt printers from having to register for network access.

Creating the Unregistered Access Policy

The Unregistered access policy must permit unregistered end-systems access to ARP, DHCP, DNS, and HTTP; particularly HTTP communication to the ExtremeControl Gateway implementing the Registration Web Server functionality. For a network composed of EOS policy-enabled switches in the access layer, you must create the appropriate network access services and rules for the Unregistered policy role in ExtremeCloud IQ Site Engine's Control > Policy tab to meet these requirements, and enforce those changes to the policy-enabled switches. For a network composed of RFC 3580-enabled switches, you must ensure appropriate network services are enabled for the VLAN(s) associated to the Unregistered access policy.

For EOS policy-enabled Access Layer Switches

When configuring the Unregistered policy role (using ExtremeCloud IQ Site Engine's Policy tab) for EOS policy-enabled switches, there are two required configurations:

  • A rule must be added that permits HTTP traffic (i.e. TCP destination port equaling 80) on the network.
  • The rule must specify a class of service action that rewrites the ToS value of the HTTP traffic to a value of 'y'. This value should match the decimal equivalent used in your policy-based routing that is used on the router.

If Assisted Remediation is already deployed with the Quarantine policy role appropriately configured for web redirection on EOS policy-enabled access layer switches, the simplest way to configure the Unregistered policy role in ExtremeCloud IQ Site Engine is to copy and paste the Quarantine policy role under the Roles tab in ExtremeCloud IQ Site Engine and rename this new policy role "Unregistered".

In addition, the Policy tab's Default Policy Domain includes an Unregistered role that is already configured with a service called Redirect Web Services, that includes an "Allow HTTP and Redirect" rule configured with the ExtremeControl Web Redirect Class of Service.

Perform the following steps in ExtremeCloud IQ Site Engine to configure your Unregistered policy role.

  NOTE: The ExtremeCloud IQ Site Engine Default Policy Domain includes an ExtremeControl Web Redirect Class of Service you can use. Make sure that the ToS rewrite value is set to the appropriate value for your network. If you already created a Class of Service with ToS rewrite functionality for Assisted Remediation, you can use that same Class of Service for Registration and start with step number 3 below.
  1. In ExtremeCloud IQ Site Engine, access the Administration > Options tab and select Policy Manager in the left-panel.
  2. In the Default Class of Service Mode section, select Role-Based Rate Limits/Transmit Queue Configuration to enable the Role-based Class of Service mode on your network devices.
  3. Create a new Class of Service that implements the ToS rewrite functionality:
    1. Open the Class of Service left-panel (Control > Policy tab > Class of Service).
    2. Right-click the Class of Service navigation tree and select Create CoS.
      The Create CoS window opens.
    3. Enter a name for the class of service (for example, "Web Redirection").
    4. Select OK.
    5. Select the 802.1p Priority checkbox and use the drop-down list to select the 802.1p priority to associate with the class of service.
    6. Select the Edit button next to the ToS field and enter a value (hex).
    7. The new Class of Service is automatically saved.
  4. Create an "Allow HTTP" rule to a service currently included in your Unregistered policy role.
    1. Right-click a service in the Roles/Services left-panel and select Create Rule.
    2. Enter a name for the rule (for example, "Allow HTTP") and select All Devices in the Rule Type(s) drop-down list.
    3. Select OK.
    4. Select the new rule in the left-panel to display the rule details in the right panel.
    5. Enter a Description for the rule.
    6. Select Enabled in the Rule Status drop-down list.
    7. In the Traffic Description section, select the Edit button.

      The Edit Traffic Description window displays.
    8. Select Layer 4 - Application Transport in the Traffic Classification Layer drop-down list.
    9. Select IP TCP Port Destination in the Traffic Classification Type drop-down list.
    10. Select HTTP (80) in the Well-Known Value drop-down list.
    11. Do not enter an IP address value.
    12. Select OK.
    13. In the Actions section, select Permit Traffic in the Access Control drop-down list.
    14. Select CoS you created in step 2 ("Web Redirection") in the Class of Service drop-down list.
    15. In the Open/Manage Domain(s) drop-down list at the top of the tab, select Save Domain.
  5. Enforce these policy configurations to your network devices by selecting Enforce Preview in the Enforce drop-down list.

    The Enforce Preview window displays.
  6. Verify the information you are enforcing is correct and select the Enforce button.

For RFC 3580-compliant Access Layer Switches

A VLAN must be identified to which unregistered end-systems will be assigned upon connecting to the network. You can make this the same VLAN assigned to end-systems when they are being assessed or quarantined. The VLAN must provision network services to an unregistered end-system that permit the end-system to open a web browser; specifically HTTP, DHCP, ARP, and DNS. Furthermore, it is required that IP connectivity between the end-system and the ExtremeControl Gateway implementing the Registration Web Server functionality is operational.

The VLAN to which unregistered end-systems are assigned must be appropriately configured on all access layer switches where end-systems will be registering to the network. Access Control lists can be configured at the default gateway router's interface for the unregistered VLAN to restrict particular types of traffic sourced from end-systems within this VLAN to other areas of the network; withstanding the previously described provisioning requirements for this VLAN.

For Both EOS policy-enabled and RFC 3580-compliant Access Layer Switches

Now that you have defined the Unregistered policy role for EOS policy-enabled switches and/or the VLAN assigned to unregistered end-systems for RFC 3580-compliant switches, you must associate this policy role to the appropriate VLAN on the Access Control tab.

  1. In ExtremeCloud IQ Site Engine, access the Control > Access Control tab.
  2. Select the Unregistered NAC Profile entry in the Configuration > Profiles left-panel menu.
  3. In the Accept Policy drop-down list, select Manage Policy Mappings.

    The Manage Policy Mappings window displays.
  4. Select the Unregistered policy and select the Edit button.

    The Edit Policy Mapping window displays.
  5. Select Unregistered in the Policy Role drop-down list.
  6. Select the Save button.
  7. Select Close to close the Manage Policy Mappings window.

Your Unregistered access policy is now configured to permit unregistered end-systems the ability to communicate to the ExtremeControl Gateway serving as the Registration Web Server. In the next step, the authentication, authorization, and assessment of unregistered end-systems will be specified.

Configuring the Unregistered ExtremeControl Profile

Now that you have created the Unregistered access policy, you can customize the Unregistered ExtremeControl Profile. The Unregistered NAC Profile is defined by default in ExtremeCloud IQ Site Engine to specify that an unregistered end-system is not assessed for security posture compliance and that it is authorized on the network with the "Unregistered" policy. Therefore, unregistered end-systems are immediately assigned to the "Unregistered" policy when connected to EOS policy-capable access layer switches without being assessed. The authentication, assessment, and authorization settings of the Unregistered NAC profile can be changed as required by your organization. When you have configured the Unregistered NAC Profile, it can be selected as the default profile for an engine group (as described in a later section) where end-systems will be required to register to the network.

To change the Unregistered NAC Profile, use the following steps.

  1. In ExtremeCloud IQ Site Engine, access the Control > Access Control tab.
  2. Expand Configuration > Profiles in the left panel.
  3. Select the Unregistered NAC Profile in the left panel.
  4. Select the desired authentication, assessment, and configuration settings.
  5. Select Save.

Configuring Policy-Based Routing

As described above, the ExtremeControl Gateway serving as the Registration Web Server must be located on a network segment directly connected to a router or routers that exist in the transmission path of all traffic from any end-system that is not registered. This is because policy-based routing (PBR) must be configured on the routers to redirect the web traffic sourced from unregistered end-systems to that ExtremeControl Gateway.

If EOS policy-enabled switches are deployed on the network, this is done by configuring policy-based routing to forward all HTTP traffic with a ToS field of 'y' to the next-hop address of the Gateway serving as the Registration Web Server. If RFC 3580-enabled switches are deployed on the network, this is done by configuring policy-based routing to forward all HTTP traffic with the source IP address on the subnet(s)/VLAN(s) associated to the Unregistered access policy, to the next-hop address of the Gateway serving as the Registration Web Server.

In addition, if you are adding multiple ExtremeControl Gateways for redundancy, the network needs to be configured for redundant policy-based routing as well.

For EOS policy-enabled Access Layer Switches

Let's consider an example where the Unregistered access policy is associated to a policy role on EOS policy-enabled switches that uses the "Allow HTTP" classification rule to assign HTTP traffic the "Web Redirection" class of service. This class of service rewrites the ToS field in the HTTP traffic to a value of 0x40 (or 64 base 10), equivalent to a DSCP value of 16. (The DSCP is the value defined in the six most significant bits of the 8-bit ToS field.) Furthermore, the Unregistered access policy is associated to VLANs 10, 20, and 30 on RFC 3580-enabled switches on the network which map to subnets 10.1.10.0/24, 10.1.20.0/24, and 10.1.30.0/24, respectively. The following steps describe how to configure policy-based routing on an N-Series router or Cisco IOS-based router when Registration is deployed for EOS policy-enabled access layer switches.

  1. Configure an entry in the access-list 102 to identify HTTP traffic with a DSCP of 16.
         access-list 102 permit tcp any any eq 80 dscp 16
  2. Use a route-map to configure the access-list 102 ACL to redirect HTTP traffic from end-systems to the next-hop IP address of the ExtremeControl Gateway serving as the Registration Web Server, where "xxx.xxx.xxx.xxx" is the IP addresses of the Gateway. Note that multiple next hop IP addresses can be specified in the route-map if multiple Gateways are serving as Registration Web Servers.
         route-map 101
         match ip address 102
         set next-hop xxx.xxx.xxx.xxx
  3. Apply the route map for the PBR configuration to the routed interface receiving the HTTP traffic from unregistered end-systems by entering the routed interface configuration prompt and executing the following command.
         ip policy route-map 101

For RFC 3580-compliant Access Layer Switches

Let's consider an example where the Unregistered access policy is associated to VLANs 10, 20, and 30 on RFC 3580-enabled switches on the network which map to subnets 10.1.10.0/24, 10.1.20.0/24, and 10.1.30.0/24, respectively. The following steps describe how to configure policy-based routing on an N-Series router or Cisco IOS-based router when Registration is deployed for RFC 3580-compliant access layer switches.

  1. Configure an entry in the access-list 102 to identify HTTP traffic sourced from subnets 10.1.10.0/24, 10.1.20.0/24, and 10.1.30.0/24.
         access-list 102 permit tcp 10.1.10.0.0.0.0.255 any eq 80
         access-list 102 permit tcp 10.1.20.0.0.0.0.255 any eq 80
         access-list 102 permit tcp 10.1.30.0.0.0.0.255 any eq 80
  2. Use a route-map to configure the access-list 102 ACL to redirect HTTP traffic from end-systems to the next-hop IP address of the ExtremeControl Gateway serving as the Registration Web Server, where "xxx.xxx.xxx.xxx" is the IP addresses of the Gateway. Note that multiple next hop IP addresses can be specified in the route-map if multiple Gateways are serving as Registration Web Servers.
         route-map 101
         match ip address 102
         set next-hop xxx.xxx.xxx.xxx
  3. Apply the route map for the PBR configuration to the routed interface receiving the HTTP traffic from unregistered end-systems by entering the routed interface configuration prompt and executing the following command.
         ip policy route-map 101

Setting up Redundancy on ExtremeControl Gateways

When adding multiple ExtremeControl Gateways for redundancy, the network needs to be configured for redundant policy-based routing as well. This is performed on the router in which policy-based routing is configured. Use the same commands described in the previous two sections except for the two following changes:

  • In step 2, in addition to the single IP address set as the next-hop IP address, enter a list of IP addresses of the redundant Gateways. For example:
         set next-hop xxx.xxx.xxx.xxx xxx.xxx.xxx.xxx xxx.xxx.xxx.xxx
  • In step 3, when adding the ip policy route-map to the router interface, specify an additional command called "ip policy pinger on". This command attempts to ping the first IP address that is specified in the next-hop to determine its availability. If it is not available, the next IP in the list of next-hops will be pinged and then used, if it is available.
    • For example:
         ip policy route-map 101
         ip policy pinger on

With policy-based routing and the Unregistered NAC Profile configured, Registration settings can be specified and then enabled on the network, as described in the next section.

Configuring the Access Control Tab (for ExtremeControl Gateways and Controllers)

Perform the following steps when you are deploying Registration in a network that utilizes ExtremeControl Gateway engines and/or Layer 2 ExtremeControl Controllers. (Registration is not supported on Layer 3 Controller engines.)

Use the Configuration section of the Access Control tab left-panel menu to configure parameters for the Registration web pages served from the ExtremeControl engine. All ExtremeControl engines are initially assigned a default portal configuration. Use this tab to view and edit the default configuration or create new configurations. When you define your portal configuration, enforce the Access Control configuration to your engine(s).

Use the following steps to define your portal configuration and enforce it to the engine:

  1. In ExtremeCloud IQ Site Engine, access the Control > Access Control tab.
  2. In the left panel, expand the Configuration section and select Captive Portals.
  3. Select an existing captive portal and select Edit or select Add to create a new portal.
  4. Select the portal configuration settings for your network using the Network Settings, Administration, and Website Configuration tabs, available in the left panel:
    1. Network Settings — view network web page parameters. These parameters are shared by both the Remediation and the Registration web pages. Be aware that if you deploy both the assessment/remediation and registration features, any changes will affect the web pages for both features.
    2. Administration — configure settings for the registration administration web page and grant access to the page for administrators and sponsors.
    3. Website Configuration — configure Guest Settings, Authentication Settings, Survivable Registration, and Assessment/Remediation. Additionally, use this to configure the Look & Feel of the website.
  5. When you have finished making your changes to the portal configuration, select Save.
  6. Enforce the Access Control configuration to the engine group.
  7. To exempt certain end-systems or end users from having to register to the network, you can configure end-system groups based on authentication type, MAC address, or user name. For example, an end-system group for the MAC OUI of the printer vendor for the network can be configured to exempt printers from having to register for network access.

Registration is now enabled for all end-systems connecting to this engine group, with the exception of those end-systems and end users that have been exempted based on group membership.

Related Information

For information on related help topics: