Updated on 04/28/21 with additional reference links on randomized MAC address with Android devices.

Updated on 06/16/20 with additional information on impact from a randomized MAC address with Android 10.

Updated on 06/04/20 with a reminder to renew the AirWatch certificate in the Cisco ISE portal. Otherwise, devices will fail to connect.

Introduction

Wi-Fi access has long been a basic necessity and the major driving force in mobile technology in the 21st century.  As anyone would have guessed, enabling cellular service on every mobile device remains a lofty goal mainly due to the cost involved. Some organizations may also allow devices access to internal resources over a specific Wi-Fi network. While using a Mobile Device Management (MDM) solution helps ensure both data and device integrity, additional steps taken at the network layer can further enhance the overall security for utmost protection without inconveniencing the users. The steps one will take mostly depend on your wireless equipment. For this particular post, I will share my experience with integrating AirWatch with Cisco Identity Services Engine (ISE).

While ISE has been around for quite some time, so far the only good known PDF is the one below which was last revised on August 6, 2013:

Integrating AirWatch with Cisco Identity Services Engine

Like many others, I attempted to search for a more up-to-date version without any success. Perhaps as the Cisco employee pointed out, there really hasn’t been many changes with the workflow since it was released.

I suppose similar to VMware Workspace ONE documentation, the online version is easier to maintain and thus should be the go-to source first. In fact, there have been several releases of ISE per the link below.

Cisco Identity Services Engine

To my surprise, I actually quite enjoy reading the original PDF even though it was pretty out-dated with the screenshots and settings that pertain to AirWatch. Although page 6 through 10 of the PDF already provides sufficient info to help integrate AirWatch with ISE, I couldn’t help but read the entire document with pleasure. I’m confident any network admin will easily develop a good understanding of MDM just by reading this document.

I also stumbled upon the document below from the AirWatch support site which may be helpful as well. The diagram below was taken from this document which shows a typical workflow.

airwatch cisco ise integration

Steps

The steps below are based on the cloud-based deployment model. You may follow similar steps if you have an on-premises deployment model as well.

Step 1: Verify connectivity between Cisco ISE and AirWatch console

The session is an outbound initiated session from ISE to AirWatch over HTTPS (i.e. 443). You may want to review your firewall rule to confirm this is in place before proceeding further.

Step 2: Verify Cisco ISE API is installed on the AirWatch API Server

For SaaS customer, open the URL below from a browser of your choice:

https://cn###.awmdm.com/ciscoise/mdminfo

If you are prompted for a username and password, the installation is successful.

To validate this further, an XML file with site-specific info should appear upon entering the above.

Step 3: Export certificate from AirWatch console

At the moment, I have two distinct environments with VMware. One is a shared SaaS and the other is a dedicated SaaS. I originally thought of exporting the certificate from both environments. It turns out, however, all cloud-based environments use the same wild card certificate from VMware. So I only need to export the certificate once.

Your steps for exporting the certificate vary based on the browser of your choice. Here I use Google Chrome as an example.

Here’s a screenshot from ISE on importing this certificate.

Before you continue, make a note to renew this certificate in Cisco ISE before it expires. Otherwise, your devices will not be able to connect as the API call fails due to the certificate being expired. If the API call fails, the devices will be flagged as ‘unregistered’ and thus they will be denied authentication.

Once the certificate is renewed, the connection will be successful once again.

Step 4: Create an API role in the AirWatch console

A restricted administrator role needs to be defined before creating an account for ISE to access the API in AirWatch. This particular role only requires access to REST API MDM and nothing else. Read permission should be sufficient for this integration. However, VMware support advised that if commands such as enterprise and device wipe are required by ISE, then Edit permission is also needed.

Make sure to create this role at the highest level organization group (OG).

According to the Cisco document, however, it appears both Read and Edit permissions are required for this integration. So adjust accordingly based on your need.

Step 5: Create an admin account and assign the newly created API role

The PDF describes steps to create a basic account for the new administrator. However, I suggest creating a directory account instead especially when you have multiple environments with the same MDM provider for easier management and security. Utilizing the directory account requires console version 1811 and above.

If you are running console version 1810, you may experience the issue below per this link from the VMware community forum. In fact, I experienced the same issue and ended up using a basic account as well until after I upgraded my console to 1903.

“Quick update on this, in our SaaS environment, it appears that version 1810 introduced a bug with the Cisco ISE API integration: Directory Accounts can no longer access the Cisco ISE specific URIs ( /ciscoise/mdminfo and others ), only basic accounts can… And these expire after 30 days..“

After speaking with VMware support, as of 04/11/19, the product request PR-199316 to restore support for directory account has been resolved with console version 1811 and above.

Also, it turns out there’s a global setting to turn off the 30 days expiration period for all basic accounts in dedicated SaaS and possibly in the on-premises environment. This setting is NOT available for a shared SaaS environment.

To make this change, contact VMware support and they will work with their internal database team to get the change completed on the back end. Below is an additional note from my support account manager:

“I have discussed this internally and found that the maximum days until expiration we can set is 9,999-days [approximately 27-years]. I don’t have any Customers who have delved into the expiration of the account credentials but there is a caveat you should be aware of. This change does not affect just the account you have set up for CISCO ISE integration. It will also apply the same credential expiration timeframe to all ‘Basic’ Administrator accounts within the Workspace ONE Environment. As a result, any Administrators utilizing basic accounts to log in to the Environment will not be required to change credentials for approximately 27-years.”

Step 6: Provide the information to add AirWatch server to ISE

We are now ready to add our MDM server to ISE.

For each MDM server, you will need to fill out the fields below:

• Host Name / IP Address:enter the URL for your web console (i.e. CN###.awmdm.com).
• Port: should be 443 by default.
• Username: the same admin account created in step 5. If it’s an AD account, use the domain\username format.

As for the polling interval which is a global setting, you may want to set it to 0 to start which disable the setting. As suggested by the PDF, it’s best to first review the existing configuration in AirWatch to avoid oversampling which could overload the MDM server and reduce the battery on your mobile devices.

Here’s a sample of the entries you may use as a reference.

If you get this prompt, this confirms a successful connection.

If you get this prompt, verify your account credential and try again.

Step 7: Confirm connectivity and review dictionary attributes

Once the MDM server is added and enabled in ISE, it will be able to retrieve a list of supported dictionary attributes from your MDM environment such as the below:

Final consideration

For my setup, below are the ones that stand out for me. Yours, of course, may vary.

• Ensure VMware Intelligent Hub is installed on every mobile device to help detect if it is jailbroken or rooted. This includes devices enrolled through Apple DEP which normally is an agentless enrollment process.
• Meet with your network group to discuss and review policies to be created in ISE will not disrupt your enrollment or compliance workflow.

We also encountered an issue that once a device was authenticated/connected via one MDM environment in ISE, it wouldn’t authenticate/connect via another MDM environment configured in the same ISE. Per Cisco’s support, this is by design. The workaround is to first delete the record in ISE before the device will authenticate successfully via another MDM environment.

“At this time the answer is to delete the Endpoint so it will be added later with the correct attributes. Once ISE maps a device to an MDM it is for good. So if you move the device to a different MDM, ISE will still think that it is on the original one.

As we know, ISE is not able to query in sequence different MDMs to find out which one currently holds the endpoint.”

Additional info on API available for Cisco ISE

https://Your_UEM_Console_URL/ciscoise/v1/ciscoise/service/help#

API 

Query by mac address.

Query by serial number.

If your device fails to connect, the below might help.

“We check for device registration status, which leverages API which makes the query to UEM console using mac address to find all the attributes for the device. So, if the mac address is not found in AirWatch database devices are failing to authenticate.”

Just recently, I learned that Android 10 and above use a randomized MAC address instead of the hardware MAC address. So I asked my colleague to reach out to Cisco to see how this may impact our Android devices.

Here’s the response from Cisco:

“End user devices have (sometimes) a function built in to randomize their mac-addresses, to counter snooping and movement profiles. Cisco can’t do anything here, because it’s an end user privacy feature, which Apple and Google (and with tablets/laptops Microsoft) have built-in and enabled for guest networks. The WLC always sees a different client, unless you use username/password authentication on the SSID, or if the end user trusts the SSID. I think the MAC doesn’t change, once the user has configured the SSID on his device.

It’s the devices that has a feature to randomize the MAC address. You can’t address that issue from any wireless controller.

Random MAC Address feature was introduced because there are some people who don’t like to be “tracked” by government agencies.  This is a feature enabled by Apple, Microsoft and Google.  Cisco isn’t the “author” of this feature.  

This depends on the used client and operating system.

Most clients don’t change their MAC address, once they are connected with a network. They only use a random MAC for scanning and searching for SSIDs with hidden BSSID. Once they connect and the user enters the PSK (or other credentials) the clients use their real hardware MAC and not change it.“

Here are a few links for your reference on this topic.

• Randomized MAC android
• Android Q for Enterprise: Wi-Fi MAC Randomizaion

As always, stay mobile!