With Android 5.0 Lollipop now available for most widely used Android smartphones and tablets, you can now manage those devices at a higher level of security, via Android for Work. Google uses Google accounts as the mechanism for applying discrete policies to content and applications on Android.
But doing so also requires that both the users and IT itself have Google accounts, which starts to make Google accounts part of your identity management equation -- even if you are trying to centralize on Microsoft's Active Directory or similar systems.
That's not necessarily bad, but it is a new wrinkle in the larger issue of identity management at enterprises, which is also evolving beyond single sign-on, the reason most IT organizations use it.
Active Directory broadens its reach
Microsoft has long used Active Directory for more than single sign-on -- policies have been fundamental to Active Directory for many years. SharePoint permissions are a good example of such policy-driven adoption. But it's a safe bet that most organizations use Active Directory in a more binary way -- permitting access to email servers, VPN servers, and so on, or not.
As Microsoft moves Active Directory to the cloud via Azure Active Directory, the opportunity to take advantage of policies is more apparent. For example, with IT concerned over access to and distribution of content and apps in mobile cloud settings, a cloud-based identity manager like Azure Active Directory for more than mere sign-on validation suddenly looks very appealing.
Microsoft is testing those waters in Office 365 as well, with specific content policies managed by its other management tool, Intune. Although I think the Intune approach is too narrow, I bet the larger notion of content-oriented policy management in the cloud will take root in an expanded System Center-like capability in Azure Active Directory that makes narrow tools like Intune unnecessary.
Google accounts ride the Android wave
I'm sure Google sees Microsoft's attempt to reimagine Active Directory for the new world of mobile and cloud, where resources from multiple providers are intermingled and policy-based management becomes more complex and more necessary.
And I see the use of Google accounts in Android Lollipop (as well as for the Google Spam email filtering service that has replaced Postini) to be the identity mechanism as its way of slipping into the enterprise's management infrastructure.
Google requires that you set up a Google account for your company domain that you either bind to Google Apps (which becomes your management tool) or to a third-party management server. In essence, you must place Google at the center of your management systems for Android and/or Google Apps.
You can sync Active Directory to Google Apps (where accounts are managed), so this is not an either/or proposition. But if Android for Work accomplished its goal of making Android safe enough for wide business usage, it will make Google's IDs intrinsic to your identity infrastructure.
The unexpected consequences of having multiple IDs
My company experienced an unexpected side effect of Google accounts being the policy-enforcement mechanism for, in our case, the Google Spam service that is part of the Google Apps portfolio. We're an Office 365 shop, and Google Apps are not officially supported. Yet most of the staff in several departments rely on Google Apps for features like shared calendars and documents that are difficult to do in Office 365, especially in a multiplatform environment like ours.
When IT deployed Google Spam, it had to sync our Active Directory accounts with Google. Previously, we had urged staff to set up separate Google accounts using their work emails to keep personal and corporate data separated. But when IT implemented Google Spam, it disabled all other Google services for the Active Directory-based IDs, cutting off the informal but separate "corporate" Google accounts.
When Google saw that our "corporate" accounts were blocked from services like Google Calendar, Google simply moved the business data to our personal accounts instead. Our informal attempt to separate personal and corporate data were undone, though we were able to continue to use the tool that was right for the job, even if not provided by our company.
This anecdote is an example of the issues I believe IT will face increasingly as Microsoft and Google both try to extend the reach and utility of their identity management tools. It may be that companies will have to embrace, not ban, BYO services like Google Apps. Or companies may need to tighten the screws even more to lock users into only official systems, regardless of their fit to the job.
Even when there's no issue around imposing specific tools on users, the fact that many users will have both Google and Microsoft services that provide policy-based controls will complicate IT management of data and apps. That's inevitable, I think, but perhaps more real than many IT organizations understand.
Apple IDs not a factor, so far
You might have noticed that I haven't mentioned Apple IDs in this context. So far, Apple IDs are not used for the same kinds of policy controls as Active Directory and Google accounts. Apple IDs control access to Apple services, which are aimed at individual users. Although an Apple ID is needed to use an iOS device or a managed Mac, the policies applied to those devices do not depend on the Apple ID -- they typically use Exchange credentials or devices' hardware IDs instead.
Your company will need an SSL certificate from Apple to use push notifications, and a business account to use the private business app store functionality Apple offers. Both are done via Apple IDs, but the Apple ID used by IT is not connected to user accounts or your domain, as Google's corporate account is. Basically, Apple's reach in your infrastructure is less than Google's or Microsoft's.
Maybe that will change, and IT will have three sets of core admin accounts to manage in coordination with each other. Maybe not.
Still, it's clear that IT will have at least two set of accounts to pay attention to.