> Bring Your Own Device Technical Configuration Guide. Wireless LAN Identity Engines. Engineering. Avaya Networking Solutions

Transcription

1 Wireless LAN 8100 Identity Engines Engineering > Bring Your Own Device Technical Configuration Guide Avaya Networking Solutions Document Date: April, 2012 Document Number: NN Document Version: 1.0

2 2010 Avaya Inc. All Rights Reserved. Notices While reasonable efforts have been made to ensure that the information in this document is complete and accurate at the time of printing, Avaya assumes no liability for any errors. Avaya reserves the right to make changes and corrections to the information in this document without the obligation to notify any person or organization of such changes. Documentation disclaimer Avaya shall not be responsible for any modifications, additions, or deletions to the original published version of this documentation unless such modifications, additions, or deletions were performed by Avaya. End User agree to indemnify and hold harmless Avaya, Avaya s agents, servants and employees against all claims, lawsuits, demands and judgments arising out of, or in connection with, subsequent modifications, additions or deletions to this documentation, to the extent made by End User. Link disclaimer Avaya is not responsible for the contents or reliability of any linked Web sites referenced within this site or documentation(s) provided by Avaya. Avaya is not responsible for the accuracy of any information, statement or content provided on these sites and does not necessarily endorse the products, services, or information described or offered within them. Avaya does not guarantee that these links will work all the time and has no control over the availability of the linked pages. Warranty Avaya provides a limited warranty on this product. Refer to your sales agreement to establish the terms of the limited warranty. In addition, Avaya s standard warranty language, as well as information regarding support for this product, while under warranty, is available to Avaya customers and other parties through the Avaya Support Web site: Please note that if you acquired the product from an authorized reseller, the warranty is provided to you by said reseller and not by Avaya. Licenses THE SOFTWARE LICENSE TERMS AVAILABLE ON THE AVAYA WEBSITE, ARE APPLICABLE TO ANYONE WHO DOWNLOADS, USES AND/OR INSTALLS AVAYA SOFTWARE, PURCHASED FROM AVAYA INC., ANY AVAYA AFFILIATE, OR AN AUTHORIZED AVAYA RESELLER (AS APPLICABLE) UNDER A COMMERCIAL AGREEMENT WITH AVAYA OR AN AUTHORIZED AVAYA RESELLER. UNLESS OTHERWISE AGREED TO BY AVAYA IN WRITING, AVAYA DOES NOT EXTEND THIS LICENSE IF THE SOFTWARE WAS OBTAINED FROM ANYONE OTHER THAN AVAYA, AN AVAYA AFFILIATE OR AN AVAYA AUTHORIZED RESELLER, AND AVAYA RESERVES THE RIGHT TO TAKE LEGAL ACTION AGAINST YOU AND ANYONE ELSE USING OR SELLING THE SOFTWARE WITHOUT A LICENSE. BY INSTALLING, DOWNLOADING OR USING THE SOFTWARE, OR AUTHORIZING OTHERS TO DO SO, YOU, ON BEHALF OF YOURSELF AND THE ENTITY FOR WHOM YOU ARE INSTALLING, DOWNLOADING OR USING THE SOFTWARE (HEREINAFTER REFERRED TO INTERCHANGEABLY AS "YOU" AND "END USER"), AGREE TO THESE TERMS AND CONDITIONS AND CREATE A BINDING CONTRACT BETWEEN YOU AND AVAYA INC. OR THE APPLICABLE AVAYA AFFILIATE ("AVAYA"). Copyright Except where expressly stated otherwise, no use should be made of the Documentation(s) and Product(s) provided by Avaya. All content in this documentation(s) and the product(s) provided by Avaya including the selection, arrangement and design of the content is owned either by Avaya or its licensors and is protected by copyright and other intellectual property laws including the sui generis rights relating to the protection of databases. You may not modify, copy, reproduce, republish, upload, post, transmit or distribute in any way any content, in whole or in part, including any code and software. Unauthorized reproduction, transmission, dissemination, storage, and or use without the express written consent of Avaya can be a criminal, as well as a civil offense under the applicable law. Third Party Components Certain software programs or portions thereof included in the Product may contain software distributed under third party agreements ("Third Party Components"), which may contain terms that expand or limit rights to use certain portions of the Product ("Third Party Terms"). Information regarding distributed Linux OS source code (for those Products that have distributed the Linux OS source code), and identifying the copyright holders of the Third Party Components and the Third Party Terms that apply to them is available on the Avaya Support Web site: Trademarks The trademarks, logos and service marks ("Marks") displayed in this site, the documentation(s) and product(s) provided by Avaya are the registered or unregistered Marks of Avaya, its affiliates, or other third parties. Users are not permitted to use such Marks without prior written consent from Avaya or such third party which may own the Mark. Nothing contained in this site, the documentation(s) and product(s) should be construed as granting, by implication, estoppel, or otherwise, any license or right in and to the Marks without the express written permission of Avaya or the applicable third party. Avaya is a registered trademark of Avaya Inc. All non-avaya trademarks are the property of their respective owners. Downloading documents For the most current versions of documentation, see the Avaya Support. Web site: Contact Avaya Support Avaya provides a telephone number for you to use to report problems or to ask questions about your product. The support telephone number is in the United States. For additional support telephone numbers, see the Avaya Web site: 2

3 Abstract The Technical Configuration Guide will describe Avaya s Bring Your Own Device solution as well as detail how to create a simple configuration of the WLAN 8100 and Identity Engines products. Together these two products provide a solution that differentiates both the user and device when authenticating and applying access policies. Acronym Key Throughout this guide the following acronyms will be used: BYOD Bring Your Own Device AP Access Point WC Wireless Controller SSID Service Set Identifier MIMO Multiple Input, Multiple Output AAA Authentication, Authorization, and Accounting ACL Access Control List CLI Command Line Interface webui Web User Interface DHCP Dynamic Host Configuration Protocol MAC Medium Access Control OUI Organizationally Unique Identifier Revision Control No Date Version Revised By Remarks 1 2/24/ S. Atkins Initial draft 2 4/2/ S. Atkins Final version 3

4 Table of Contents Figures Introduction BYOD Profiles Design Restrictions Architecture Prerequisites and Requirements Configuration Configure WLAN Configure Identity Engines and VSAs Configure Access Policies on Identity Engines Alternative Access Policies Summary Reference Documentation

5 Figures Figure 1 BYOD Architecture

6 Conventions This section describes the text, image, and command conventions used in this document. Symbols Tip Highlights a configuration or technical tip. Note Highlights important information to the reader. Warning Highlights important information about an action that may result in equipment damage, configuration or data loss. Text Bold text indicates emphasis. Italic text in a Courier New font indicates text the user must enter or select in a menu item, button or command: ERS T# show running-config Output examples from Avaya devices are displayed in a Lucida Console font: ERS T# show sys-info Operation Mode: Switch MAC Address: B0-00 PoE Module FW: Reset Count: 83 Last Reset Type: Management Factory Reset Power Status: Primary Power Autotopology: Enabled Pluggable Port 45: None Pluggable Port 46: None Pluggable Port 47: None Pluggable Port 48: None Base Unit Selection: Non-base unit using rear-panel switch sysdescr: Ethernet Routing Switch T-PWR HW:02 FW: SW:v Mfg Date: HW Dev:H/W rev.02 6

7 1. Introduction The Bring Your Own Device (BYOD) trend has forced IT departments to support devices that employees are bringing to work, whether they are prepared or not. In most cases employees have already been using these devices on enterprise networks without the knowledge of the IT staff. Usage may range anywhere from a smartphone with Wi-Fi connecting to the enterprise guest SSID to a tablet device connecting to the secure corporate SSID and making use of corporate video conferencing and telephony applications (softclients). The question is not whether IT should or should not approve, but rather what policies and controls will be put in place to ensure the enterprise network will not be compromised as a result. Avaya s BYOD solution is aimed at allowing IT to regain control over this environment in such a way that intelligent policies can be applied that limit access and reduce the risk imposed by these devices. The vast majority of devices that are categorized as BYOD are wireless devices that have no Ethernet port or easy way of connecting via wire. This means that the two main ways that BYOD is accessing the corporate network are via cellular wireless data (2G/3G/4G/etc) over the Internet, perhaps with VPN, and on campus via Wi-Fi. Therefore, Avaya s BYOD solution primarily focuses on two products: WLAN 8100 and Identity Engines. WLAN 8100 provides the Wi-Fi access to wireless devices, and Identity Engines provides the policy based authentication and authorization of users and devices. This document does not cover the wide-area access over cellular/vpn, though similar configurations would apply to the VPN concentrator as an access device, and Identity Engines would apply similar policies. 1.1 BYOD Profiles Before discussing application and configuration it is important to classify and understand the risks involved with BYOD. There are three main usage profiles to consider. Understanding the usage needs of employees will better help you provide the access they need while maintaining security of the network and company assets. While there are variations of these three, these are meant to be viewed as a nested series of increasing rights and permissions, so you can construct policies in a similar manner. This document is not intended to define IT policy only the IT department can do that. You can use these categories to determine what level of access will be permitted. For example, if it is desired that only widearea VPN access is allowed for and documents, even when users are on campus (meaning corporate users cannot access the corporate Wi-Fi at all from BYOD devices) this can easily be implemented. Wide-Area VPN Access Many users, especially teleworkers and road-warriors seek only to gain access to certain company resources from outside the corporate network. They are using their wireless carrier s data network to access the Internet, and from there access applications like , Sharepoint, or other data resources. Since most wireless carriers separate wireless data and wireless voice and do not provide QoS on the data network, enterprise telephony over wireless data networks is problematic. Securing wide-area access of to company assets is not different from any other Internet VPN access solution and is therefore beyond the scope of this document. Components involved would be VPN termination (or concentrator) products (such as Avaya s Secure Router product line), an AAA server (such as Avaya s Identity Engines), and a firewall. This usage profile is mentioned strictly because many BYOD users simply desire the ability to get and documents on their mobile device. This usage profile is also often used even within the campus and 7

8 has pre-dated the BYOD phenomenon, for example, employees with older Blackberry devices that had no Wi-Fi radio. Local-Area Internet Access Users who own iphone or Android devices, may simply want to connect to the Internet over Wi-Fi to download that latest game which requires Wi-Fi due to size. Or a better business related application may be that they have the Wi-Fi radio enabled so that whenever access is available, their phone uses free Wi- Fi for access to corporate instead of counting against their cellular data plan. If your enterprise offers a guest Wi-Fi SSID that puts users outside the company firewall, you may be surprised (or not) to discover that many of your employees are already using it on their BYOD devices. If all they want to do is download the latest Angry Birds application, then likely your BYOD policy simply needs to enforce this as the only allowed means of accessing the Internet. Specifically, this means implementing a policy that disallows the next usage profile, i.e. use of the corporate secure SSID from BYOD devices. Note that local-area Internet access can also be a means of providing the same level of access as the previous profile (wide-area VPN access). A user who seeks to connect to the company servers will still be accessing the company network from outside the network, using VPN or whatever means are required for access over the Internet. In other words, BYOD devices are still external to the corporate LAN, therefore they access corporate resources the same way as any other device over the Internet. Local-Area Access with Business Applications Other users have need for direct access to corporate resources over Wi-Fi. Since guest SSIDs are usually unencrypted, accessing internal resources from an unsecure SSID may not be the best option. Even with use of VPN to secure communications, the device itself is exposed to other threats from the unsecure guest SSID. Also, leaving them on the outside of the corporate firewall leaves them exposed to other external threats. It may be more desirable to give them some level of access through the corporate secure SSID, requiring secure user authentication as well as device identification. This raises another topic of concern for BYOD solutions. When allowing secure access to devices that aren t running IT approved firewall applications or that may not have up to date security patches installed, how do you limit their ability to infect your other secure devices? Ideally, you may want to still isolate these into a quarantine area of your LAN, and limit access based on VLAN. 1.2 Design Considerations and Restrictions There are a few criteria that are important to consider when designing networks. Multiple SSIDs One common approach for offering multiple services or supporting devices that have different security capabilities, is to create a different SSID for each. This leads to numerous SSIDs per access point (AP). This has many unintentional side effects that are detrimental. Each SSID broadcasts a beacon every 100ms by default. This beacon is transmitted at the lowest supported data rate, so if you support b clients, this beacon is probably transmitted at 1 or 2 Mbps. Wi-Fi is half-duplex, so slow transmissions consumes a large amount of throughput, or more specifically takes away time that could be used by much higher rate transmissions. Therefore, each SSID adds a significant amount of overhead on the channel. Avaya recommends that you use as few SSIDs as possible and no more than 5. In the past with user device capabilities being so varied, you might have some that only supported WEP, other that were only capable of PSK authentication, and still others with full WPA2 support. Fortunately most BYOD devices 8

9 are capable of the latest security standards, i.e. WPA2 with 802.1x for authentication, so you don t have to create special SSIDs just for BYOD devices. Multiple VLANs It is a common security practice to segment devices into different VLANs, such as voice and data. It is also common to map different SSIDs to different VLANs. However, many products, including Avaya s WLAN 8100, are capable of using AAA to assign different devices and/or users to separate VLANs, even though they are part of the same SSID. Avaya recommends that you have separate VLANs for guest, secure, and insecure devices and assign users and devices to them as appropriate based on AAA policy. The guest SSID should map to a VLAN that is separated from the rest of the corporate LAN by a firewall. Throughput One of the issues with any Wi-Fi network is how to offer high performance for devices that can support it, while also offering legacy support for slower devices. One common approach is to separate devices by channel, for example, using 5 GHz for high performance, and 2.4 GHz for low performance. BYOD devices have a wide array of radio capabilities, from g to n support. Even when devices appear to support the latest capabilities, such as advertising n support, capabilities still vary widely. For example, Apple ipads do offer n support, but what is not mentioned is that they are only capable of single stream MIMO. Avaya recommends that you thoughtfully consider BYOD device capabilities used within your organization and try to separate them into high performance and low performance groups. High performance should use 5 GHz and low performance should use 2.4 GHz. Further recommendations on how to segment devices into different bands is beyond the scope of this document. 1.3 Architecture Avaya s BYOD architecture, illustrated in Figure 1, has three discrete levels of access: guest and two categories of authorized users using either secure (aka managed) devices or insecure (aka unmanaged) devices. In this architecture, Avaya s Identity Engines product performs the authentication and authorization services required to handle guest, employee, and device authentication, and Avaya s WLAN 8100 provides the Wi-Fi services and implements security. This Technical Configuration Guide is based on Identity Engines release 7.0 and does not leverage the new BYOD capabilities introduced by Identity Engines release 8.0 provided by the Ignition Access Portal, BYOD Device Profiling, and BYOD VSAs introduced to provide even greater flexibility for BYOD access control, on-boarding and management. Guest It is assumed that your organization offers guest Wi-Fi services to customers and/or business partners. If your organization does not, then you can skip this option. The guest SSID will be unencrypted in most cases, and should map to a VLAN that is outside the corporate firewall or in a DMZ. There are many options for managing a guest Wi-Fi service, ranging from a simple open SSID with no portal, to a simple portal with simple username/password access, to dynamically created guest accounts for each user that expire at the end of a specified time period. Avaya s Identity Engines supports best in class capabilities for guest account creation and access management, but configuration of Identity Engines Ignition Guest Manager and these options is beyond the scope of this document. The configuration examples will only show a simple portal-based authentication for guest authentication. 9

10 Figure 1 BYOD Architecture Authorized User on Insecure Device A second SSID is created for secure access and will use WPA2 and 802.1x for authentication. WLAN 8100 will refer to Identity Engines as the AAA server for authentication of all WLAN clients. Identity Engines will make Authentication and Authorization decisions based on user and device credentials. The heart of the BYOD solution is designed to differentiate between an authenticated user on an approved secure device vs, an authenticated user on an approved unsecure device. Note: a third category can also be created for authenticated users on unknown or unapproved devices, but this is strictly optional and not shown in the configuration examples. Once the user and device have been authenticated, Identity Engines returns an accept/deny response to WLAN 8100 along with additional information about what VLAN to use or ACL to apply to the session. In this solution, authorized users on insecure devices will be mapped to a separate VLAN. Access controls should be applied to these sessions, restricting access to only certain applications and resources. Avaya recommends that a firewall be used for this purpose, but WLAN 8100 is capable of implementing persession ACLs. These ACLs are applied at the AP so even client to client communication via the same AP will have this ACL applied to it. Authorized User on Secure Device The last group is for employees using traditional IT supplied computing assets that comply with corporate security requirements. For reasons explained earlier (minimizing the number of SSIDs), a common secure SSID using WPA2 and 802.1x is used for this as well as for BYOD devices. Identity Engines will recognize the secure device and make the same accept/deny response to WLAN 8100 and provide the 10

11 VLAN mapping. WLAN 8100 will map the device to a VLAN that is separate from BYOD devices. There will be no ACL or firewall applied to these WLAN client sessions, as access will not be restricted. Note: Some organizations do prefer to apply firewall rules to all WLAN clients regardless of authentication, or status. Avaya does not generally recommend this approach, because in common practice, WLAN access is more secure than comparable LAN access, and LAN access policies generally do not require firewalls. To be specific, WLAN is authenticated by 802.1x and secure Diffie-Helman based protocols like PEAP; the typical LAN is not authenticated, but rather depends on building security (which is fallible) to keep intruders out. WLAN is encrypted using high grade 256-bit AES ciphers which are considered uncrackable with today s technology; The typical LAN is unencrypted and depends on building security (which is fallible) and switching technology (which can be fooled by simple hacker tools) to prevent eavesdropping. Arguably, your WLAN has better security implemented than your corporate LAN, and therefore, the need for a firewall on top of that is questionable. There are also many alternative options, such as using NAP to enforce firewall use on laptops. You may want to consider deploying 802.1x based access to the LAN leveraging your deployment of Identity Engines, however this is beyond the scope of this document and other TCGs are available focusing on such deployments. 1.4 Prerequisites and Requirements This feature set assumes the following minimum requirements are met: Avaya WLAN AP 8120 Avaya WLAN Controller 8180 Avaya Identity Engines installed and running on a VMware ESXi server Avaya Ignition Dashboard installed on a Windows-based PC The configurations described in this guide used the following software and hardware versions: Laptop with Windows XP with Service Pack 3. Avaya WLAN Controller 8180 with software version installed. Avaya WLAN AP 8120s running the same version as the WC Avaya Identity Engines version or Avaya Ignition Dashboard release or (matching the Ignition Server version) Avaya Ethernet Routing Switch 5520 for PoE support of APs. 11

12 2. Configuration It is assumed that you have already setup the WLAN 8100 controller with a basic configuration and licenses, that WLAN 8100 APs are in a managed state, and that all WLAN components are running 1.1 software or later. If APs are not in a managed state please consult the WLAN 8100 Quickstart Guide to get the WLAN 8100 controller and APs properly configured. This guide starts with configuring a new VLAN for clients and network profiles (SSIDs) for BYOD and guest devices. 2.1 Configure WLAN Add VLANs You will first need to configure VLANs on the Controllers. These are the real underlying VLANs that will be trunked or untagged to the connecting switches, and which will determine the IP address (subnet) that clients ultimately receive. In other words, these are locally significant VLANs. If different controllers are separated from each other by routers, then they will obviously have different VLANs that need to be configured. Click Configuration, Mobility Domains, <domain_name>, Devices, Controllers. Click on the Controller where you will be configuring the VLAN. Click the VLAN Configuration button. In the Configuration VLAN window, click Add. Type the VLAN number and Name and click Add. 12

13 Repeat for additional VLANs. At the end of this, you should have 4 VLANs: The original system VLAN, a VLAN for secure clients, a VLAN for BYOD and a VLAN for guests. If you have more than one controller, these may be located on different controllers. This TCG only shows the configuration for a single controller. 2 Configure VLAN Port Members You will need to assign the VLAN to ports. In this configuration, port 12 is a trunk port that is already configured for tagging VLANs. The port configuration is not shown here, but would normally be performed in the CLI or Menu interface. This TCG assumes you have ports and trunks already configured and connected to other switches, and that you are just adding additional VLANs to an interface that is already configured for tagging. Without exiting the VLAN Configuration window opened in the previous step, Click the icon for adding Port Members. In the popup box, check the ports to add the VLAN. Click Save. Repeat for the other two VLANs you created, then click Save to close the VLAN Configuration window. 13

14 The final result should look something like this: 3 Configure a Routed Interface for the Guest VLAN By default, the Captive Portal is hosted on the System IP interface. Guest users can be in a different VLAN and their traffic is internally routed to the System IP when captured and redirected. While this does not actually give them access to the controller management interface, it does give the appearance that the users are being redirected to the private network. There is no real security risk, but many administrators would still prefer to have the Captive Portal hosted on an interface that is local to the guest users. This step shows how to accomplish this. Since the guest VLAN you previously created will need to host an instance of the Captive Portal, you will need to perform one additional task in the controller CLI to create a routed interface on the VLAN. On a WLAN Controller 8180, routed interfaces are not used for general routing of client traffic. Client VLANs are still treated strictly as Layer 2 forwarded VLANs. Routed interfaces are only used to capture and redirect Captive Portal sessions. So only the initial client HTTP session is captured by the routed interface, and then after authentication, client traffic is L2 forwarded. Telnet or use a console cable to access the controller CLI. From the CLI follow the commands, assuming your guest VLAN has a VLAN ID of 4. If you used a different VLAN ID and/or IP address, then adjust your configuration commands accordingly. WC8180> en 14

15 WC8180# conf t Enter configuration commands, one per line. End with CNTL/Z. WC8180(config)# interface vlan 4 WC8180(config-if)# ip address WC8180(config-if)# ip routing WC8180(config-if)# 4 Configure Mobility VLANs The purpose of a Mobility VLAN is to allow the concept of a global VLAN for wireless devices to be abstracted from the actual VLAN location. This allows several important capabilities, such as the ability to map all guest users, regardless of controller and AP location or VLAN connectivity, to a single VLAN on a controller that is outside the company firewall in a DMZ. You can use this to map certain SSIDs to a specific VLAN somewhere in the network or use AAA to assign specific clients to certain VLANs, by using globally named VLANs. These names are globally unique across the cluster of WLAN 8100 controllers in the domain. You will map them to locally unique switch VLANs in the following step. Click Configuration, Mobility Domains, <domain_name>, Policy, Mobility Profiles. Click Add. Type secure_vlan, and click Add to complete. 15

16 Repeat this process to create two more Mobility VLANs named byod_vlan and guest_vlan. The result should look something like this: 5 Map Mobility Profiles to VLANs Map these Mobility VLANs to real VLANs on the controller. If you have more than one WLAN 8100 controller, and these controllers are in different locations within the network, they can each host different named VLANs that clients get mapped to. For example, if you have a guest VLAN that you desire to have isolated from the rest of the corporate VLANs, you can have a Mobility VLAN named guest and only map it to one controller VLAN which happens to be in the DMZ of the network. When guest clients are authenticated, they are mapped to this guest VLAN and tunneled to the controller and therefore kept separate from any other clients or secure VLANs in the network. This TCG only shows one controller, so having different Mobility VLANs mapped to different controller VLANs is beyond the scope. Click Configuration, Mobility Domains, <domain_name>, Devices, Controllers. Right-click on the Controller where you will be configuring the mapping and select Edit. In the Domain Controller window and VLAN Map tab choose the Mobility VLAN from the left column and select the Local VLAN from the drop-down box. Repeat for the other three VLANs. This TCG uses the following mappings: secure_vlan VLAN2 byod_vlan VLAN3 guest_vlan VLAN4 16

17 Change the role of each of these VLANs to Server. When you select this, it will change to the numerical designation which is 2. Click Update. 17

18 The configuration should resemble this if you open the Domain Configuration / VLAN Map view again: 6 Enable Captive Portal and Client QoS Click Configuration, Mobility Domains, <domain_name>, Policy, Captive Portal, General Settings. Check Enable Captive Portal and click Update. 18

19 Under Configuration, Mobility Domains, right-click on the <domain_name>, select Edit Settings. Check AP Client QoS Mode and click Save. 19

20 7 Configure a RADIUS Profile and Server Click Configuration, Mobility Domains, <domain_name>, Policy, Local Security DB, RADIUS Profiles. Click Add. Name the profile radius_server and click Add. 20

21 Click Configuration, Mobility Domains, <domain_name>, Policy, Local Security DB, RADIUS Profiles. In the right pane, click on radius_server and then in the pane below click Add. Type the IP address of the server and RADIUS Secret 21

22 Click on the Health Check tab. Change the Interval to 0 and click Add. 22

23 8 Configure a Network Profile for Secure SSID Click Configuration, Mobility Domains, <domain_name>, Policy, Network Profiles. Click Add. Type secure as the profile name. Set the default client VLAN to the byod_vlan this will result in all clients being mapped into the quarantined BYOD VLAN unless the AAA server provides a different mapping during authentication based on device credentials. Set the SSID to secure as well. Click on the Security tab. Choose wpaenterprise as the Security Mode. 23

24 Click on the General tab again. Choose radius_server as the authentication profile for this SSID. Click on the QoS tab. Check Enable Client QoS. Click Add. 24

25 9 Configure a Captive Portal Profile Click Configuration, Mobility Domains, <domain_name>, Policy, Captive Portal, Profiles. Click Add. 25

26 Click Configuration, Mobility Domains, <domain_name>, Policy, Captive Portal, General Settings. In the Captive Portal Profiles IP Mappings pane, click Add. Select the my_captive from the Captive Portal Profile drop-down box. Type the IP address of the VLAN interface that you previously configured. Click Add. 26

27 Click Configuration, Mobility Domains, <domain_name>, Policy, Network Profiles. Click Add. Type guest for the Profile Name. Select the Default Client VLAN to be guest_vlan that was created earlier. Select RADIUS as the Captive Portal User Validation type. Type guest as the SSID. Select radius_server as the Authentication Profile. Click the Security tab. Check Enable Captive Portal. Select my_captive from the Captive Portal dropdown box. Click Add. 27

28 10 Configure DiffServ Policies (optional) If you desire to restrict access for BYOD to a limited set of services, the preferable way to implement this is through an external firewall that sits between the BYOD VLAN and the rest of the corporate network. Alternatively, the WLAN Controller 8180 is capable of applying ACL rules to individual client sessions based on a response from a AAA server, which is what is illustrated in this guide. The policies need to be created and named on the controller. You can create a different policy for upstream and downstream depending on your security requirements. Only a sample is shown. You will need to configure the rest of the ACL accordingly. Click Configuration, Mobility Domains, <domain_name>, Policy, DiffServ, Classifiers. Click Add. Name the classifier type. Click Add 28

29 Click Configuration, Mobility Domains, <domain_name>, Policy, DiffServ, Classifiers. Click on the classifier you just created in the top right pane. In the Classifier Block pane below, click Add. Select the Element Type and fill in the corresponding information based on the type selected. Click Add. 29

30 Click Configuration, Mobility Domains, <domain_name>, Policy, DiffServ, Policies. Click Add. Give the Policy a name, such as BYOD_up to denote the direction of the traffic flow the policy will be applied. Click Add. Repeat for any other policies and traffic direction. Click Configuration, Mobility Domains, <domain_name>, Policy, DiffServ, Policies. Click on one of the policies you previously created in the DiffServ Policies pane on the top right. In the Policy Classifiers pane below, click Add. Choose the classifier name from previous steps and select the Action allow from the drop-down box. Check the Action Allow box. Click Add. 30

31 Repeat process for each additional traffic type. At the end of the policy, you will need to add a match all classifier with a deny action. DiffServ Policies are L2 filters so when using them in this way with a deny all rule at the end, you will need to explicitly allow ARP, DHCP, DNS and all other traffic types necessary for basic network connectivity. 2.2 Configure Identity Engines and VSAs 1 Configure an Policy The first thing you will need to do is configure a policy for wireless access rules. This policy will contain all the rules for all wireless devices that are authenticated through RADIUS, including guest, BYOD devices, and corporate owned assets. You will add rules to this policy later. Click Site <#>, Site Configuration, Access Policies, RADIUS. In the right hand pane, click New. Provide a name for this policy. In this example, the name is Wireless. 31

32 2 Configure an Authenticator Next you will need to configure the WLAN 8100 as an Authenticator on Identity Engines. If you have more than one controller in your WLAN 8100 domain, you will need to repeat this step for each controller. Click Site <#>, Site Configuration, Authenticators, default. In the right pane, click New. Give the authenticator a name, in this case Lab, provide the IP address of the WLAN Controller 8100 (this is the wireless interface IP which is the same as the management IP address), select Nortel as the vendor, and select generic-nortel as the Device Template, check Enable RADIUS Access, and select the Access Policy configured in the previous step, Wireless. Click Ok. 32

33 4 Configure the Internal Directory store Next, you will configure user groups and device groups in the Identity Engines local directory store. Depending on whether you are passing through user credentials to another directory, like an external LDAP or Active Directory, some parts of this step may not apply. Click Site <#>, Site Configuration, Directories, Internal Store, Internal Groups. In the right hand pane, click Actions and choose Add a New Internal Group. Type Guest for the group name and click Ok. Repeat to create two more groups and name them BYOD and Corp_asset. 33

34 After you are done, the list of groups should look something like this: 4 Configure the Outbound VLAN VSAs You will need to configure Identity Engines to return VLAN names as outbound values so that it can assign users/clients to specific VLANs based on authentication. Click Site <#>, Site Configuration, Provisioning, Outbound Values. In the right pane click New. In the dialog box that appears, type the name guest_vlan and click New to define the Outbound Attribute. 34

35 In the VLAN Label field, type guest_vlan. In the VLAN ID field, type 4. The VLAN Label field must match the exact string of a Mobility Profile (also referred to as Mobility VLAN) in the WLAN 8100 domain. If Identity Engines returns a value that doesn t match a Mobility Profile name in WLAN 8100, then the client won t connect. If you use different Mobility Profile/VLAN names, then make sure you use your labels for the Outbound Attribute instead of those shown in this guide. 35

36 Click Ok. Click Ok again to return to the list of Outbound Values. Repeat the above steps to create additional Outbound Values for the secure_vlan and configure an Outbound Attribute with the label secure_vlan and VLAN ID of 2. 36

37 Repeat the above steps to create additional Outbound Values for the byod_vlan and configure an Outbound Attribute with the label byod_vlan and VLAN ID of 3. After you are finished, the list of Outbound Values should include three new entries, guest_vlan, secure_vlan, and byod_vlan, respectively. 5 Configure the DiffServ Policy VSA on Identity Engines You will need to configure Identity Engines with the VSA for returning the DiffServ Policy name to the WLAN Controller Click Site <#>, Site Configuration, Provisioning, Vendors/VSAs. Click on the Actions button then select New Vendor. 37

38 Type LVL7 as the Vendor Name, and 6132 as the Vendor ID. Click Ok. In the right hand pane, locate the new vendor name in the list, click the plus next to the LVL7 entry to expand it, and right-click VSA Definitions and choose New. 38

39 Type LVL7-Wireless-Client-Policy-Dn as the RADIUS VSA Name, and 122 as the Attribute Type. Click Ok. This attribute will carry the value of the DiffServ Policy name to apply on the client s downstream traffic. 39

40 Repeat the last step to create another VSA with the RADIUS VSA Name LVL7-Wireless-Client-Policy- Up and Attribute Type 123. Click Ok. This attribute will carry the value of the DiffServ Policy name to apply on the client s upstream traffic. 5 Configure the DiffServ Policy Outbound Attribute on Identity Engines Click Site <#>, Site Configuration, Provisioning, Outbound Attributes. In the right pane, click New. 40

41 Type LVL7-Wireless-Client-Policy-Dn as the name of the Outbound Attribute. Choose VSA and select LVL7 as the Vendor and select LVL7-Wireless-Client-Policy-Dn as the VSA. Click Ok. Repeat this step to similarly configure a new Outbound Attribute named LVL7-Wireless-Client-Policy-Up. Choose VSA and Select LVL7 as the Vendor and LVL7-Wireless-Client-Policy-Up as the VSA. Click Ok. 5 Configure the DiffServ Policy Outbound Value on Identity Engines You will now need to configure the value that will be returned by Identity Engines when this attribute is used. Click Site <#>, Site Configuration, Provisioning, Outbound Values. In the right pane, click New. 41

42 Type WLAN-Client-ACL-Dn for the Outbound Value Name. Click New. 42

43 Choose LVL7-Wireless-Client-Policy-Dn for the Global Outbound Attribute, and type BYOD_dn as the String. Click Ok. Click Ok again. The String value of this attribute must match the Diffserv Policy name in the WLAN 8100 domain. If it does not, then no policy will be applied to the client. 43

44 Repeat the previous step to create another new Outbound Value Name as WLAN-Client-ACL-Up with the Global Outbound Attribute LVL7-Wireless-Client-Policy-Up and String BYOD_up. Click Ok. Click Ok again. The String value of this attribute must match the Diffserv Policy name in the WLAN 8100 domain. If it does not, then no policy will be applied to the client. 44

45 2.3 Configure Access Policies on Identity Engines Finally, you will put all the pieces together to configure a set of policies on Identity Engines. When a device authenticates, Identity Engines traverses the Policy Rules in order until it finds a match. When a match is found, no further rules are processed and the configured action will be taken, so it is important to structure the rules from most specific to least specific. There are many ways to configure these rules for a BYOD solution. All rules assume the user has provided a valid password and authentication is successful. The solution shown has the following structure: 1. The first rule looks at the device hardware address and attempts to definitively match a corporate asset and places these in the secure VLAN. Corporate assets are explicitly listed as a device account in the Local Store of Identity Engines. 2. The second rule looks at device hardware and since the device did not match a corporate hardware address, it must be unknown. This rule attempts to match against a wildcard OUI from known approved device categories (ipad, HTC, etc). Devices that match known BYOD lists, will be assigned to the BYOD VLAN. 3. The last rule is for guests. Assuming no devices are either corporate assets or BYOD devices, the last possibility is that it is a guest device or user. This rule looks to see if the username is a member of the guest group. This allows you to implement a solution using Guest Manager that maps dynamic guest accounts to the guest group. The configuration of Guest Manager is 45

46 beyond the scope of this document, but it is assumed that guest accounts are placed in the guest group configured previously. You will now configure the Wireless policy you created earlier. 1 Configure the Authentication Policy The first step is to setup the Authentication Policy. This controls the acceptable modes of Authentication. Since you are setting up both a Captive Portal for guests and 802.1x based authentication for corporate assets and BYOD devices, you will need to allow both PEAP/EAP-MSCHAPv2 and None/PAP. You may need to enable other Authentication modes for other types of authentication depending on your exact needs. To simplify the setup and troubleshooting of your configuration, you may want to go ahead and enable all options and later turn off the ones you don t need. Click Site <#>, Site Configuration, Access Policies, RADIUS, <wireless-policy-name>. In the right pane, click on the Authentication Policy tab and click Edit. Check PEAP/EAP-MSCHAPv2 and NONE/PAP. Click Ok. 46

47 Your Authentication Policy should look something like this: 2 Configure the Policy Rule for guest access To setup this policy, you will first configure a rule for guest access. Click Site <#>, Site Configuration, Access Policies, RADIUS, <wireless-policy-name>. In the right pane click Authorization Policy. Click Edit. In the Edit Authorization Policy window, click Add to add a new rule. Type the name of the rule guest. Click Ok. 47

48 Now you will add constraints to the Guest rule. On the right hand side, click New to add a new Constraint. In the Constraint Detail window, choose group-member. Click Add on the right side and choose the Guest user group. Click Ok. Click Ok again to save the Constraint. 48

49 In the Edit Authorization Policy window, choose the Allow action, and from the list of Outbound Values, choose the guest_vlan and click the left arrow to move it to the Provision With list. Do not close this window yet, as you will be adding some additional rules in the next few steps. Guests are typically authenticated by a captive portal, which means they have already been assigned to a VLAN and have received an IP address. Using RADIUS to assign VLANs works well for WLAN authentication types that authenticate before clients are assigned to VLANs, such as WEP+802.1x, WPA-Enterprise, and WPA2-Enterprise. WLAN authentication types, like captive portal, that authenticate after clients have been assigned to a VLAN and received an IP address have a problem if the assigned VLAN differs from the current client VLAN, resulting in 49

50 the client being unable to communicate. Guests are typically authenticated by a captive portal, so the purpose of this policy is not to assign the guest to a guest VLAN, but rather to enforce the policy that guests should already be in the guest VLAN. Depending on the VLAN design of the guest service, such as if there are multiple guest VLANs, providing an outbound value for VLAN assignment may not be appropriate. Use this attribute with discretion. The resulting rule for Guest access should look like this: 3 Configure the Policy Rule for corporate device access You will now add a rule for corporate devices. It is assumed you are already in the Edit Authorization Policy window. If you are not, then Click Site <#>, Site Configuration, Access Policies, RADIUS, <wireless-policy-name>. In the right pane click Authorization Policy. Click Edit. In the Edit Authorization Policy window, click Add to add a new rule. Type the name of the rule corp_device. Click Ok. Make sure you have the new corp_device rule highlighted on the left hand list and on the right side, click New to add a new Constraint. In the Constraint Details window, choose Device from the Attribute Category list, and then below, select device-group-member. On the right side, click Add and select the group Corp_asset. Click Ok. 50

51 You will need to add another constraint to match the device ID to the Calling Station ID field. Click New to add a new Constraint. Select Inbound from the Attribute Category list, and below Inbound-Calling- Station-Id. On the right side, choose Format Treat As MAC Address, choose Dynamic Value of Attribute, then Device, and then device-address. Click Ok. 51

52 In the Edit Authorization Policy window, choose the Allow action, and from the list of Outbound Values, choose the secure_vlan and click the left arrow to move it to the Provision With list. Do not close this window yet, as you will be adding one more rules in the next step. 52

53 The resulting rule for corporate device access should look like this: 4 Configure the Policy Rule for BYOD access Finally you will configure a rule for BYOD device access. It is assumed you are already in the Edit Authorization Policy window. If you are not, then Click Site <#>, Site Configuration, Access Policies, RADIUS, <wireless-policy-name>. In the right pane click Authorization Policy. Click Edit. In the Edit Authorization Policy window, click Add to add a new rule. Type the name of the rule byod_device. Click Ok. Make sure you have the new byod_device rule highlighted on the left hand list and on the right side, click New to add a new Constraint. In the Constraint Details window, choose Device from the Attribute Category list, and then below, select device-group-member. On the right side, click Add and select the group BYOD. Click Ok. 53

54 You will need to add another constraint to match the device ID to the Calling Station ID field. Click New to add a new Constraint. Select Inbound from the Attribute Category list, and below Inbound-Calling- Station-Id. On the right side, select Starts With, select Treat As MAC Address for the Format, choose Dynamic Value of Attribute, then Device, and then device-address. Click Ok. 54

55 In the Edit Authorization Policy window, choose the Allow action, and from the list of Outbound Values, choose the secure_vlan and click the left arrow to move it to the Provision With list. Similarly, move WLAN_Client_ACL_Dn and WLAN_Clien_ACL_Up over to the Provision With list. Do not close this window yet, as you will be performing one final step. 55

56 The resulting rule for BYOD device access should look like this: 5 Order the Policy Rules The final step of configuring the Access Policy is to ensure the rules are in the correct order and that all of them are set to Allow. It is assumed you are already in the Edit Authorization Policy window. If you are not, then Click Site <#>, Site Configuration, Access Policies, RADIUS, <wireless-policy-name>. In the right pane click Authorization Policy. Click Edit. Ensure your list has the same order as below. If not, use the arrow buttons to move the individual rules up and down accordingly. 56

57 6 Create User Accounts Click Site <#>, Site Configuration, Directories, Internal Store, Internal Users. In the right pane click New. Type user-1 for the username, and to make it simple for testing, type user-1 as the password. After your configuration is working and verified, you should go back and disable or delete this account. Click Ok. Similarly, create another account with the username as guest-1 and password guest-1. Below, click Add to put this account in a group. Check Guest and click Ok. Click Ok again. 57

58 7 Create Corporate Device Accounts Click Site <#>, Site Configuration, Directories, Internal Store, Internal Devices. In the right pane click New. Type the MAC address of the corporate asset and type corp_laptop1 for the Name Below, click Add to put this account in a group. Check Corp_asset and click Ok. Click Ok again. 58

59 8 Create BYOD Accounts Click Site <#>, Site Configuration, Directories, Internal Store, Internal Devices. In the right pane click New. Type the OUI of the BYOD device you want to support with a wildcard appended and type the Name, for example, type 28:6a:ba* in the MAC Address field and ipad for the Name. Depending on the types of BYOD devices you want to support, you should provide the correct registered OUI of that device/manufacturer and corresponding name. Repeat for additional device types. This step shows the OUI of an ipad2. Below, click Add to put this account in a group. Check BYOD and click Ok. Click Ok again. 59

60 Repeat this step to add other third party devices to the list of BYOD. 2.4 Alternative Access Policies This guide shows one sample policy that may work for some enterprises, but may not represent the security requirements of others. Identity Engines has the flexibility to implement virtually any set of policies that you desire. This guide does not illustrate alternative configurations, though certainly the possibilities are limitless. Below are some alternative policies, described in high level terms, but not illustrated. 60