Physical efforts in virtualization and mobility
So you’ve got a whole bunch of iPads out in the field hosting various applications and iOS9 comes out; one of the application vendors tells you his application isn’t quite ready for the latest OS and that you should hold off on updating your fleet. Problem – If you look for an option to disable iOS updates in your MDM suite you won’t find it, this is not a limitation of your MDM provider but more a control that Apple hasn’t provided to them. So if you ask your MDM vendor they will probably say it’s not possible, and as far as I can tell this is indeed the case. I’m going to keep looking but for now the best we can do is suppress the notifications that pop up advertising to all and sundry that a new version is available, but even this is not an out-of-the-box setting so I’m going to explain how it’s handled in AirWatch.
Now there’s nothing to stop users navigating through the menus to check to see if there is an iOS update, finding one and proceeding to download and update it themselves, so this is about as good as it gets for now. According to the comments this short article it is possible to use applednld.apple.com via a proxy server (although I think it should be appldnld.apple.com – note no ‘e’ on apple) to disable access to the download location but I didn’t have any joy with this. If I ever get any further with this issue I’ll post an update with the final solution.
Quite a bit to get through in this post, ultimately what I want to discuss here is the Apple Device Enrollment Program (DEP) but this subject cannot be reached without first detailing the basic enrollment options in AirWatch, therefore I have made this a two part post which you could skip to if the lead up content is already understood.
End user agent based enrollment
This would be a scenario where the end user is either given an out of the box corporate device or chooses to use a BYOD. The steps a user would take would be something along the lines of:
Now the process detailed above is about the most manually intensive method possible and as you can see the user is required to tap and type several times and to also know or be told a few things about what they are doing. This process can though, be partially or pretty much fully automated as we will see.
The next step up from this handled in the user account setup process, where it is possible to send the user an email on account completion. This email can contain a QR code which has the server address and group ID embedded in it.
Pretty swish, but this method is relatively uncommon because of:
The final agent based enrollment method which is to use; email address.
This is probably the most common method as users will always know this info, it just requires a little more work on the back end to enable.
Pitfalls of agent based enrollment
Whichever way you look at it there is one common dependency on these three methods above and that is that they all require end user interaction. This means that things can go wrong as users may not know the information, understand what they are doing or just not bother enrolling at all because they can get away with not doing so. Another thing that can be done is to offload these tasks to an IT admin who can enrol as administrator then hand the device to a user. The biggest issue with agent based enrollment though is from a security aspect as devices can be simply un-enrolled and left in an unmanaged state.
For BYOD, agent based is the only way to go as users have every right to un-enrol their devices but for corporate devices, particularly on a medium or large scale two things are required; automation and security.
Corporate owned enrollment options
Apple Configurator is a kind of ‘offline’ MDM solution in its own right, as it can stage and apply configuration profiles to iOS devices. The trouble is, it is limited in that cannot work over the air (OTA) or as it must be physically plugged into the Mac OSX device running the configurator software. A USB hub can be used which can bank up to 30 iOS devices which can all be configured simultaneously making mass configuration and enrollment possible with Configurator. This works with AirWatch by having an (AirWatch) MDM profile imported into Configurator and into the banks of devices enrolling them en masse.
Supervision of Devices
Configurator enables ‘Supervision’ of Apple iOS devices which is a feature that enables greater security controls and configuration options. Although this is switched on via Configurator which is a tethered mechanism (in this instance at least), once enabled these additional features can be controlled OTA via the MDM solution of choice if it happens to support them. There are quite a few options that work with Supervised mode, but a few for reference would be to Allow App Removal, use of iMessage and erasing of content, but a more killer features would be things like Single App Mode which can be a very useful option for shared devices as it can lock the device to a single app. For corporate owned devices Supervision should be enabled wherever it’s practical to do so; if MDM is being applied to an existing fleet these will all need to be recalled so they can be physically plugged in to Apple Configurator, in the case of new devices being purchased however, the decision is more straightforward as these can have a supervised DEP profile assigned even before they come out of the box.
Device Enrollment Program (DEP)
First of all I want to point out that I am not comfortable with the use of the word ‘Program’ here which is what refers to a computer program. What we are talking about here is a ‘Programme’ which is more like a project or a system. Anyway, now I’ve proven my Britishness let’s talk about DEP at a high level.
Until last year there was the only option for mass enrollment and device supervision, and that was the Configurator and even that only arrived in 2013 with iOS 6. Then early last year a select few countries had access to DEP and towards the end of the year many more including the UK and may others too. DEP is a system provided by Apple which has been put in place purely to streamline corporate owned device enrolment into MDM solutions. The inner workings will be discussed in a follow up post but ultimately what it leaves the end user with is iOS version 7 or 8 device that can be taken fresh out of the box from a supplier and enrolled using a tailored version of the standard iOS start-up wizard, requiring no administrative involvement or use knowledge of the environment, other than their username and password (can be a basic account or domain).
One of the key benefits of DEP is a non-removable MDM profile can be deployed to the devices; even though both Configurator and DEP support supervision, only DEP supports this. Configuration profiles are not configured within the DEP portal this is all set within the MDM vendor console. We’ll take a look at this in part two of this post.
Samsung Knox and Android
Just for information its worth mentioning Samsung Knox which even though I am an Android Fan boy (FanDroid) it isn’t something that I have any experience of, but it is the only Android platform that supports mass enrollment in a similar way to that of DEP. This also includes Android for Work, the new Android MDM service provided by Google which aims to reduce fragmentation within the Android platform. So it is worth bearing in mind that features such as this are vendor specific on the Android Platform so we will need to wait for either Android for Work to develop or for other manufacturers to catch up.
That’s enough for part one which has been just an over of deployment options in the lead up to a more in depth discussion on DEP.
Just a short one this.
I recently came across a customer who required integration with an on-prem Certificate Authority so it could be integrated into a particular profile (maybe more on this another time). I noticed they were already using Directory integration for enrollment and assigning resources so I assumed an ACC would already be in place. I was wrong about this however as they were using the now legacy EIS component for this (I did find this out before I got there!).
A bit about EIS (Enterprise Integration Service)
According to the AirWatch EIS Guide:
The AirWatch Enterprise Integration Service (EIS) provides organizations the ability to securely integrate with back-end enterprise systems from either the AirWatch SaaS environment or a remote network zone (for example, a DMZ). This integration allows organizations to leverage the benefits of SaaS and their existing LDAP, CA, email, and other back-end systems.
Sounds just like the ACC (AirWatch Cloud Connector) huh? Well it does the same thing but the ACC is current, whereas EIS is now considered legacy. EIS is a bit more of a painful to configure than ACC though as it really requires secure DMZ placement due to it needing inbound communication from the AirWatch Console Server. ACC on the other hand only requires an outbound web connection to the AirWatch Cloud Messaging Service so can quite happily sit on the internal LAN somewhere and go out directly or via a proxy if needed. Despite this, EIS is still in support however and oddly AirWatch are still (on version 8 for example) producing 33 page integration guides fot it which have no mention of the ACC.
EIS doesn’t support quite as many integration points as the ACC does, and for Certificate Services an additional and purchasable add-on pack is required.
Move to ACC
I didn’t want to get involved in any of this nonsense so I just replaced EIS with an ACC. If one was to navigate to the ACC node in the AirWatch console whilst EIS is enabled, this message would be seen:
It’s not as daunting as it may first look, I had a new virtual server ready to run as an ACC so I went ahead and pressed the button, you then go through the ACC installation as normal.
The integration points (directory services in this case) that were previously using EIS remain just as before. These are independently configured nodes so will just carry on and the old EIS server will just be ignored and can be switched off. I then went ahead and implemented the Certificate Authority integration through the ACC so I could use it in my target device profile.
I’ve been working on a couple of AirWatch engagements recently and as a result, my product knowledge has had to move to a lower level. Being more of a ‘Citrix Guy’; from an MDM perspective I’ve had more involvement in XenMobile up until now, but seeing as Citrix is deemed a 2nd tier vendor by the likes of research firm IDC, it’s surprising the lack of resources there is out there for top tier AirWatch compared to XenMobile. Maybe it’s because AirWatch really push the SaaS model where the on-prem is the poor relation (~70/30 market split) so there is less community interest out there.
What I wanted to cover here was how the headline products fit into the AirWatch architecture as at first glance it’s not obvious, to this end I have created a flow chart as a kind of decision matrix. The components will change depending upon requirements and if SaaS is chosen over on-prem.
Below I will briefly cover each of the key components
Device Services Server – This is the Server that actively communicates with the devices and handles enrollments. Seeing as devices will normally be anywhere and everywhere, this server needs to be available on the internet. For SaaS deployments, clearly this will be handled but for On-Prem, this will normally located within a DMZ with SSL punched through to the internet secured with a public certificate.
Console Server – Sometimes called the API server, the server communicates with the Device Services Server and contains a Web App (IIS Site) for administrative control of the environment. This will normally be placed on the internal LAN, but would be possible to combine with the Device Services Server.
Database Server – As with most enterprise products a database is required; clearly AirWatch holds a lot of device data and this needs to be stored somewhere. Note that SQL is the only supported database type and it needs to be full SQL, not express. Again, this could be combined but in larger deployments would be separated to aid with high availability plans.
In a SaaS deployment, all of the above will be hosted and managed by AirWatch, but required for all deployments be they SaaS or on-prem. The following components however, are optional depending upon requirements.
AirWatch Cloud Connector (ACC) – This is nearly always used in SaaS only deployments for bringing the above three components to local customer based back-end resources. Typical integration components would be Directory Services (LDAP), Microsoft Certificate Services, and Exchange to name a few. If you have a SaaS deployment, your AD is locally hosted and you want to configure Auto enrollment for end users to use their email addresses for example, you’ll be needing ACC. This is normally placed on the internal LAN with a direct outbound connection to the internet so it can communicate with the AirWatch SaaS. This can be either direct (preferable) or via internal proxy.
Just a quick note on connecting components via proxy – At the time of writing (v188.8.131.52) proxy PAC files are not supported in the ACC but they are for the MAG!
AirWatch Content Gateway, formerly Mobile Access Gateway (MAG) – The MAG (also known as MAG Endpoint) is a relay for accessing internal content. It differs from the ACC which is more about authentication where the MAG is proxy and content. This component is secured in terms of Airwatch (‘Containerised’) so if you plan to use it you will need to be using one of the AirWatch client based products to access the content, that being Secure Content Locker, the AirWatch Browser and Enterprise Apps that have been subject to AirWatch App Wrapping.
In terms of placement there are a number of options. Really, being a reverse proxy, this is a DMZ type of component but could be a pain to manage as and when you want to open it up to more back end resources, this is because you would need to add rules for each server (unless you cheat and open up a subnet or whatever). If you have no DMZ, it’s simple as there is only one option which will be LAN placement. If you do have a DMZ the best approach would again be internal LAN but also to use the additional sub-component….
AirWatch Content Gateway Relay, formerly Mobile Access Gateway (MAG) Relay – This is part of the same installer as the above but you just choose the relay option. This is designed to be placed in a DMZ and is what your external devices will be pointing at along with the AirWatch Cloud Messaging Service. This simplifies ongoing management in a DMZ scenario as the internal ‘MAG Endpoint’ server can be left fully open to chat to all internal resources whilst the communication remains secure with the relay handling connectivity between the devices, AWCM and the internal MAG. In the MAG configuration on the AirWatch management console it just needs to be told that’s it’s using the relay model rather than basic endpoint.
AirWatch Tunnel – This is a Linux based product that I suspect at some point this will replace the Windows based Content Gateway. For the time being though, both are required if you want to externally publish Content for use with the Content Locker Client App, Wrapped applications and Per-App VPN. In a nutshell, AirWatch Tunnel doesn’t yet work with Content Locker and the Content Gateway doesn’t work with Per-App VPN (and probably never will). Like the Content Gateway, this is also available as a Relay configuration. Something to bear in mind is that as mentioned this is Linux based installation. This does not mean as I expected a virtual appliance, it’s purely a Linux installation which requires CentOS or Red Hat Enterprise, so you’ll need a level of Linux capability to implement this.
Secure Email Gateway (SEG) – Let’s be clear, the SEG isn’t a requirement for end users to be receiving emails on their devices but it is certainly beneficial. The SEG sits between your Exchange ActiveSync server(s) and enables greater control and monitoring of email to and from enrolled devices. ActiveSync is globally enabled on Exchange and while it can be switched off on a mailbox basis and (since Exchange 2010 SP2) be subject to device quarantine rules, it is not very easy to control. The SEG will proxy the ActiveSync communications and block/allow depending upon configured policy.
Cloud Messaging Service – This is mentioned for information, it’s a different sort of component to the above as it is a facilitator rather than something that performs it’s own specific front end function but it is important. It handles messages from the Administrative Console, and is a pre-requisite for both the MAG and ACC. For SaaS deployments this isn’t a consideration as it is preconfigured by AirWatch but for on-prem this needs to be installed and configured, typically on the Device Service Server. Seeing as the ACC is generally only used in SaaS implementations though, this is normally only a concern for MAG installations. Part of the MAG configuration requires the Cloud Messaging Service details to be entered.
Something else to bear in mind is licencing as these components don’t directly fit into their licencing models – well they do, but you have to base the components on the requirements and subsequent licencing model, which will spit out the required components. The licencing models and pricing is available publicly here. You could actually integrate any of the below components and no licensing would be breached but take for example the MAG; yes this could be fully integrated into AirWatch but unless you are doing App Wrapping, using the AirWatch Browser and/or Content Locker (which would require a ‘Blue’ license) it’s inclusion would have no benefit.
So what I’ve done on the flow diagram is to colour the text in accordance with the required licencing banding assuming you are requiring features that require the component in question.
Component Flow Chart
So without further ado, here is the flowchart I have created help with all of this. Note the decision questions are very high level, other questions could be asked of the capabilities particularly around the ACC which has many integration points.