Wireless Access

Hi guys,

 

Airheads has been a boon for configuring our Wi-fi setup. Thanks for the great stuff. Just wanted to discuss a problem I am having with adding some more flexibility to the WLAN. We have a 650 Controller and a few AP-105's and a couple of AP-93H's. Firmware is 6.1.3.4. Currently we have two SSID's one for Corporate and one for guests.

 

a) Corporate: Authentication is PEAP and each user is authenticated to MS-NPS which returns a FILTER-ID to identify the users vlan  after which the controller assigns a role using Server Derivation rules. (for e.g. a third floor user is assigned a role of "Third-Floor-Vlan-Role" which assigns him IP from the 3rd floor vlan and whereever he roams in the building, he would still get access like he was sitting in his cubicle.)   Devices: Laptops

 

b) Guest: Guests authenticate via a Captive Portal and are assigned to the Guest Vlan where they have only internet access. Devices: Any guest device | laptop or mobiles etc.

 

 

Now there is a third variable we want to add. We want that Corporate mobile devices like Apple iPads etc owned by employees are assigned a specific VLAN where they only get access to the Lotus Server in the DMZ and internet. They don't get access to the rest of the network.  Something like this:

 

User ->  Connects to Corporate SSID -> Logs in with Radius_Credentials -> Aruba checks device type if matching with User role -> Assigns role depending on device (Laptops=He gets the role returned in FILTER_ID from the Radius server | Mobile=He is assigned to the mobile vlan irrespective of the role returned from the radius)

 

For this I thought of using DHCP fingerprinting on Aruba, and configured the Roles and the User Rules and attached them to the AAA profile. When I see the DHCP Debug log, I see that it matches the User rule and assigns it the Mobile-Role but when I see the "Clients" I see that the user gets the same role that he gets on his laptop with PEAP.

 

Just want to pick your brains if this things is even possible (i.e. PEAP Server derivation rules + User derivation (DHCP Option rules)

 

Hi geekwrestler,

 

You can note the following:

 

1- From DHCP-Option (finger print) you can assign either VLAN or ROLE.

 

2- in case of layer 2 authentication, you have to authenticate before you start taking IP address from DHCP server.

 

3- Assignment of role/vlan from DHCP-Option will over-ride (have higher preference) server derived role assignment.

 

 

If I were you, I would create an other SSID for those smart-phones. They will get the VLAN from the VAP VLAN and the role should be given from DHCP-Option, 

 

The logic is like this:

 

(Authenticate using Radius from: SSID= IPhone)

                                    |

                                    |

                                    |

                                    |

( Client Assigned to VLAN=y, Client authenticated and assigned Role= only DHCP allowed) note: the role here should be the 802.1x default role and not server derived role

                                    |

                                    |

                                    |

                                    |

(Iphone try to get IP-Address)

                                    |

                                    |

                                    |

                                    |

(From DHCP process, controller find a match with a pre-defined user-role, and controller will assign a new role to the client Iphone which allowes him to access internet and DMZ (email) only).

 

 

 

I really did not try it by myself but this is the way I see it.

---

@geekwrestler wrote:

Hi guys,

 

Airheads has been a boon for configuring our Wi-fi setup. Thanks for the great stuff. Just wanted to discuss a problem I am having with adding some more flexibility to the WLAN. We have a 650 Controller and a few AP-105's and a couple of AP-93H's. Firmware is 6.1.3.4. Currently we have two SSID's one for Corporate and one for guests.

 

a) Corporate: Authentication is PEAP and each user is authenticated to MS-NPS which returns a FILTER-ID to identify the users vlan  after which the controller assigns a role using Server Derivation rules. (for e.g. a third floor user is assigned a role of "Third-Floor-Vlan-Role" which assigns him IP from the 3rd floor vlan and whereever he roams in the building, he would still get access like he was sitting in his cubicle.)   Devices: Laptops

 

b) Guest: Guests authenticate via a Captive Portal and are assigned to the Guest Vlan where they have only internet access. Devices: Any guest device | laptop or mobiles etc.

 

 

Now there is a third variable we want to add. We want that Corporate mobile devices like Apple iPads etc owned by employees are assigned a specific VLAN where they only get access to the Lotus Server in the DMZ and internet. They don't get access to the rest of the network.  Something like this:

 

User ->  Connects to Corporate SSID -> Logs in with Radius_Credentials -> Aruba checks device type if matching with User role -> Assigns role depending on device (Laptops=He gets the role returned in FILTER_ID from the Radius server | Mobile=He is assigned to the mobile vlan irrespective of the role returned from the radius)

 

For this I thought of using DHCP fingerprinting on Aruba, and configured the Roles and the User Rules and attached them to the AAA profile. When I see the DHCP Debug log, I see that it matches the User rule and assigns it the Mobile-Role but when I see the "Clients" I see that the user gets the same role that he gets on his laptop with PEAP.

 

Just want to pick your brains if this things is even possible (i.e. PEAP Server derivation rules + User derivation (DHCP Option rules)

_________________________________________________________________________________________________

 

You said that you are using DHCP-Option to assign a VLAN not a role.

 

So the people when trying to access the network using IPhone they are still using their username/password and the Radius server also, then the Radius will return the Attribute and will assign them the usual role as the people using laptops.

 

 

 

Hi Abi,

 

Thanks for the quick reply!

 

Firstly...

 

You said that you are using DHCP-Option to assign a VLAN not a role.

Typo. I mean't a Mobile-Role which has an assigned vlan. :)

 

Creating another SSID would be easy yes, but the problem is since the users are using the same user/pass as the Corporate SSID they can login to the Corporate SSID just as well and then they could get full access to the lan. To block that, I'd need to use User-derivation-rules that do DHCP fingerprinting... so I thought I just use that to assign them a Role that gets them on a restricted vlan...

 

You did mention that user rules hold higher preference than server derivation rules... so my interpretation is as follows:-

 

1) 1st floor User connects to Corporate SSID with PEAP (enters IDentity/Pass) (ex. Android phone)

                                                                             |

2) Radius authenticates user and sends back filter-id saying "1st_floor_user"

                                                                             |

3) Aruba controller receives the Filter-ID and assigns the user to 1st_floor_user role.

                                                                             |

4) Smartphone does a DHCP request

                                                                             |

5) Controller identifies that it is a smartphone and reassigns role to "Mobile-Role"

 

Is that the correct flow? I'm just guessing since Authentication in PEAP happens BEFORE the DHCP request from the client right? Hence the Server-derivation rule should take effect before the User-derivation rule. (Btw, I selected the User-Rule in MAC Authentication in AAA Profile. Don't remember exactly as I don't have access to the controller right now. Maybe I can get some screenshots of the config for you on Monday.)

---

@geekwrestler wrote:

Hi Abi,

 

Thanks for the quick reply!

 

Firstly...

 

You said that you are using DHCP-Option to assign a VLAN not a role.

Typo. I mean't a Mobile-Role which has an assigned vlan. :)

 

Creating another SSID would be easy yes, but the problem is since the users are using the same user/pass as the Corporate SSID they can login to the Corporate SSID just as well and then they could get full access to the lan. To block that, I'd need to use User-derivation-rules that do DHCP fingerprinting... so I thought I just use that to assign them a Role that gets them on a restricted vlan...

 

You did mention that user rules hold higher preference than server derivation rules... so my interpretation is as follows:-

 

1) 1st floor User connects to Corporate SSID with PEAP (enters IDentity/Pass) (ex. Android phone)

                                                                             |

2) Radius authenticates user and sends back filter-id saying "1st_floor_user"

                                                                             |

3) Aruba controller receives the Filter-ID and assigns the user to 1st_floor_user role.

                                                                             |

4) Smartphone does a DHCP request

                                                                             |

5) Controller identifies that it is a smartphone and reassigns role to "Mobile-Role"

 

Is that the correct flow? I'm just guessing since Authentication in PEAP happens BEFORE the DHCP request from the client right? Hence the Server-derivation rule should take effect before the User-derivation rule. (Btw, I selected the User-Rule in MAC Authentication in AAA Profile. Don't remember exactly as I don't have access to the controller right now. Maybe I can get some screenshots of the config for you on Monday.)

---

 

 

 

Only DHCP-option has higher preference over Server-Derived-Role.

 

Yes, your flow is correct. This way you can assign a strict Role to Smart-phones. However, you have two issues.

 

 

1- VLAN assignment to smartphone ( to be honest I do not know if you can assign a VLAN from the role or something?!) laptops and smartphones might be in the same VLAN in this case.

 

2- if people are using smart phone that its signature is not defined they will get the raduis role and get access to the local LAN

I am using DHCP Option for the User-Rule-Derivation.

 

We can assign a Vlan from the Role. (It;s called Assign VLAN or something). Laptops get the same VLAN's as on Wired. Only Smartphones/ Tablets will get different vlan.

 

For point 2, well we have to accept some facts in life. :D Maybe we may go for a full fledged BYOD solution in the future but right now, it's got to be via the controller only..

---

@geekwrestler wrote:

I am using DHCP Option for the User-Rule-Derivation.

 

We can assign a Vlan from the Role. (It;s called Assign VLAN or something). Laptops get the same VLAN's as on Wired. Only Smartphones/ Tablets will get different vlan.

 

For point 2, well we have to accept some facts in life. :D Maybe we may go for a full fledged BYOD solution in the future but right now, it's got to be via the controller only..

---

 

Hi Geekwrestler,

 

so VLAN can be assigned with Role, I find the following just to fill the gap:

 

Role VLAN ID
(optional):

By default, a client is assigned a VLAN on the basis of the ingress VLAN for the client to the
controller. You can override this assignment and configure the VLAN ID that is to be assigned to
the user role. You configure a VLAN by navigating to the Configuration > Network > VLANs
page.

 

 

In addition, to justify why DHCP-option has a precedence over Server-Derived-Role is because DHCP-option (finger printing) is a vendor attribute as the following shows Role assignment (from ARUBA-UG):

 

1. The initial user role or VLAN for unauthenticated clients is configured in the AAA profile for a virtual AP
(see Chapter 4, “Access Points” ).
2. The user role can be derived from user attributes upon the client’s association with an AP (this is known
as a user-derived role). You can configure rules that assign a user role to clients that match a certain set
of criteria. For example, you can configure a rule to assign the role “VoIP-Phone” to any client that has a
MAC address that starts with bytes xx:yy:zz. User-derivation rules are executed before client
authentication.
3. The user role can be the default user role configured for an authentication method, such as 802.1x or
VPN. For each authentication method, you can configure a default role for clients who are successfully
authenticated using that method.
4. The user role can be derived from attributes returned by the authentication server and certain client
attributes (this is known as a server-derived role). If the client is authenticated via an authentication
server, the user role for the client can be based on one or more attributes returned by the server during
authentication, or on client attributes such as SSID (even if the attribute is not returned by the server).
Server-derivation rules are executed after client authentication.
5. The user role can be derived from Aruba Vendor-Specific Attributes (VSA) for RADIUS server
authentication. A role derived from an Aruba VSA takes precedence over any other user roles.

 

 

 

Thanks Geekwrestler, good to learn from each other. :smileyhappy:

Thanks Abi. Hopefully we can continue the tradition! :)

 

I think for me these two points are key:

User-derivation rules are executed before client authentication.

Server-derivation rules are executed after client authentication.

 

Maybe that is why even when the logs show that the device is assigned to the "Mobile-Role" it finally lands up in the Floor_vlan_roles. Maybe the aruba guru's can shed some light?

---

 (Btw, I selected the User-Rule in MAC Authentication in AAA Profile. Don't remember exactly as I don't have access to the controller right now. Maybe I can get some screenshots of the config for you on Monday.)

---

If every thing were configured correctly then I really do not know why the role changed for mobile users !!

 

It might be your selection " selected the User-Rule in MAC Authentication in AAA Profile " :smileyhappy:

 

following is also ARUBA recommendation for DHCP-Option.

 

10. (Optional) If the rule uses the DHCP-Option condition, best practices is to enable the Enforce DHCP
parameter in the AP group’s AAA profile, which requires users to complete a DHCP exchange to obtain
an IP address. For details on configuring this parameter in an AAA profile.

 

 

One last point, try to delete all clients from the database first and then be sure to disconnect the smart-phone from the wireless network and then reconnect.

 

#aaa user delete all   (or you can specify <ipaddr> or MAC address)

 

 

 

 

A lot of data here. Let me try to explain:

The dhcp option user derivation rule is special in that it will override all other derivation rules in the AAA profile if it hits a match. It cannot be used in combination with other rules to achieve a role or vlan result. In addition, it cannot change the vlan of a device because the device has already requested an address on the expected vlan (vlan switching does work for an open ssid with no encryption, however).

With that being said, how do you change the vlan or role of a device based on user and operating system type? The easiest way, like Abi said is to have a separate vlan for mobile devices. The most flexible way is to deploy clear pass policy manager with onboarding. You would then be able to authorize users who can even get on with mobile devices, ensure that those devices have unique credentials separate from domain credentials and then decide how you treat them every time they authenticate.

Hi Cjoseph and Abi,

 

Thanks very much for your help here. For the authentication flow, found this enlightening document on the same: https://dl.dropbox.com/u/694445/Role-Derivation.pdf (Page 83 of VBNVRD)

 

The easiest way, like Abi said is to have a separate vlan for mobile devices.

 I'm assuming you mean WLAN here because a "separate vlan" is what I'm aiming to do but on the same SSID by assigning all mobile devices a Role irrespective of the role returned by Radius based on the user's AD group. IMO, it should work, because it works like a charm on wired networks.. the problem may be because when the Wired user switches VLAN's the ethernet connectivty disconnects and reconnects prompting the system to resend the DHCP request and get an ip from the new VLAN. Don't think that is possible with Wireless...

 

Browsing around the forums with the right keywords I found the other two topics:

 

http://community.arubanetworks.com/t5/ArubaOS-and-Mobility-Controllers/DHCP-fingerprinting-for-VLAN-not-working-at-all/td-p/19046

 

http://community.arubanetworks.com/t5/ArubaOS-and-Mobility-Controllers/Issues-Setting-VLAN-via-User-Rules-or-User-Roles/td-p/18952/page/2

 

A MAC -> 802.1x seemed like the "go to solution" but it has its caveats too -

 

1) Aruba checks MAC database and if a valid entry is returned assigns Mobile_Role (only will be entering MAC's of mobile devices)  If not...

2) If MAC fails, L2 Authentication Fail-through sends to 802.1x authentication where user enter's his credentials and gets access.

 

The only problem I see is that if I do not enter a mobile devices MAC address in the derivation rule, and the user has WLAN access in the RADIUS policy he could log in to an unauthorized device and get full access. Also maintaining MACs is a tedious task... people keep changing Mobile phones and tablets faster than they change clothes these days! ;)

 

So other than a BYOD solution I'm without any options...

 

Hey,

 

Yes, good to hear about VLAN assinment issue. The Role Derivation flow chart which you provided is very helpful. However, it shows that dot1x Auc will take place before MAC authentication !

 

well, then you can make the users have different credintials one for the laptops and other one (say with different username) for mobile devices.

 

That you mentioned it !! I am still thinking of buying a new suit or an iphone !!:smileyvery-happy:   JK