Security

 Hi

 

I have created enforcement vlan profiles for wireless 802.1x ssid  based on user device make- sony/lg/samsung etc.

but it doesnt work  at first instant , it gives error as cant get information for category.. I guess that means devices is not profiled..

once i connect this client on other onboarding ssid it gets profiled and then on first ssid the device gets proper profile..

 

What is the proper  procedure to achieve profiling ??

 

Profiling occurs after a device obtains a DHCP address.  802.1x authentication occurs before DHCP.  If a device has never done DHCP, it would not be profiled or in the endpoint database, so the first time it connects via 802.1x, we do not know what type of device it is...

If you have RADIUS accounting enabled, you can do a delayed session timeout, but the user experience isn't great.

Hi Colin,

 

so what will be the proper ( acceptable by customer  :smileywink: ) way to address it ? 

What are you trying to do?

 

 

basically if a user comes and connects to 802.1x ssid with android device it should get vlan x

user comes with iOS it should get vlan y

both users are new to the network connecting very first time

in this case these devices are not profiled hence they will never get profiled and connected 

what modification is required to first allow the non-profiled device>> something like bounce the device connection>> while reconnecting apply proper profile

Let's take a few steps back:

 

Why does the customer want Android and IOS devices in different VLANs?

 

:smileysurprised:  It was just an example ....actually the requirement is 

computer >> Vlan x

Smartphone >> vlan y

If it is a domain computer, you can use clearpass rules to detect that and return an enforcement profile http://community.arubanetworks.com/t5/AAA-NAC-Guest-Access-BYOD/Enforce-Machine-Authentication/td-p/58918/highlight/true/page/2   Any other devices simply get the "other" enforcement profile which will put them into the second VLAN.

ok but that will partailly solve the problem..

and I forgot to mention that one more requirement is to block devices which are other than samsung/apple  fopr which profiling is must

 

How would the customer do this without Aruba equipment? If you let us know we can emulate that with Aruba equipment.

 

Hi Colin ,

 

adding CPPM IP as DHCP helper on Cisco WLC will be helpfull in this case ? 

what I understand is  by any way a device should get IP from either WLC based auth or CPPM based auth then only it will be profiled

 

:smileyfrustrated: this poc is making me understand every possible feature of CPPM :smileywink:

configuring most of the part of cppm for very first time 

If this is a POC, you should probably consult your local Aruba SE to make sure that all of the requirements of the POC are met.  We can only give you one-off advice here and it might not meet your overall needs.

 

I'm working on a similar scenario in a lab environment and am seeing similar results.  I thought Radius CoA would solve this issue but it doesn't appear so, at least how I have the system configured anyway.  I have an Aruba 3400 WLC and a Cisco 2504 WLC advertising SSIDs pointing to a ClearPass server for AAA services and device profiling.  I'm trying to achieve differentiated service based on device type.  My enforcement profile matches a Windows AD group and a device category but new users are failing the enforcement profile due to the inability to gather device category in the enforcement profile.  It works fine for users that have already been profiled.  It appears I need to onboard the device first and leverage Radius CoA during that process to do what I want to do.

Hi,

I'm preparing an Aruba 802.1x Service for a customer and meet the same issue.

The Role mapping rules classifies the Non-AD authenticated devices by categories and OS : Android, Ipad, Iphones...

My Enforcement policy places the devices in specific vlans (Customer's devices vs BYOD's devices) with specific roles (based on User's AD Groups).

It works fine for the Machine authenticated devices (Customer's domain machines) and for every already-profiled devices.

There is an issue for every new devices. They are not profiled, so they cannot be role mapped.

 

Could you please tell me how you finally did ?

 

Regards

Matthieu

 

You need to enable profiling on the service and also add a rule at the top of your enforcement that says if the endpoint category does not exist, then return a role that has only DHCP (you could just use the logon role for this).

 

Thanks for your reply. I will quickly try this.

Is there a difference on the user experience with this configuration , between an already profiled device and a new device ? I'm asking if the new devices have to connect 2 times to the SSID.

First time to be redirected to a DHCP only role by this new Enforcement Profile rule.

Second time to apply the good role based on role mapping.

 

The Profiler tab may be the tip to automatically change the Role without regards to the user experience as soon as the device is profiled. Am I right ?

 

 

A device that is already profile will skip the first rule and proceed directly to the role assignment.


Thanks,
Tim

I recently worked on implementing this into my environment.

In my testing I did not see much impact on the user experience.

 

The COA happens extremely quickly and the device will simply reconnect without the need for user intervention.

 

Then, as cappalli pointed out, the next time around the device will be processed normally without the COA bounce.

 

Cheers