Wireless LAN 8100 Identity Engines - Avaya

Wireless LAN 8100

Identity Engines

Engineering

> Bring Your Own Device Technical Configuration Guide

Avaya Networking Solutions Document Date: April, 2012 Document Number: NN48500-636 Document Version: 1.0

Avaya Inc. –External Distribution 2

avaya.com

August 2011

© 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: http://www.avaya.com/support 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, HTTP://SUPPORT.AVAYA.COM/LICENSEINFO/ 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: http://support.avaya.com/Copyright.

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: http://www.avaya.com/support

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 1-800-242-2121 in the United States. For additional support telephone numbers, see the Avaya Web site: http:// www.avaya.com/support.


avaya.com

August 2011

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/2012 .02 S. Atkins Initial draft

2 4/2/2012 1.0 S. Atkins Final version


avaya.com

August 2011

Table of Contents Figures .......................................................................................................................................................... 5

1. Introduction ........................................................................................................................................... 7

1.1 BYOD Profiles ............................................................................................................................... 7

1.2 Design Restrictions ....................................................................................................................... 8

1.3 Architecture ................................................................................................................................... 9

1.4 Prerequisites and Requirements ................................................................................................. 11

2. Configuration ....................................................................................................................................... 12

2.1 Configure WLAN 8100 ................................................................................................................ 12

2.2 Configure Identity Engines and VSAs ......................................................................................... 31

2.3 Configure Access Policies on Identity Engines ........................................................................... 45

2.4 Alternative Access Policies ......................................................................................................... 60

3. Summary ............................................................................................................................................. 61

4. Reference Documentation .................................................................................................................. 63


avaya.com

August 2011

Figures Figure 1 – BYOD Architecture ..................................................................................................................... 10


avaya.com

August 2011

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:

ERS5520-48T# show running-config

Output examples from Avaya devices are displayed in a Lucida Console font: ERS5520-48T# show sys-info

Operation Mode: Switch

MAC Address: 00-12-83-93-B0-00

PoE Module FW: 6370.4

Reset Count: 83

Last Reset Type: Management Factory Reset

Power Status: Primary Power

Autotopology: Enabled

Pluggable Port 45: None




Base Unit Selection: Non-base unit using rear-panel switch

sysDescr: Ethernet Routing Switch 5520-48T-PWR

HW:02 FW:6.0.0.10 SW:v6.2.0.009

Mfg Date:12042004 HW Dev:H/W rev.02


avaya.com

August 2011

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 wide-area VPN access is allowed for email 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 Email, 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 email and documents on their mobile device. This usage profile is also often used even within the campus and


avaya.com

August 2011

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 email 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 email 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 802.11b 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


avaya.com

August 2011

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 802.11g to 802.11n support. Even when devices appear to support the latest capabilities, such as advertising 802.11n support, capabilities still vary widely. For example, Apple iPads do offer 802.11n 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.


avaya.com

August 2011

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 per-session 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


avaya.com

August 2011

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 1.1.0.133 installed.

• Avaya WLAN AP 8120s running the same version as the WC

• Avaya Identity Engines version 7.0.1 or 7.0.2

• Avaya Ignition Dashboard release 7.0.1 or 7.0.2 (matching the Ignition Server version)

• Avaya Ethernet Routing Switch 5520 for PoE support of APs.


avaya.com

August 2011

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 8100 1 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.


avaya.com

August 2011

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.


avaya.com

August 2011

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


avaya.com

August 2011

WC8180# conf t

Enter configuration commands, one per line. End with CNTL/Z.

WC8180(config)# interface vlan 4

WC8180(config-if)# ip address 192.168.4.2 255.255.255.0 2

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.


avaya.com

August 2011

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


avaya.com

August 2011

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.


avaya.com

August 2011

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.


avaya.com

August 2011

Under Configuration, Mobility Domains, right-click on the <domain_name>, select Edit Settings.

Check AP Client QoS Mode and click Save.


avaya.com

August 2011

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.


avaya.com

August 2011

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


avaya.com

August 2011

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


avaya.com

August 2011

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 802.11 Security Mode.


avaya.com

August 2011

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.


avaya.com

August 2011

9 Configure a Captive Portal Profile

Click Configuration, Mobility Domains, <domain_name>, Policy, Captive Portal, Profiles.

Click Add.


avaya.com

August 2011

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.


avaya.com

August 2011

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 drop-down box. Click Add.


avaya.com

August 2011

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


avaya.com

August 2011

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.


avaya.com

August 2011

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.


avaya.com

August 2011

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”.


avaya.com

August 2011

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.


avaya.com

August 2011

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”.


avaya.com

August 2011

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.


avaya.com

August 2011

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.


avaya.com

August 2011

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”.


avaya.com

August 2011

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 8180.

Click Site <#>, Site Configuration, Provisioning, Vendors/VSAs. Click on the Actions button then select New Vendor.


avaya.com

August 2011

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.


avaya.com

August 2011

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.


avaya.com

August 2011

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.


avaya.com

August 2011

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.


avaya.com

August 2011

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


avaya.com

August 2011

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.


avaya.com

August 2011

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.


avaya.com

August 2011

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


avaya.com

August 2011

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.


avaya.com

August 2011

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.


avaya.com

August 2011

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.


avaya.com

August 2011

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


avaya.com

August 2011

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.


avaya.com

August 2011

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.


avaya.com

August 2011

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.


avaya.com

August 2011

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.


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.


avaya.com

August 2011

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.


avaya.com

August 2011

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.


avaya.com

August 2011

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”.


Ensure your list has the same order as below. If not, use the arrow buttons to move the individual rules up and down accordingly.


avaya.com

August 2011

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.


avaya.com

August 2011

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.


avaya.com

August 2011

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.


avaya.com

August 2011

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.


avaya.com

August 2011

Implicit BYOD support

1) Rule 1: Match corporate devices. Corporate devices (or corporate device type OUI) are defined in the local store of Identity Engines.

2) Rule 2: Match guest users: Guest users are identified by username/group.

3) Rule 3: Implicit match for all other devices, and assigned BYOD profile.

Eliminating rule 3 would serve to essentially deny authentication from any non-approved device, so this approach could be used to attempt to deny use of BYODs. Alternatively, modifying rule 3 to place all other devices in the guest VLAN can serve to allow BYOD use, but give them the lowest possible trust, that is, Internet access only just like other guest users.

Explicit BYOD support with bulk corporate device authorization

1) Rule 1: Match BYOD devices. BYOD devices (or OUI wildcard list) are defined in the local store of Identity Engines. BYOD policy is applied for matches.

2) Rule 2: Match corporate users. Support is implicit by not matching rule 1 and having a valid corporate user account. Additionally security is improved if this rule incorporates matching an OUI of common corporate owned devices, like “Dell laptops”, “HP printers”, etc.

3) Match guest users. Guest users are identified by username/group.

Avaya’s Identity Engines supports bulk import for ease of provisioning large amounts of records gathered by automated device auditing process. This will allow you to implement the level of granularity of security policy without making the configuration overly cumbersome.

More BYOD Options with Identity Engines Release 8.0

• This Technical Configuration Guide is based on Identity Engines release 7.0

• Identity Engines release 8.0 offers additional BYOD access control capabilities with the new Ignition Access Portal.

• The Ignition Access Portal serves as a Captive Portal for both wired and wireless users with the capabilities to profile devices and automate creation of device records. This allows organization to automatically profile devices by identifying if for example a device is an iPad with its specific OS version, automatically create a device record with the device MAC address and associate it with the user.

• Hence, more alternatives for Access Policies are available such as basing access rules on authenticating users and allowing only Androids, Blackberry, or iPads with specific OS versions.

3. Summary Creating a policy for allowing and supporting BYOD devices is a requirement in today’s business environment. Determining the right level of access for employees and their devices is something every enterprise has to decide for itself, based on risk assessment, convenience, and support requirements. Implementing the policy so that network devices can enforce the IT security policy should be easy with the flexibility and security capabilities that Avaya’s WLAN 8100 series and Identity Engines provides collectively. This guide, while not comprehensive or exhaustive with respect to all the possibilities, attempts to show how such a policy can be configured.


avaya.com

August 2011


avaya.com

August 2011

4. Reference Documentation

Publication Number Description

NN48500-615 Ignition Guest Management for Wireless LAN 8100 Technical Configuration Guide

© 2010 Avaya Inc. All Rights Reserved.

Avaya and the Avaya Logo are trademarks of Avaya Inc. and are registered in the United States and other countries. All trademarks identified by ®, TM or SM are registered marks, trademarks, and service marks, respectively, of Avaya Inc. All other trademarks are the property of their respective owners. Avaya may also have trademark rights in other terms used herein. References to Avaya include the Nortel Enterprise business, which was acquired as of December 18, 2009.

Date post:	12-Feb-2022
Category:	Documents
Upload:	others
View:	3 times
Download:	0 times

Wireless LAN 8100 Identity Engines - Avaya

Documents