Physical efforts in virtualization and mobility
Following on from my last post which focussed on traffic flows to enable remote connectivity, I thought I would look at the internal side of things. I am coming across more and more on premises environments where there are lots of VLANs with firewalls inbetween them so this is becoming more of a requirement.
For this post I have just produced a diagram which you may find useful, when I get time, maybe I’ll produce another firewall spreadsheet. This diagram assumes that there is a common server VLAN hosting the likes of the Connection Servers and App Volumes Managers so I have not added the ports required between those sorts of components.
You may have noticed that I favour flat diagrams over the 3D ones that VMware produce. I have created a basic Visio stencil set for these which you can download if you wish.
When deploying Virtual Desktop/Application remote access solutions you often need to engage with ‘The Firewall Guy’. This can often be a difficult conversation involving lots of questions such as “what?”, “from where?”, “to where?” and “why?”
To this end I have created a Unified Access Gateway Firewall Rules Generator which you can download. You just need to plug in the parameters on the lookup tab and it will pre-populate the firewall rules for you. Other than the standard back end stuff which you (as the Virtual Desktop Consultant) should already know, the only things you need to ask the firewall guy for are:
Hopefully you won’t even need to talk to the firewall guy at all after that! You can fill in the sheet and email it off to him/her. Here’s a diagram I put together with the ports:
I’ve used the PowerShell deployment method before but since 2.8 the OVF deployment actually works properly so it’s just as easy to deploy it that way then import your predefined settings from a JSON file.
So it turns out that TLS 1.1 and 1.2 is not supported on the NetScaler VPX platform to communicate with the backend servers.
Update: At the time of writing this was the case but support has now been provided with version 10.5 Build 65. MPX and SDX appliances would also be affected if they are running firmware older than 10.5 Build 58. I have since load balanced these services successfully using MPX 10.5 Build 60.7004.e with no need to carry out the procedure below.
The check boxes are there on an SSL Service Group but they won’t allow you to tick them. The trouble with this is that Horizon View 6.2 forces use of 1.2 on Server 2012/R2 so if you have created an SSL service group and point to 6.2 Connection servers (or recently carried out an upgrade), the members will show as Red (Down). Given the lack of support on the NetScaler end, the only workaround at the present time is to add TLS 1.0 support to the connection servers, which is achieved by editing the View LDAP instance on the Connection Servers using ADSI Edit. Below is a procedure I have adopted from the VMware documentation center but is specific to this issue:
1. Start the ADSI Edit utility on your View Connection Server computer.
2. In the console tree, select Connect to.
3. In the Select or type a Distinguished Name or Naming Context text box, type the distinguished name DC=vdi, DC=vmware, DC=int (exactly this DN, not your own domain)
4. In the Select or type a domain or server text box, select or type localhost:389
5. Expand the ADSI Edit tree, expand OU=Properties, select OU=Global, and select CN=Common in the right pane.
6. On the object CN=Common, OU=Global, OU=Properties, select pae-ServerSSLSecureProtocols, this will be configured as <not set>
7. Enter the following string in this field \LIST:TLSv1.2,TLSv1.1,TLSv1
8. Restart the View Connection Server Service
You do not need to do this on the other connection servers as this change will replicate to all other servers in the cluster. Restarting the Connection Server service on all of the all of them will suffice. As a side note, this also seemed to affect Imprivata OneSign appliances connecting to the Connection Servers so it looks like they don’t support TLS 1.2 either.
DEP was discussed at a high level in the previous post; it is a facilitator for corporate owned iOS devices to be quickly enrolled into MDM solutions, all of the major MDM vendors support this.
First off, an account is required to manage the DEP portal and the devices within it. This is essentially another Apple ID which is created at https://deploy.apple.com – I think it is worth pointing out here that I tried using the same account that was used for management of the APNS certificate to start with and this wasn’t allowed so be prepared to manage two accounts going forward, one for DEP and one for APNS.
Now this process will be pretty much the same for any MDM provider but true to form I’m using AirWatch here. What we are doing is linking the MDM solution with the DEP account which contains the devices, once complete all of these devices should appear in the Device Lifecycle section of AirWatch (it may not actually contain any devices at this stage so this may happen later). So head over to the AirWatch console and navigate to:
System > Devices and Users > Apple > Device Enrollment Program > Configure
In order to link the two systems a token needs to be uploaded from AirWatch to DEP so from within this section, select to download the MDM public key file and then click the link to be taken straight to the DEP page and log in with the account created previously.
Once within the DEP portal you may be startled by how sparse it is, there really isn’t very much one can achieve in there over and above the initial setup.
Considering DEP holds your organisations inventory of iOS devices you may think you could run reports and so on from here but this is not the case. DEP will provide a very high level overview of what is in inventory and some rudimentary details of the MDM server(s) (yes you can add more than one) that is linked to the DEP account, other than that all other management and reporting is handled within the MDM tool.
Finally there is the opportunity to assign devices if they are actually ready at this point, which can be assigned via either order number of by serial number. At this point it should be explained that DEP only ties into affiliated Apple resellers, if you do not purchase them from such a supplier DEP will not be an option for you so ensure you ask this question of the supplier before committing to an order. Personally I would always use the Order option as you will get the whole lot dumped in there with no messing about, in fact once up and running the supplier can simply drop devices into the portal (you will receive an email notification) and so long as the ‘assign automatically’ box was ticked on the server setup in the previous section, no further administrative action is required on your part. If you like though, you can not do this and paste in the serial numbers to DEP and have them enabled that way.
(Back to the) AirWatch Console
So here we are back at the AirWatch Console and we are now in a position to create the first DEP profile via completion of the DEP wizard. First of all you’ll be prompted to upload the Apple Server token file that was downloaded from the DEP portal previously to complete the linking process.
The wizard will then guide you through the creation of the first DEP profile; after which, additional ones can be created manually. As I have been through the wizard previously on my deployment I can’t re-invoke it without a lot of phaffing about so below I have will go through the settings as part of the manual profile setup which is the same but just displayed differently on screen. The profiles are split into three sections, Authentication, Features and the Setup Assistant:
Authentication can be simply enabled of disabled, the default is ‘On’ which will result in an authentication prompt for the user as part of the enrolment process. Below is how this section will change if Authentication is set to ‘Off’. The device can be ‘Staged’ in this mode, so enrolled and ready to go but not tied to any particular user. The options here are for:
Note, if Single or user device is set an AirWatch basic account would be selected and used to enrol the device which can help place the device into a specific Organisation Group.
Going back to the first screen shot above, the next option is the Device Ownership Type. Now I’m struggling to think of a scenario where anything other than Corporate Dedicated would be used here with the other two options being:
Employee Owned (BYOD) devices just don’t fit in into the DEP model at all, not least because end users wouldn’t be able to purchase and link them into DEP (happy to be corrected on this)
Corporate Shared would be better using no authentication and staged as the below screenshot shows but instead selecting the ‘Multi-User device’ staging mode. Users can then authenticate as and when each time the ‘check out’ a device so it can be returned to the pool for the next user.
Lastly in this section, the device ownership is selected for the profile along with the organisation group where you want the device to land once enrolled. These options will change again based upon previous selections, for example if Multi-User Device is selected, ‘Corporate Shared’ will be enforced and greyed out.
Here we set the Profile Name, Department and Support number which are compulsory free text fields followed by some DEP specific MDM settings.
Require MDM enrolment – Yes there is an option disable enrolment as part of this process, I really don’t know why you would disable this but the option to skip is here folks if you chose to. This is pretty smart because if there are ever any issues with the iPad or there is a change of ownership, you can send the device a full device wipe instead of an enterprise wipe; it will then be back to an out of the box configuration maintaining the enrolment settings and enforcement into the MDM server.
Supervision – As mentioned in the previous post which covered supervision, for the Corporate Owned model, which DEP is aimed at I would always enable this to expose the enhanced management and security features to the MDM profiles
Lock MDM Profile – Again mentioned in the previous post, for Corporate owned, this would normally be enabled so that the secure profile cannot be removed by the end user.
Device Pairing – This is whether you want the end users in question to be able to connect the mobile device via ISB to a workstation to use things like iTunes. This is probably the only option here that’s worth giving any real amount of thought to disabling.
The ‘Hola’ welcome wizard that most iOS users see out of the box can be tailored in this section to streamline the start-up process. I’m not convinced these require much explanation as they are fairly self explanatory but most of these would be set to ‘skip’ to make the process fast for the end users. It is worth not skipping the Apple ID though as a valid ID will be required to download the MDM agent on enrolment from the Apple Store. Most of the other items can be managed via MDM profiles anyway.
Something very important not to miss in order to close this process off, is to actually assign the DEP profile to the devices. Going to the Device > Lifecycle > Enrollment Status page you can select one multiple or all devices. Then select to assign DEP profile as shown below.
This can be a bit of a pain if you have multiple DEP profiles to assign to different devices.
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.