Recently, I tested out policy enforcement on corporate iPads using Forescout’s CounterACT and its optional Airwatch integration module*. I’ll be sharing a few things I learned along the way, especially since documentation of this setup is rather sparse (read practically non-existent).
To get this setup, I installed the Airwatch module, downloaded from the Forescout site. You’ll need a valid login, but once you’ve downloaded the file, you can install the module from the CounterACT client by going to Tools -> Options -> Plugins. After installing the module, there’s a few pieces of integration information that can be found in the Airwatch portal itself. In the CounterACT client, you can right-click the AirWatch MDM plug-in, click Configure, and enter the required information.
Once you’ve completed the integration information, be sure to start the AirWatch MDM Plugin – it doesn’t automagically start and results are particularity disappointing unless it’s running, as I experienced myself.
At this point it is a good idea to use the Test option for the Plugin and confirm you see a Test Passed in your output.
You can also double click the MDM Integration Module and you should see some happy little Airwatch managed devices listed.
Now it’s time to set up a couple of policies. My first policy matched on Network Function – Mobile Device and Airwatch Enrollment Status – Enrolled. If CounterACT finds these two criteria to be true, it should drop the tablet into my Corporate Hosts group I designated – a group which is allowed the appropriate network access for a corporate managed device.
My second policy was designed to match unmanaged tablets and phones – those not enrolled in Airwatch. The policy checks if the Device Function is Mobile Device, and has an action of WLAN Block.
I thought this would be it and victory would be mine, but alas the WLAN block wasn’t working.
I received increasingly annoying errors about not being able to reach the wireless controller to enforce the policy. After testing the wireless controller under Plugins, I could see I was failing on WLAN Role and on Write Permissions. In an act of sheer grasping at straws, I removed the wireless controller, which had been added as it’s VIP (HA) address, and instead added the wireless controller as its “real” IP address. That did the trick. All tests passed, victory dance cued up.
But then I discovered the extremely disturbing flaw in my perfect policy plan. Once a device was identified as not managed and very successfully blocked, it became blocked from all SSIDs. Meaning no employee network AND no guest network for the device. The controller wouldn’t accept the device as a client. Period. Cue sad trombone instead.
Reworking the policy logic, I instead implemented the WLAN Role change instead of the WLAN Block action.
I selected a guest role configured in the Aruba controller that locks the user down, blocking access to corporate resources. You can see below the successful policy enforcement.
Later, my awesome coworker was able to set up an HTTP notification action for the policy so that the users see a web page informing them of the error of their ways and instructing them to change SSIDs to the guest wireless network to be redeemed.
Now about that victory dance…
Published 05/26/2017
*Anyone who has had to deal with 802.1X certificate enrollment for iPads knows what a PITA the experience is – the setup being tested here allowed for PEAPv0 (EAP-MSCHAPv2) authentication using Microsoft NPM, with the goal that any non-corporate device would have no access to corporate resources. There are other ways to skin this ugly iPad certificate cat, and if you’d like to list the ones you’ve had the most success with in the comments, I am sure others would appreciate the insight.
Amy Engineer 