Today we’re going to talk about what I think is one of the more important differentiators of Enterasys wireless. They like to call it Flexible SSID, or some variation there of. Simply put, it’s the ability to use a single SSID across and organization and grant different levels of access based on a variety of factors. These can include location, user, active directory group, operating system, just to name a few.

In this example I’m going to show you the basics of how to configure a system that supports different types of users across multiple locations. These locations have totally disparate network configurations, and we’ll be polling Active Directory to determine a user’s level of access. To make this possible we need only need 2 things; an Enterasys wireless controller, and an Active Directory backed Radius Server. So here’s a layout of our network.

In our network we have 3 type of users; staff, students, and guests. For the purposes of this exercise, we’re going to put each of these user types into their on VLAN. Since we also have 2 locations with different network topologies, each site will have unique VLANs for each user type.

• Building 1
  • Guest: 101
  • Students: 102
  • Staff: 103
• Building 2
  • Guest: 201
  • Students: 202
  • Staff: 203

Before we get into the nitty gritty, I should explain how this all works. First, a user connects to our SSID. After connecting they will be given the access needed to get a DHCP assignment, resolve DNS, and access the Captive Portal we’re going to use for authentication. From there, any web session they try and establish will be captured by the controller and redirected to a Captive Portal Page. After providing their credentials, Radius will provide either a reject or accept response. Assuming the user provided valid credentials, the response from Radius will contain two Radius Attributes that indicate to the controller what Role and Topology to apply. In other words, the level of access and VLAN the user needs.

First, let’s configure the wireless controller. We need an SSID, a role for each of our user types, and a topology for each user type and location pair. In addition, we need a topology and role for unauthenticated users. These will be used to provide the necessary access to connect to the network.

To create the pieces need for Captive Portal authentication, it’s easiest to use the built-in wizard. So login to your controller, go to VNS Configuration > New > Start VNS Wizard. Choose the following options as you go:

• Catogory: Captive Portal
• Authenticaion Mode: Internal Captive Portal
• Mode: Bridge Traffic Locally at HWC

The IP, VLAN, Radius, and encryption settings are going to be specific to your environment. I leave the Filtering at defaults and change it later. Once it’s created, you’ll need to add DNS/DHCP access to the non-authenticated role associated with our new VNS.

We also need to make sure the SSID will send all the needed info to the Radius Server. Go to VNS Configuration > WLAN Services > Your new WLAN > Auth & Acct > Radius TLVs. Select VNS Name, AP Name, SSID, and Replace Called Station ID with Zone name in RADIUS Requests (I’ll explain this later).

Now we need to create Roles for each of the user groups. Go to VNS Configuration > Roles > New. Create a Role for each group type with your desired access, you can also apply a Class of Service here if you want.

Next, we need Topologies. For this scenario we need six new topologies, one for each VLAN we want to use. Go to VNS Configuration > Topologies > New. Create a topology for each VLAN you desire, set it to Tagged and Bridge Traffic Locally at AP options.

We also need to configure one Global option to allow Radius to set the Role and Topology. Go to VNS Configuration > Global > Authentication, then select the RFC 3580 (ACCESS-ACCEPT) Options. Make sure your set to Both RADIUS Filter-ID and Tunnel-Private-Group-ID attributes.

Last, we need to configure the location of each AP so that they can tell Radius where the user is. This is accomplished with a property of each AP called Zone. Go to Wireless Aps > Select an AP (or use multi-edit), then define your Zone. You’ll note there is a spot here for Location, but there doesn’t appear to be a way to send that to Radius.

That should be it for the Wireless Controller side of things. Now we’ll move onto the Radius server.

I’m using a Windows Server 2012 R2 box with the NPS Role installed. First, you’ll need to make sure you add your wireless controller as a Client. Once you’ve completed that, right-click Network Policies and select New. Use the following options to create your policy.

1. User Group you want to assign this Role/VLAN to
2. Case-sensitive name of the SSID
3. Zone of the AP the user is connected to
4. Tells the controller what kind of response we’re sending
5. Specifies the VLAN for the NPC Policy
6. Tells the controller we’re sending a VLAN ID
7. Specifies the Role we’re going to assign to this user (case-sensitive)

Rinse and Repeat for all of your VLAN/Role pairs. That should be it, now you can deploy a single SSID across your organization while providing multi-tier access and a single experience at each site.

There are a few limitations to this that should be noted. You can’t mix encrypted, unencrypted, and 802.1x networks. Each of those would require a separate SSID. You also can’t specify different timeouts for different users with this method. Unfortunately, that too requires a separate SSID. I’m hoping that Enterasys will eventually add the ability to send a timeout value through Radius as well.

So there you have it, I haven’t seen any other product that can be quite that flexible with a single SSID. Not only did we change access levels, and VLANs, but we also changed topology from bridged at the controller to the AP. Pretty slick if you ask me.