Mobile Device Manager
Posted by BPuhl on July 15, 2008
Wow, it’s been a remarkably long road to getting System Center Mobile Device Manager deployed here internally at Microsoft – and to be honest, we really don’t have it released to the general population yet – but since we’ve got the infrastructure stabilized, and enough pilot users to be “close enough”, then it’s probably a good time to start a series on “How Microsoft IT designed and deployed System Center Mobile Device Manager.” Of course, that’s really long, so let’s just call it part 1 for now.
First off, we’re still actually in a little bit of flux in terms of the service offering and how everything is going to work. There were some definite design details which were completely missed (by me), that we’re going to need to go back and fix. So the first disclaimer is:
This series is based on my experience up to the date of this post. I’ve found that I’m really bad at coming back and correcting blog posts when things change, but I’ll continue to do my best. by the time you read this, it may or may not describe what is actually in production at Microsoft anymore.
(2nd disclaimer: These are in the order I’m thinking about them, not necessarily the order in which they occurred or in which might make sense to anyone else)
Ok, so one of the hardest things that we had to figure out for our SCMDM deployment, was what we were going to do about user authentication. This may or may not seem obvious, but it turns out to be a ridiculously complicated conversation with fairly passionate arguments on each side. The basic question, was whether or not a local PIN and a strong PIN policy, is sufficient for “user authentication” in our environment. Here are some of the things we thought about:
- If <configurable X> number of bad PIN’s are entered – the device explodes (well, ok, it wipes and all sensitive data is erased)
- PIN policy can be specified and pushed down to the device via MDM (or OWA), so you can make it whatever you like
- The PIN’s are local to the device
- There is no enforcement to periodically “change” the PIN’s
- There is an implicit assumption that since a person is able to use a device, they entered the right PIN, and must be the user
- The person entering the PIN has “physical access” to the device: Law #3 of security – physical access
- When talking about “2 factor auth”, one of the factors cannot be the device/laptop/Computer itself – separate from the device, there would need to be a “something you have” and a “something you know”
- How does this extend, if you wanted to use the phone itself as the “something you have” to log onto a laptop? (outside the scope of this deployment, but a fun conversation anyway)
- How do you manage “deprovisioning” of a device, if a user is no longer employed
- It’s difficult to know which user is associated with which device
- Remote Wipe functionality in MDM requires that the VPN connection be established
- Because Microsoft does not provide the devices, they are personal devices, therefore we cannot restrict the ability for users to turn off the VPN connection
- Active Directory user accounts are the enterprise acceptable form of user authentication for applications
- User credentials are already stored on the device anyway – since everyone uses ActiveSynch for Exchange/Outlook access
After batting these things around quite a bit, we decided that the “wild west” culture of our environment, where we have more of a laissez-faire culture with respect to users (while at the same time being responsible for protecting our data), required that we leverage our existing account provisioning and deprovisioning processes to enforce security.
So although the “standard” MDM deployment architecture allows for authenticated mobile devices to have unrestricted access to the corporate network, we needed to deploy in such a way that we could enforce user authentication, and only allow access to those resources which MS IT Security approved for mobile devices. This basically translates to High Business Impact (HBI) classified data being excluded, and everything else was fair game.
Over the next few posts, we’ll talk about “how” we enforced this, and what this meant to our deployment…