Thomas B. I´m not sure if the workaround will help in my configuration. We do not use the boxer, so it´s rather the hub-app that triggers the compromised status.
What I also found out was that the status switched on some devices more than one time from true to false and back to true - but could not find any reason for that change. Some times it helps to start the hub and force a sync, somtimes a restart of the device helps, and on other devices nothing will help...
So at this time I will wait for a new hub-(or iOS) version, the compromised-status is a ' beauty mistake' without impact.
Mark S - in this case my fist question is: ' what have they fixed?' . Every day the number of compromised devices on my dashboard increases. The good message is, this is currently the only negativ impact.
The next question is: why are not all of my ~16.000 devices affected? They all using also the last HUB-Version...
With the beta version of iOS 13.0, nothing like this has been noticed yet, only since the first official version was available the compromised devices appeared (whit the ' on-off' effects I wrote in my last message)...
Over the last month or so, we've seen an increase once again in the number of devices being detected as compromised. In this latest round, the devices are being detected as compromised, and in most cases, going back to being compliant within a minute or two. The users aren't doing anything to rectify it, because at that point, they don't even know their device has been detected as compromised (and I've followed-up with some of them).
I think I've put in at least 4 tickets related to this never-ending problem. The last one I created, which was back at the beginning of the year, is still open, and they just responded that the issue is fixed in Hub 20.05. But they've told me similar things in the past about new versions of their apps, and the problem still happened even with the "fixed" apps installed.
Our security team is hesitant to disable Compromise Detection, but it seems to be more trouble than its worth. Don't think we've ever actually detected a real jailbroken device in over 4 years.
Hi,
just discovering this thread as we've been suffering from this since introduction of the over-the-air compliance app check from Boxer.
Same as you, devices are marked as being compromised then in a matter of seconds / minutes / hours, the device is marked as Compliant again.
We had more or less same answers from ticket support at VMware and issue has been escalated for resolution. Waiting for a feedback now.
In our case, support asked if the following URLs are accessible from our devices.
api.na1.region.data.vmwservices.com
discovery.awmdm.com
signing.awmdm.com
The last two are mentioned in the network prerequisites as optional and the first one is not listed. Also, it seems that these URLs must be accessible from the device themselves, which is the case for us as we do not restrict connectivity on our devices.
Given the URLs are mentioned as optional, we have no plans of opening it up from our DS / CN servers.
Final info received from the auto communications from VMWare is the following :
https://kb.vmware.com/s/article/79668?lang=en_US
From the KB it relates to 20.05 version, we're currently on 19.07 , not using tunnel and Boxer has a specific SDK profile attached to it.
Check out the below and see if it helps with your issue.
ESC-22684: iOS devices incorrectly marked compromised after updating to VMware Workspace ONE Intelligent Hub 20.05
View the article https://kb.vmware.com/s/article/79668?lang=en_US
What an absolute joke. Hub 20.05 was supposed to resolve the false positive compromised device issue, and now it also suffers from the same problem.
In our case, support asked if the following URLs are accessible from our devices.
api.na1.region.data.vmwservices.com
discovery.awmdm.com
signing.awmdm.com
The last two are mentioned in the network prerequisites as optional and the first one is not listed. Also, it seems that these URLs must be accessible from the device themselves, which is the case for us as we do not restrict connectivity on our devices.
Given the URLs are mentioned as optional, we have no plans of opening it up from our DS / CN servers.
We were asked the same months ago. We've allowed access to those URLs, and it made no difference. Plus, with COVID-19, most of the workforce is working remotely, so they wouldn't be impacted by any firewall rules.
This KB has been updated.
[Resolved] ISDK-174103: iOS devices incorrectly marked compromised after updating to VMware Workspace ONE Intelligent Hub 20.05 (79668)
Have anyone else noticed an increase on the number of compromised devices in the past 1-2 weeks?
We are on cn763 and the latest 20.8.0.6 release. The compromised devices have the latest Hub app, and after we make a re-evaluation they are marked as compliant.
Its not a big issue, but it is annoying!