There’s no doubt that an explosion of private, generally unmanaged devices is underway. Sometimes, organizations want to save money and so encouraged users to supply their own devices; sometimes, users would sneak devices in the back door without waiting for IT policy to catch up; and sometimes, users preferred their own device or wanted to carry one device that held work and personal data and connections. Whatever the impetus, Bring Your Own Device (BYOD) has come to be.
Of course, with BYOD comes new security threats and new compliance concerns. When users are restricted or cannot use a mobile device, frustration may grow and productivity may plummet. The Windows Server 2012 R2 operating system introduces two new concepts for devices, device registration (known as Workplace Join which is a feature of Active Directory Federation Services).
You implement device registration by using the Workplace Join feature of AD FS. Users can register their devices to allow single sign-on scenarios or to gain access to corporate data that may otherwise be blocked.
Prior to Workplace Join, a device was either in the domain or it wasn’t. Of course, to be in the domain, it also had to be a PC. Various management tools (including Microsoft System Center Configuration Manager and Exchange ActiveSync [EAS]) helped to bridge the gap, but it was still essentially binary. Non-Microsoft mobile device management tools became popular, but even with all of this in place, you couldn’t control which resources a mobile device could access and which it couldn’t.
Now, there are essentially three states for any given device:
The organization can now decide with much more flexibility and granularity which group of devices can access which information. For example, you may allow unknown devices to access applications with lower sensitivity such as an intranet but require devices to register (with Workplace Join) before they can access the internal HR and Finance site.
When a user registers a device, it’s a “give and get” scenario. The user “gives” by registering the device and in turn “gets” access to resources. Although some users may not be willing to make their device known to the organization, the organization may in turn choose not to allow them to access confidential information.
Technically speaking, during registration, a certificate is installed on the device and a new device record is created in the AD DS. This device record establishes a link between the user and their device. Because the device is now “in” AD DS, it can be used as part of a claims-based authentication process (Active Directory Federation Services [AD FS]) and referenced in conditional access policies.
You need to complete a few steps to get Workplace Join up and running:
For BYOD registration to be effective, it has to work with the devices that users have. That includes devices that run Apple iOS, Google Android, and of course PCs running Windows 8.1 that for one reason or another are not joined to the domain.
Configuring a Windows client is easy as long as it’s Windows 8.1:
From an iOS device, the process is equally straightforward:
You should now be back in Safari. You’ll see a message letting you know that you can close or leave Safari.
With Samsung Android, the user can register their device using the “Add Account” process, choosing Active Directory. This will step the user through the same process or requesting their credentials and completing the Workplace Join.
That’s it. Your device is now registered by using Workplace Join. For details and instructions on how to set up a test lab, see Walkthrough Guide: Workplace Join with an iOS Device.
In our next post, I’ll talk about synchronizing data to home or personal devices while maintaining information protection.
NEXT BLOG POST IN THIS SERIES: Syncing and protecting corporate information (Coming June 12)
Catch-up with the previous entries in this blog series:
Part one: Setting up the environment here
Part two: Making resources available to users
Learn more about Access and Information Protection here.
Comments in this blog are open and monitored for each post for a period of two weeks after the posting date. If you have a specific question about a blog post that is older than two weeks, please submit your question via our Twitter handle @MSCloud