Where Google MDM Falls Short
I found that the administrator cannot dictate via policy the maximum number of incorrect log-ins before the device wipes itself, so depending on the device platform an attacker could continue a brute-force attack without consequence. For instance, the Windows Mobile devices both defaulted to allow seemingly billions of password guesses without consequence, while the N97 disables the password for a 5-minute interval after 5 incorrect log-in attempts. Once the device successfully synchronizes with Google Apps Premier, the device appears on the appropriate user's settings page within Google's domain administration console. There are no views or reports of all devices attached to the domain, so administrators can't get a good global view of devices or mobile usage across their entire domain. Instead, to find a device a domain administrator first needs to know which user account is synchronized with the device.Also, Google doesn't report ongoing usage of a device. I could see the date and time of each device's first synchronization with the domain, but I could not view the last time of synchronization, so administrators won't be able to tell whether a device is still in use. The last feature available to administrators is a wipe command. On the administrator's user management page, each device synchronized with the user account offers a link to trigger a remote wipe command the next time the device attempts to synchronize. I attempted a remote wipe on the iPhone, Windows Mobile phones and the N97, and found that the wipe action triggered and completed successfully within minutes, provided the device was connected to the cellular data network or to a WiFi network. However, on the management side of things, I could not necessarily tell that the wipe was completed successfully. In one test case, the HTC Fuze running Windows Mobile 6.1, the management console showed the wipe completed successfully with a time stamp. For every other device I wiped, the console never received-or never reported that it had received-an acknowledgement that the wipe command had either started or completed. Instead, each of those devices continuously showed that the "device will be remotely wiped during the next sync." So, theoretically, in cases where a user reports a phone lost or stolen and requests that the administrator wipe the phone, then later finds the device and tries to reactivate it and connect to the domain, the phone will wipe itself over and over again until the user calls the administrator again to cancel the wipe command. Indeed, because of the limited set of interactions available from Google at this time, I think it would make sense for users to be allowed to wipe their own devices via the Gmail Web interface's Settings page. As it now stands, only the domain administrator can remotely wipe a phone, so the user needs to initiate a help desk call to wipe the phone and would need a second call to rescind the order. If administrators could choose whether users were allowed to remotely wipe their own devices (with an alert being sent to the domain administrator when that action is taken), then administrators may be able to reduce the number of support calls that come in.
On the user page, Google reports an extremely limited amount of detail about the device. It's tough to say whether this lack is because of Google or the device manufacturers, as mobile device makers often implement ActiveSync slightly differently and the ActiveSync protocol doesn't do a good job of specifying what device makers need to report about themselves. So while I found the Nokia N97 showed up definitively on Google's admin page as an N97, the iPhone 3GS was reported only as an iPhone and the iPod Touch as an iPod, and both Windows Mobile phones showed up simply as PocketPC devices. There were no other differentiating details to go on like an IMEI or serial number.