It's coming to be pretty much understood now that you can't put the MDM Gateway on a NAT'd IP address. The reason why is that it 'breaks' the Alerter service, and thus the Wipe Now capability is lost.
In reality, it's acting as designed; the client will check the source address of an alerter message and if the source IP address has changed (as it must, when NAT is used) will failsafe and presume that the originator cannot be trusted and thus will drop the packets.
It looks like things aren't working, when in fact they're working exactly as they're supposed to, with Security first and foremost.
Inconvenient, perhaps, but well thought-through and well implemented.
Bear in mind that "Wipe on Next Connect" is not impacted here since the device will re-connect to the DM on whatever schedule the admin has defined (default is 8 hrs) and then will accept and process the Wipe command.
One suggested workaround is to use the Exchange device wipe capabilities instead, since there is a high probability that waiting until the next connection is unacceptable and the device really does need to be blown out of the water sooner rather than later.
Actually, the risk of waiting until next connect is that the target device can be connected and accessing your LoB hosts as normal. The 'next connect' refers explicitly to the device checking in with the DM to see if there are any packages, policies or commands waiting for it. In the meantime it's business as usual.
Can definitely see that being unacceptable for a lot of folks.
Subscribe to:
Post Comments (Atom)
1 comment:
One thing to keep in mind also when using Exchange wipe is that until the user removes the wipe request (typically from OWA). The device will hard reset everytime it syncs.
Ensure your users action this before re-configuring activesync on the same device!
Post a Comment