Intune is a robust toolset. I’ve talked in the past about how much it has grown over the years, from basically WSUS-in-the-cloud to a real MDM solution, and now to a full-service solution for managing and delivering similar access and experience for users across a wide range of both mobile and traditional compute, personal and corporate devices, and even controls for kiosk solutions. That’s a big story arc for a single product, and now we’re in the midst of the single biggest admin overhaul I’ve ever seen, bringing all that functionality and control into an interface aligned with other Azure solutions.
But all of that added functionality brings a fair amount of confusion. Most of the deployments I’ve performed of Intune, to date, have been in environments that did not already have an MDM solution. Intune may have been replacing an app deployment and patch-management solution, but rarely have I been involved in a direct replacement for anything governing access. And yet that’s one of the main selling points of Intune: sure, we can manage your devices, but we can also use it to govern access into services.
I got the pleasure of performing exactly such an implementation recently, and for the first time I came to value exactly what “integrated” means. The solution being replaced was an industry darling. It offers many of the same controls, but runs on-prem on a server. That server is tied to a network device. That network device forwards ActiveSync authentication requests to this server, which registers the device and then authorizes it to access ActiveSync to Exchange Online. All pretty normal stuff, except it does this through a series of automated tasks that run on PowerShell. Cool. I dig PowerShell.
But PowerShell isn’t true integration, and ActiveSync is just a single protocol out of many, so the solution being replaced relies on a setting in Exchange Online that just blanket-allows or blanket-denies (or quarantines, if you want to drink from the fire-hose of admin approval requests). No per-user or per-group configuration options exist, though Exchange Online does at least allow us to apply these protections to specific platforms. That’s a huge relief, because effectively that becomes our only path to migrate from this solution to Intune.
It turns out that this particular solution doesn’t much care for the Outlook App for iOS or Android. This customer had set all ActiveSync connections to deny, then allowed this on-prem MDM to connect via PowerShell and individually enable access per device. Outlook doesn’t use ActiveSync, though. It uses a stateless protocol translator to access the mailbox through its own API, and the on-prem MDM didn’t know how to handle this access. Intune does.
With the non-integrated MDM solution, the customer relied on Exchange Online to reject the client, then the MDM solution to register and accept the client, then PowerShell commands to update the user’s ActiveSync controls. The replication cycle was lengthy, and often configuration changes that appeared to be initially successful would then update and break unexpectedly. Intune flips the script and allows us to accept or block access at the account level, to handle that authentication directly within Azure, and THEN decide whether or not to grant access through compliance and conditional access policies to the data.
And while all of this control is great, the implementation is still incredibly confusing, and that’s not helped by the nomenclature. Conditions control access (wear a suit to the interview if you want the job), configurations control devices and apps that are enrolled or controlled (business casual is fine once you’re hired), and compliance governs settings that must be satisfied to maintain access (if you do not wear shoes, we will send you home). And of course there are settings that overlap, and some that rely on other settings already being configured elsewhere in the tenant. Exchange Online conditional access, for instance, does not work if Modern Authentication is not enabled in the tenant.
These settings add up to create a multi-faceted set of controls, but getting through the initial configuration can make you feel like you’re seeing double, because yes you can enforce encryption through both configuration and compliance controls, and yes you can govern device password configurations in both, but if you think of the controls more like a set of guidelines for working in an office and less like PC settings, the overlaps become a little more logical and the pieces start to fall into place. Then you can rest easy knowing that Intune’s controls are constantly monitored, so you’ll always know when a phone tries to take its shoes off in the middle of the day.
Comments