This article is more than 1 year old
Get comfortable with mobile device management
A walk through Casper Suite
This article was produced in association with JAMF Software
Mobile device management (MDM) is very much the thing at the moment. And frankly it's about time.
Until quite recently if you wanted users to have mobile devices connected BlackBerry-style to the corporate network – securely and natively without faffing about running up VPN software, and controlled centrally so they can be remotely wiped and corporate security policies can be imposed – the choice has been… well, to go and buy a load of BlackBerrys.
Happily software vendors realised a little while ago that organisations actually wanted to use iPhones, iPads and Android devices, but that BlackBerry had the market stitched up. So they set out to make similar functionality for iOS and Android devices.
Even BlackBerry realised that there's more to life than having a BlackBerry phone and introduced iOS and Android support with version 10 of its Enterprise Server.
We have written rather a lot about MDM lately, but we have not gone into any great detail about just what MDM does, what you can use it for and what it actually looks like.
So this feature will walk through how you get started with MDM and what you can do with it. The product we will use for examples is Casper Suite from JAMF software, a bunch of people whose office is just around the corner from my favourite Minneapolis pub.
They have a slightly unusual approach in the MDM world: rather than focusing on handsets spanning multiple platforms, they do device management for pretty much anything in the Apple camp, though these days there is some Android support in there too.
I used Casper with my lab iPhone 5. With this product you have a couple of choices: you can run an in-house server or you can run off a hosted version. Given my penchant for cloud-based services, I went for the latter.
How to enroll
If you plug a Windows PC into your corporate LAN you can't magically enforce group policies and other corporate standards on it. To do that you have to join it to a Windows domain.
Similarly, you can't just take a handset out of the box and enforce company policies on it. The device has to (a) have software on it that deals with the client end of a management suite, and (b) be registered with a server that deals with the corporate end.
Many people don't know that Apple's iOS these days includes as a native part of the code a pile of corporate security and MDM features that pretty much deal with item (a); if you don't use enterprise-type stuff you would never know (or need to know) they are there. The JAMF Software Server (JSS) provides the other end.
There are various ways to enroll a device, though the one I tend to use with any MDM package is simply to point the mobile device at the appropriate enrollment URL and walk through whatever wizard is thrown at me. Sometimes you need to initiate the enrollment from the server, but often you can just initiate the connection from the handset.
With the JSS enrollment wizard you start by authenticating to the server with the credentials of the person using the handset, then you specify whether the device is owned by the company or is the user's own.
This is one of the nicest features of modern MDM systems: you can have complete control over the handsets belonging to the organisation but users working with their own devices are not handing them over entirely to the company.
So with the JAMF offering you can't wipe a personally owned device or fiddle with configuration profiles, for example, though you can install and remove institution-specific apps and data (JAMF has standardised on the term “institution” to refer to the company or organisation). With institutionally owned devices you have pretty much carte blanche.
Once you have decided on the type of install you are going for, you have to install the security certificate (it does all the work for you and you just enter your PIN for confirmation) and the MDM profile (same again, nice and easy).
The device should now wink into existence on the server GUI. The inventory process will hoover down the information about the device and its contents and present it to you.
What's in a policy
Once you have one or more devices under management you can start applying policies to them. To do that we need to understand what policies actually do.
In a JAMF world you manage institutionally owned devices with configuration profiles, which we will refer to as CPs. You can do less for personally owned devices than for institutional ones, and you do it via an equivalent concept called a personal device profile.
There are bazillions of options on the list of things you can control and restrict
The CP defines everything people can and can't do with their company-owned phones. Like many packages of its kind it can be a bit hard to comprehend as there are bazillions of options on the list of things you can control and restrict. The JAMF package has no fewer than 24 subsets of features in a CP.
Usually, though, you need to fiddle only with a handful of the sections. I recommend spending a few hours experimenting with a test device and trying out the various options so you get to grips with what they do.
The things you are most likely to use are at the top of the section list: passcode control (you can insist on devices having complex passcodes, for example); Wi-Fi, defining the wireless LANs the device is able to connect to; mail, LDAP and ActiveSync for corporate email connectivity; and restrictions.
The last of these is the biggy and is split into three sections: functionality, applications and media content.
In the functionality section is a long list of core features that can be enabled or disabled – from whether users are permitted to use the phone’s camera or take screenshots down to whether in-app purchases or interchange of documents between managed apps and unmanaged apps are allowed (those you have specified as part of your profile versus those users have installed themselves).
In the applications section you can define whether users can access the Game Center or Safari, and in media content you can allow or deny access to movies, TV shows or applications, based on age ratings (perhaps phone companies should start offering that to customers for their children's phones).
There is also control over forcing the device to go through a web proxy or to filter web access based on a set of rules you define, and you can force the mobile device to connect only to specific mobile provider APNs (data network services).
As a quick example I defined a CP that disables the camera and Siri and dropped my test phone in it. By the time I had unlocked the phone the camera app had vanished from the front screen, and sure enough, as intended, Siri wasn't answering either.
The JAMF offering, given the company's historical focus on all things Apple, has plenty of Apple-specific features alongside the generic ones. So you can limit the devices that AirPlay can connect to, for example, and define settings for AirPrint-compliant printing.
Think of the users
We have looked at what MDM is and how you enforce policies, so now for the final step: implementing it for real.
This is the most important part because it includes the key concept for any IT deployment: design. In any MDM offering you have a bewildering array of options, some of which sound simple but may have more far-reaching effects than you realised before you read the manual and tried them out.
Most MDM platforms make it easy to tweak policies and deploy the new version to the field. Without due consideration you could break your world spectacularly with just half a dozen clicks.
For instance if you are defining a new Wi-Fi policy you could find yourself sawing off the branch that some or all of your users are sitting on. If you inadvertently configure their devices so they are unable to connect to your corporate network, how are you going to deploy the corrected policy to them?
Another point that I found out the hard way is that you also need to consider the user experience when you make a change. You could bombard users with alerts and other confusing messages if you are not careful.
In this test, for example, when I re-enabled the camera on my iPhone policy in the lab the phone threw up an alert that FaceTime was now able to use the camera and then my Mac warned me that I had enabled FaceTime on my phone.
When you are designing and enforcing policies, then, it is crucial to have a rigorous regime of testing and deployment so that you don't inadvertently blow up your world or bug your users to death with umpty-squillion warnings through scattershot deployments.
Steps one, two and three
MDM is really not hard when you think of it as a series of steps. First you have to connect your device to some kind of control server; then you have to design, test and implement the policies you want to enforce; and finally you have to deploy them.
There are more and more cloud-based MDM packages on the market these days and I think these are the way forward – no more mucking about running up resilient pairs of servers on your LAN and configuring inbound connectivity through the firewall.
And the great thing about MDM is that you can approach it a bit at a time; you don't have to go the whole hog and implement everything all in one go.
In fact in my day job I am doing precisely that: as we implement MDM we are taking the opportunity to gradually roll out the package's other features because they have tangible value to the business. ®
The Register is running a series of BYOD workshop articles in association with Jamf.