[Resolved] APC-380: Incorrect AirWatch server response can result in enterprise wipe for devices under certain configurations

Note: This issue affects Android and iOS devices differently.  This article is broken out into separate Android and iOS sections.

Identifier

APC-380

 

Android

Symptoms

When an AirWatch mobile application checks into the Device Services server, if the server experiences an exception / error at the time of check-in then a potential enterprise or application wipe can occur. The most common cause of exception observed is if the Device Services server loses connection to the database server for any particular reason. (e.g. datacenter outage with no failover, uncontrolled infrastructure changes, etc.).  

On the affected Android devices specified in the Version Identified section below, this incorrect response will result in an enterprise wipe.

 

Workaround/Mitigation

If any security settings are enabled under Settings > Devices & Users > Android > Security, temporarily disable these settings until you are running a version of AirWatch that has resolved the issue.

When performing any network maintenance, AirWatch recommends ensuring that your AirWatch application servers (Console, API, and Device Services) are always able to communicate with the AirWatch Database.  Any time maintenance may affect the connectivity to the database, make sure all AirWatch application servers are taken offline first.

 

Version Identified

This issue primarily affects upcoming releases of AirWatch applications.  The following versions/deployments are affected by this issue.  This article will be updated with specific version numbers as these apps are released.

  • Android devices in environments using AirWatch Console 9.0.1 if Android Agent 7.0+ is used AND additional security settings are enabled in the AirWatch Console under Settings > Devices & Users > Android > Security.  These settings are only applicable and configurable when you have configured Authentication and Single-Sign-On for AirWatch applications.
  • Devices using Workspace ONE 2.12+ or Container 3.3+.
  • Devices enrolled in stand-alone Content Locker or stand-alone Boxer mode (without the AirWatch Agent) may be affected.

In addition to the upcoming versions mentioned above, end-users using certain versions of Boxer (3.12 or below) or Browser (5.10 or below) and below may experience the issue as well.

 

Resolution

This issue has been resolved in AirWatch 8.4.9 and 9.0.2.

 

 

iOS

Symptoms

When an AirWatch mobile application checks into the Device Services server, if the server experiences an exception / error at the time of check-in then a potential enterprise or application wipe can occur. The most common cause of exception observed is if the Device Services server loses connection to the database server for any particular reason. (e.g. datacenter outage with no failover, uncontrolled infrastructure changes, etc.).  The specific behavior experienced differs between Android and iOS devices:

  • Affected iOS devices that are enrolled through the Agent or web enrollment will experience an application wipe if the issue occurs.  That is, the application being used during the incorrect response will lose all saved application data (such as emails in Boxer or content in Content Locker).   These users may need to re-enter credentials to continue using affected applications.  These devices will not be un-enrolled.
  • iOS devices enrolled through Container will become un-enrolled if they experience the issue.  These users must re-enroll.
  • iOS devices enrolled through Workspace ONE are unaffected.

 

Workaround/Mitigation

When performing any network maintenance, AirWatch recommends ensuring that your AirWatch application servers (Console, API, and Device Services) are always able to communicate with the AirWatch Database.  Any time maintenance may affect the connectivity to the database, make sure all AirWatch application servers are taken offline first.

 

Version Identified

iOS devices in any AirWatch environment can be affected.

 

Resolution

This issue has been resolved in AirWatch 8.4.9 and 9.0.2.

Have more questions? Submit a request

0 Comments

Article is closed for comments.