Security

Hi,

I've setup in our lab environment this scenario:

CPPM 6.7.4.107401 in Windows Domain with Server 2016 Standard and using certificates to authenticate Machine/Users. All working perfectly with EAP-TLS Method.

Some clients is asking for a solution to this: Machine authenticate and gets the "Corp" VLAN when boots up. After that, the User put the credentials and based on Domain Usergroup it takes specific VLAN. How can I force the bounce or something else to user get the IP on new VLAN?

The Machine auth is used because the need to authenticate the User on Domain (if the user never logged at this machine).

Any thougths?

I agree with you. I always try to avoid, but, this is a specific case.

Where I put the CoA action? After machine authentication?

Below is the Service/Enforcement Policies. Each Enforcement Profile set the specific VLAN ID.

Anyway, what is the best practice in this scenario?

Authenticate machines first, so users can be authorized by AD to log in and then authenticate users on Clearpass? The need is to assign vlan based on User Group.

The fall back is mac auth based on roles/endpoints and captive portal, thats ok.

As Tim mentioned, not recommended to change VLANs as DHCP is unreliable and it is very possible the device's VLAN will change, but IP will not, leaving it unable to communicate in the new VLAN.

What you could try is machine auth through CPPM send back corp VLAN assignment, then User Auth through CPPM sends back a dACL if using Cisco or User-Role if using Aruba to limit network access to only required resources.

You *can* use the VLAN change, but I think it's very risky and may be inconsistent, resulting in endless troubleshooting of connectivity issues.

If you do go down the machine and user authentication with different VLANs route, on Windows 7 devices you should enabled single sign-on in the advanced settings and ensure the option "This network uses separate virtual LANs for machine and user authentication" option.

This tells the device to complete a DHCP renewal after a successful user authentication.

I'm not sure if the option is the same with Windows 10.

That said I agree with the previous posts that you should really avoid this scenario.

Hi Tim. If VLAN change is not recommended after user authentication, what is the recommended practice in getting the machine into the right VLAN? Presuming we want to segment users and machines by job function: Payroll vs HR vs IT, etc. If we ultimately want users separated by VLANs then we also need the machines separated by VLANs and we'll use dACLs with CoAs upon authentication. I'm unclear on how to best get Clearpass to assign machines to their own VLAN. The only way I can think of is to get machines into specific AD OUs and then have an enforcement policy (with VLAN enforcement) based upon that. Is that correct?

I've had some success with the AD / Group Policy route at a user level (machine auth into a particular VLAN prior to login, create enforcement policy with an Aruba Role that is assigned to user based on their AD group membership, in the Aruba Role on the controller define desired VLAN.  When user logs in they are switched to VLAN defined in Aruba Role).  This worked without issue across Windows 7/8/10, iOS, etc. from versions 6.x until 8.2.x (conservative release), but seems to have issues in 8.4.x and 8.5.x that manifest at login (the time of role assignment / VLAN switch).

The consensus here on the forums is to not perform a VLAN switch but use a CoA or disconnect instead, my question to this is similar to that of vtran's.  Is a "VLAN switch" being considered as using an Enforcement Profile with a template of "VLAN Enforcement" and setting the Tunnel-Private-Group-Id?  Is what I outlined above the same thing and also not recommended? (template of "Aruba RADIUS Enforcement" that assigns Aruba User Role, which that role then has a VLAN defined on the controller)  

Hi,

As previous posts mention it is not recommended.

I know from experience in special cases that with windows 7 & 10 it will work without a CoA. But you could have other devices doing 802.1x where it doesn't work. And I have seen microsoft change settings on 802.1x twice with the last updates in windows 10. So it is better to avoid it in production.

Hope it helps