Security

Hello all,

 

Can anyone please recommend the best practice for the following scenario:

 

- multiple sites with Dell switches running dot1x, need ClearPass to return a different VLAN ID based on the site where the request originates (different VLAN IDs are used per site).

 

I had thought that I could perhaps have a different service defined per site based on a device group or device, however doesn't seem to be an option when defining the service rules.

 

There also doesn't seem to be an option for role mapping or enforcement policy based on requesting network device either - any thoughts appreciated.

 

Cheers

you can certainly do it in the service selection screen. so create different services for different locations.

In your enforcement profile, you can select a network device. Create a new profile for each VLAN and add the appropriate switch(es) to the list. 

In your service, create your enforcement rule and return all of those profiles. 

ClearPass will return the appropriate VLAN ID depending on the authentication request. 


Thanks, 
Tim

Thanks for the advice guys, that's great.

 

I've added a service rule for requests from a group of devices are a site:

Type: Connection

Name: NAD-IP-Address

Operator: BELONGS_TO_GROUP

Value: <group name>

 

Cheers

As always with Aruba and ClearPass, there are a number of ways to do the same thing.  If you only wanted a single enforcement policy you can configure each NAS with a "Data" attribute signifying the VLAN that you would want data to be placed on.  You can use the namespace "%{Device:Attribute}" to return that value in an enforcement policy.  The namespace will replace %{Device:Attribute} with the value of the attribute pulled from the authenticating NAS (Device) and send it as a radius attribute (in this case the attribute is data).  For example, if I have a switch defined like below in ClearPass and I specify a "Data" attribute:

I could simply return the Value of the VLAN as a Device:<attribute> namespace like this:

If an authentication comes into ClearPass from that switch and hits that enforcement profile, it will return a VLAN of 4 for that authentication.  You can define each switch with its own Data attribute to return whatever VLAN number corresponds to that switch.

 

There are many places where a few floors have one vlan for data, the next set of floors have a different vlan for data and so on and so on.  The strategy above allows you any return any value that is defined as an attribute in a NAS in CPPM as a radius attribute.  While there is definite utility for a list of rules where "NAD-IP-Address belong to group" the strategy above allows you to be more granular and have a single enforcement policy.  Again; just another way to do it.

 

I hope this helps.

 

 

 

That's fantastic, and simplifies everything - especially for remote sites.

 

Cheers and thanks for taking the time!

Thank you for this. 

I am actually using this for one of my installs and it is working just fine. In some switches they have two different data VLANS defined on the same switch. How can that be configured using your method you have posted above? How would CPPM know to send the device to the right data VLAN?

You can create an attribute for that particular switch or use the NAS-IP (Switch RADIUS source IP)

Sent from Mail for Windows 10

sorry, I was trying to look on my test CPPM on how this would be configured, but I couldn't fiqure it out from what you have said below. You able to provide some screenshots please on how you envisage two different data VLANS being sent back to the same switch?

Thanks for the screenshots. 

Still a bit confused on how that will allow two different data VLANS to be sent back. So just for my clarification purposes, are you advising two attributes be created on CPPM on the device section and then in the enforcement policy two conditions created to send either data VLAN back. How would CPPM know what data VLAN to actually send back?

Its typically the same devices that connect, i.e laptops, printers and VOIP phones.

Sorry just need a bit more clarification so I can understand and explain how this would work with two data VLANS

What kind of switches are you using? Why not just use named VLANs?

As Tim mentioned, named VLAN is the way to accomplish the straight task of spreading users across multiple VLANs. Otherwise, what criteria should ClearPass use to determine which VLAN to signal a user into?

The switches are:

Cisco 9300-48P

Switch Version: 16.6.3

 

How would these work with named VLANS? 

On the switch themselves what configuration do you have to do so the VLANs are part of the same name?

 

If we can't do this on the switch side, we may build policies on Clearpass based on AD group memebership to put specific users in the respective VLANS. 

Take a look at the ClearPass Solution Guide for Wired Policy Enforcement. Named VLANs with Cisco is covered.

Which section I have re-read the guide over 5 times to find the answer for this?

 

The closest I have found is:

"For example, each switch might use a different VLAN-ID for “secure access”. Instead of having to write complex policy in ClearPass to return the correct VLAN-ID for each switch, we just give the appropriate VLAN-ID a name on each switch; “SECURE” for example. Now in your ClearPass policy, you simply return a VLAN enforcement with “SECURE” as the VLAN-ID and each switch will use the appropriate VLAN-ID mapped locally on the switch."

this is based on different switches having different VLAN-ID with the description as "secure access". The specific requirement is to have the different data VLANS returned to the same switch, but we are not sure on the switch configuration side or Clearpass side. 

I actually did make progress with this, but my client decided to move to one data VLAN to keep things simple. 

Before they decided to have one VLAN, I actually found this feature on Cisco Switches.

 

vlan group

To create or modify a VLAN group, use the vlan group command in global configuration mode. To remove a VLAN list from the VLAN group, use the no form of this command.

vlan group group-name vlan-list vlan-list

no vlan group group-name vlan-list vlan-list

Syntax Description

 

group-name	VLAN group name.
vlan-list	VLAN list name. See the "Usage Guidelines" section for additional information about the vlan-list argument.

 Defaults

This command has no default settings.

Command Modes

Global configuration (config)

Command History

  

Release	Modification
12.2(33)SXI1	This command was introduced.

 I didn’t managed to test this fully as I only had three test devices to play with at the time.

I had two data VLANs in a group configured on a test switch.

Just wanted to check if anyone else managed to play with the Cisco switch group feature?

When I tested this with my 3 devices I saw, the first two devices went into the first VLAN and the other device in the 2nd VLAN. This group feature doesn’t let you configure whether it will be hash or even loading balancing on the VLAN group. On wired I would prefer if it would be even to be honest.

Just wanted to put this out there to see if anyone else had any ideas about this just for the future?

I couldn’t find much documentation on this either most documents I came across was for the Cisco Wireless controllers.

is this cisco's vlan group the same as in aruba controller's vlan pool?

and what are the results of your testing?

anyway, for my case, straight to the example: one department can have multiple vlans assigned to individual. so i couldnt think of any other way other than whitelisting them by mac address. so in my RMP i set if ur mac=aa-bb-cc you'll get Role "ABC". then i set this tips:role as a condition in the enf-policy.
what could be the alternative?
maintaining the whitelists is unacceptable for the customer.

From my experience it does not behave the same as Aruba controller VLAN pool feature.

 

I didn’t manage to test it fully, but the results were clients were going into the first VLAN in the group I did not ever manage to get it load balanced.

 

For your example, are the users divided up by department? In the AD?

If a user from department x connected send him to VLAN 10

If a user from department Y connected send him to VLAN 20

 

Is this something you could implement?

I hope my explanation made sense. 

i also never fully observed and made sure about vlan pool in aruba controller, but i perceive it as below:

if in vlan pool we configure vlan 10 & 20, then the user can get either vlan 10 or vlan 20 network.

 

below example from you is easy, i can set a condition provided any certificate attribute (i configured the cert must show FullDN in issuing CA )

Cert:FullDN contains OU=X to vlan 10

Cert:FullDN contains OU=Y to vlan 20

 

customer situation is, they have some users from OU X are now currently (while without dot1x) assigned to vlan 10, 20, 30 (these are also under the same switch group).

so it will be like this more or less:

user A from OU "fin" under one switch "GHI" use vlan 10 as their prod vlan.

user B from OU "fin" under same switch "GHI" use vlan 20 as their prod vlan.

user C  from OU "fin" under switch "PQR" use vlan 30 as their prod vlan.

and any other possibilities.

 

so they want to keep the user production vlan same as before, but now with dot1x enabled.

To achieve this maybe you could set this condition in the enforcement rules:

 

Connection: NAD-IP-Address: Equals: x.x.x.x

And

Authorization:AD: member of: Equals: OU=fin

 

I think this way will allow you to do DOT1X and get the users in the individual VLANs. Please let me know.

 

Hello,

 

Yes, at the first place I thought that would work to our customer, but we found out later that under one switch, there are many vlan assigned to this OU=fin.

 

Decided to ask customer on any fixed criteria that we can use to map the user vlans.

 

My temporary solution is assign unique Role to EVERY single user, based on the current 'switchport access vlan xyz' value.

Populate [local user repository] manually (using XML) with all the users and assign them 'Authorization:[LocalUserRepository]:Role_Name="Staff_VLAN_xyz"'.

These user data we gathered from HRD.