Security

 

Actually as I'm writing this, my other services in production are no longer profiling any devices. Is there a way to restart the profiling service?

--------

 

I'm running into a problem in a new service I'm creating. I'll list the requirements, followed by my current rules. This is an EAP-PEAP-

MSCHAPv2 auth type.

 

We require SmartDevices to be put on a seperate VLAN from domain computers. We would like SmartDevices to be on the same VLAN as domain computers if the user account has an AD membership that allows this access.

 

 

The AD part is all well and good, but I'm having problems with the profiling, as a device that hasn't been profiled can't match many enforcement rules. So for the below rule, if it is a smart device, belongs to this AP group, and is corporate ownership, apply this VLAN.

 

 

however if it is the devices first time connecting, it won't have been profiled, and therefore won't hit the right vlan.

 

Is there a better practice I should be using?

Is there a way to do profiling such as:

endpoint:isProfiled = false, enforce CoA profiling

 

Any thoughts are greatly appreciated.

Are you able to successfully CoA the device?

Get Outlook for iOS

No devices are going through CoA anymore or profiling. 

They were earlier today.

The best way to try this is using a test device that authenticated successfully to the network via ClearPass and search the MAC address in access tracker and do a change of authorization from there and see if it works

Get Outlook for iOS

I tired the Manual CoA from access tracker and it reported a success, but the device did not go through CoA, device also didn't profile

I just tried the CoA again, this time the got profiled. I then deleted the endpoint and tried again. The device failed the CoA.

I tried it again, and it succeeded the CoA, but didn't profile.

 

I've just done this on 2 different androids with accounts that have the same details. they only profile occasionally, and inconsitently on both devices.

 

I feel clearpass is acting up

These are IAPs? Be sure Dynamic RADIUS Proxy is enabled.

These are IAPS, and dynamic RADIUS Proxy is enabled.

 

Is there a default enforcement policy/role that forces profiling that I'm missing, or something that needs to be manually created?

No. You would need to create a role on the IAP that allows only DHCP and DNS. The in ClearPass, create a role enforcement profile with that role name. Then add a rule at the top of your enforcement policy that says Authorization:[Endpoints Repository] Category NOT_EXISTS and return that enforcement profile.

Seperate from best practices on setting up profiling for enforcement, profiling is either not working or very slow.

 

I just tried making a test service/ssid with simple AD authenitcation, with a simple enforecment policy that checks to see if the account exists, then allow access profile, with profiling enabled.

 

it took 3 manual connections to get profiled. I deleted the endpoint after I saw it had profiled, reconnected, and did 5 manual CoA from the acccess tracker before it profield again.

 

 

CPU and RAM are below 50% each, so load isn't the issue.

Remember, if you’re testing with the same device over and over, it will not always send a discover. Profiling uses DHCP discover packets.

Ah okay, so my frantic attempts to try to get these devices reprofiled are causing them to not be profiled? In that case, can I force a DHCP discover?

No, you’d have to either use different devices, keep changing the VLAN or change your DHCP leases to be very short (60 seconds). (This should never be done in production)

So this would also mean if a user was wired in on a gen user VLAN, the same VLAN they would be assigned on the wireless, when they change to wireless they wouldn't go through profiling as they wouldn't have a dhcp discover?

 

I'll have to rethink some of my setup it seems.

I've been looking into profiling best practices and I ran in to an old thread where Victor suggested setting up a DHCP helper

http://community.arubanetworks.com/t5/Aruba-Instant-Cloud-Wi-Fi/Can-IAP-serve-DHCP-and-relay-DHCP-requests-to-ClearPass-for/td-p/167936 

 

would this be something that would assist in my situation? setting a centralized DHCP scope using my IAP management VLAN pointing to clearpass server as the helper address to allow profiling, and all remaining DHCP requests would be normal?

 

That's the most typical way of profiling devices with ClearPass

Get Outlook for iOS

Unforunatley I found out earlier today that our environment can't support DHCP helper currently (we have a lot of really old equipment).

I'm thinking of just creating a VLAN that's only used for profiling. If a device isn't profiled, the user will be assigned to that VLAN, followed by the CoA from the profiler, so they can be assigned the correct VLAN.

 

I'll be testing this during the week. Are there any glaring issues with that idea?

---

@David_Spencer wrote:

So this would also mean if a user was wired in on a gen user VLAN, the same VLAN they would be assigned on the wireless, when they change to wireless they wouldn't go through profiling as they wouldn't have a dhcp discover?

 

I'll have to rethink some of my setup it seems.

---

Usually Wired NIC has a different MAC address than the Wireless NIC so you would have different IP address (1 per NIC). I guess it will create 2 EndPoints in ClearPass.

 

As for DHCP Helper, I don't know if it's configurable on Instant (maybe in CLI?) but I'm doing that in my infrastructure directly from Aruba Controller on the VLAN/IP configuration to point to ClearPass and with another DHCP helper on the VLAN interface on the Distribution switch to point to the DHCP server. 

A few findings:  the test client wasn't being profield as they were failing the enforcement policy. I have a rule that the client must be user and machine authenticated, but the test client wasn't being machine authenticated. After I provided a role that allows user only authentication, they successfully got profiled.

 

The non-profiling was mostly on my test clients due to my frantic reconnects hoping it would profile without letting the DHCP lease expire.

 

The IAPs do support DHCP helper, but by network environment doesnt (we have some extremely old hardware).

 

Now, my test client wasn't passing Machine authentication, it seems this is because it's a windows 10 client. It seems the Hyper-V hypervisor has a credential guard and device guard that prevents PC domain information from being used.

does anyone have a workaround for Windows 10 computers using EAP-PEAP-MSCHAPv2, with deviceguard and credential guard preventing machine auth? I'd rather not fully disable these guards if possible

PEAPv0 is effectively a legacy authentication method these days. PEAPv0/EAP-MSCHAPv2 will not work with Credential Guard enabled. You’d need to move to EAP-TLS (best practice).

The problem with EAP-TLS is that it works terribly with multi user devices, especially the first  time a user signs in to the device when the PC hasn't recieved the client certificate yet.

Yes, correct. You could use machine only auth in that case.

with machine only auth I won't be identifying specific users and providing different access based on AD roles. 

 

Everything I do seems to have a drawback. I just want to have cake and eat it too.

Thanks for this information, we are planning to deploy Device Guard/Credential Guard to hundreds of Win10 devices and on test devices have confirmed it breaks authentication over wifi.

Is there a white paper on this or best practises or is it as simple as 'EAP-TLS'?

thanks 

Micrososft has a ton of documentation on deploying certificates with Active Directory Certificate Services. We don't maintain separate documentation.

On our windows 10 devices with Device Guard/credential guard, they are able to connect using EAP-TLS.

 

As long as you have the correct certificates pushed from your cert server to your devices, you can do machine and/or user credentials for authentication.

 

I would recommend making sure you have the correct group policy for the SSID. Make sure to specify which credentials are being used, machine and/or user, whichever you choose to deploy.

You need to create a rule at the top that checks if the profile category NOT_EXISTS and drop the user into a profiling role.

You need to verify how your CoA is configured on the IAPs
Make sure that the transition VLAN is configured to do profiling

Get Outlook for iOS