5 Tips to cope with the BYOD post-holiday rush

It’s that time of year again. Tech gifts are set to be the most popular this year again (after socks) and tablets are top of that tech gifts list. When you get back to work lots of your users will have shiny new Android, iOS and Windows devices that they’ll probably bring to the office. Some will use them as a distraction from work but many will want to use them to enable working in new ways. Not only that but this year it’s not just the tech trendsetters that will be getting tablets, it’s everyone at all levels in your organisation. Some people will just leave those devices at home for a start but some won’t and that will encourage more and more people to start bringing them into the office. It’s probably not tenable to just ban them outright any more – this season will put pay to that ability for most I think. So what can you do? We have two months and a few small upgrades might get you right to where you need to be.

1. Email

There can be no doubt that for almost every organisation on the planet email is the number one productivity, communications, CRM, sales, marketing and lol cat tool in our arsenal. If you’re going to spot a crunch point this will be it. If you’re running your email on-premises still it might be time to start considering a move to the cloud and my personal, favourite approach here is to go hybrid.

Enabling a BYOD solution for your business at enterprise scale is going to mean you’ll have more and more people wanting to connect more and more devices to your email servers. Within Microsoft we have a limit of 10 which I recently found myself exceeding. Following this year’s holiday buying fest it’s quite likely that any individual might have: a mobile phone, a small tablet (7-8 inch, a present this year from the other half), a larger tablet (10 inch, bought last year as a present to themselves), a company provided laptop, a hot desk computer (only for when the user forgets their laptop). All those devices are going to “require” email access to make them useful. Of course this is also the tip of the iceberg, next year it’ll be wearables.

Moving the email boxes of users who are entering a BYOD program over to Office 365 and leaving those with more traditional requirements on-premises could be a really smart move. Office 365 gives you this option like no other cloud email service can, integrating into your existing Exchange infrastructure providing that seamless familiar experience that users are used to. It’s too much to go into deep detail in this article about next steps but there are plenty of guides around the web.

2. Work Place Join, Enterprise Registration

The chances are that you know who everyone in your company is, what they do and what they should have access to do. The same is probably also true of your company owned laptops and desktops. The reason is of course that these people and devices have accounts within Active Directory (AD) and those accounts then let you specify what those users and computers are allowed to do and what resources they are allowed to access.

Of course not all devices are created equal, they don’t all run Windows today and even if they do with BYOD they might not be members of your domain, known to AD. Essentially they are ghosts, visible but at the same time hidden. Within the Windows Server 2012 R2 wave we have a feature that helps us manage those ghosts and pull away their white sheet of invisibility, making them known to AD. The feature is the Device Registration Service otherwise commonly known as Workplace Join. This feature is complemented in Windows 8.1 with the ability to workplace join the device and iOS also has a similar ability, although the UI isn’t as slick. When a device is registered by the Device Registration service a few things happen, first an identity is created for the device within AD with a unique GUID (device names Aren’t-used per-se, although it is an attribute of the record) because a device can be enrolled multiple times, potentially by different people. Second a certificate is issued to the device to identify it. Now that our device is known to AD there is all sorts we can do to given the device.

To deploy Device Registration you’ll need to deploy Windows Server 2012 R2, deploy the Active Directory Federation Services (AD FS) role, update the schema, issue some certificates and make some DNS changes. There’s a good guide to building this out in a lab here.

3. Publish your internal sites, externally, safely

Not all your internal websites are the most secret things your company has to offer. The intranet might have some proprietary information on it but you could still publish it securely and safely to people. Especially since we now know not only who they are but from what device they’re connecting. Going hand in hand with deploying AD FS in Windows Server 2012 R2 is going the new Web Application Proxy role which takes internal resources and publishes them externally safely using either claims based auth (AD FS) or pass through auth.

Using rules for those published services, called relying parties in AD FS parlance, it’s possible to restrict the level of access over those published services using authorization rules that take a look at the claims an incoming request is making. Those claims can include device claims, so we can easily publish our intranet and create a rule that says if this device isn’t registered with AD don’t let the connection through, if the device is registered with AD and the user is allowed access to the intranet then allow the request.

It’s actually the Web Application Proxy that publishes the enterprise registration service mentioned previously out to the internet. The Web Application Proxy also acts as an AD FS proxy allowing you to keep your AD FS server inside your network and taking these two services and linking them with Office 365 we can easily develop a single sign on environment.

4. Device Governance

It’s tough to require the ability to control all aspects of an individual’s personal device, in fact in some places it may soon contravene the law to remote wipe someone’s device without their permission, something you may want to do for example when they level the company. The idea of “governance” however is to allow access to specific resources – such as applications or remote help, once the individual has allowed you specific access to their devices.

With this power comes the responsibility to not do such things as wholesale wipe their device. Once a device has been workplace joined we have the ability to start to selectively wipe the corporate aspects of their device. For example we could revoke the certificate that we placed on their device when they workplace joined. If they pulled any data down to their device and we’ve encrypted it with EFS, we would then be able to break the chain of trust that allows the device to access said data. Likewise we can do the same for sideloaded corporate apps.

5. Data Governance

It would be nice if we all knew all of the data inside our organisations. Sadly we don’t, especially when we consider the data explosion and how much data we will be storing in the future (I think storage space is like your salary: the more you earn the more you spend; the more storage you have the more you use!) Our users aren’t much good at managing their data either – they generally don’t understand ACLs and how to correctly permission their data. It would be far better if there were a better, more automatic way. Thankfully there is…

Windows Server 2012 introduced Dynamic Access Control (DAC) and dynamic file classification through File Server Resource Manager (FSRM). Essentially this means that, given some rules, we can have our file servers look at the data they are hosting and apply access controls based upon the content of that data. For example we could look at all the Word documents on our file share and if they contain something that looks like a credit card number (using RegEx) we can classify the files as only for the eyes of people in our customer finance department (this is just file classification not DAC). The DAC part of the equation comes into play when we start to use those applied classifications in addition to the claims being made by the party accessing the files.

The party accessing the files is going to be a user, but the device that the user is using to access the files could vary. In Windows Server 2012 we could take a devices identity in AD (the computer account) and decide that only users with a specific OS can access the files. Now that we have device registration in play too we can not only do this for Windows devices that are domain joined but also for Windows devices and iOS devices that are workplace joined. The upshot being that we could allow Jane from Finance access to a file with a credit card number in only from her Windows 8.1 domain joined device but not from her iOS device unless she registers the device and we therefore have the ability to track the data. All of this has been done without IT needing to understand the specific document or the specific device she used.

Summary

Hopefully this article has been a little thought provoking. It’s probably a very big ask for you to get this stuff into production in time for the holidays but at least you can start to think about building a lab to try this out with those devices that Santa leaves for you. You’ll need some lab guides, and the Windows Server 2012 R2 and Windows 8.1 Enterprise Evals to be able to do just that – luckily it’s all free to try, our present to you.