Microsoft introduces several new features in Windows Server 2012 R2 aimed at crossing the gap between company-owned managed devices and employee-owned personal devices. As the divide between work and private time blurs, the line between these two types of devices is blurring rapidly as well.
This trend is commonly referred to as the “consumerization of devices,” “people-centric IT,” “enterprise mobility management,” and “bring your own device.” We’ll use the acronym for the latter, BYOD, in this series to clarify the actions systems administrators can take to help their colleagues be productive on their own devices and, at the same time, remain in control of where the organization’s data resides.
With Windows Server 2012 R2, the following new functionality is introduced:
- Workplace Join
- Web Application Proxy
- Work Folders
This new functionality also works beautifully with the latest release of Microsoft Multi-Factor Authentication Server (built by the PhoneFactor team, who was acquired by Microsoft in 2012).
Let’s quickly discuss these.
Workplace Join ^
With Windows Server 2012 R2, Microsoft introduces a new domain coupling ability as an alternative to the rigid and Windows-only domain membership. With this feature, an object is still created for a “trusted” device, but this time the device is coupled to a specific user account. Other big differences between these new “device accounts” and the computer accounts that we’ve known for ages are as follows:
- Device accounts automatically expire after 90 days.
- Group Policies cannot be applied to device accounts.
- Device accounts cannot be configured for logon with NTLM or Kerberos.
But the biggest difference of all is that you can create device accounts through Workplace Join on non-Windows devices, too. Colleagues can Workplace Join Windows 8.1 home editions, Windows RT 8.1 devices, Windows 7 devices (after a download), Windows Phone 8.1 devices, and iOS devices (with Android devices being supported soon).
Colleagues would Workplace Join their devices to get a major benefit: Single Sign-On. On workplace-joined devices, after logon to a website or web service with claims for the first time, a cookie is created that allows the session to persist, thus allowing Single Sign-On. Colleagues only enter their credentials once; as long as these credentials remain valid, the website or web service can be accessed without the need to manually log on.
Web Application Proxy ^
While on the subject of claims-based authentication, the Web Application Proxy is of special interest.
You’ve all known the ability of Active Directory Federation Services (AD FS) to provide claims to colleagues based on their on-premises (Kerberos or NTLM-based) authentication to Active Directory Domain Services (AD DS). This way, Kerberos tokens are transformed into SAML and/or OAuth2 tickets.
In terms of claims, the Web Application Proxy was designed to perform this transformation the other way around. The Web Application Proxy is placed on the edge of a network, where it functions as both a Reverse Proxy and an AD FS Proxy. Colleagues may access Kerberos-based web applications behind the Web Application Proxy while authenticating with claims. The web application itself may understand claims, but it may also be completely oblivious to claims-based authentication, at which point the Web Application Proxy transforms the claims ticket to a Kerberos ticket on behalf of the user. (Indeed, Kerberos Constraint Delegation [KCD] is at play here.)
This way, the Web Application Proxy allows system administrators to open Kerberos-enabled web applications to external federated identities without the need to adapt the code of these applications.
Work Folders ^
Of course, many colleagues will still continue to use Windows devices. On Windows 8.1 devices, Windows RT 8.1 devices, and Windows 7 devices (again, after a download), a feature called Work Folders can be used to synchronize the contents of the colleague’s private work folder to his or her device. While this doesn’t sound spectacular yet, you should know that the synchronization of Work Folders is based on block synchronization and uses the universal firewall bypass protocol: HTTP over SSL (HTTPS). Best of all, the backend to Work Folders is just a Windows Server 2012 R2–based File Server, not a database, so all your file screens, quota settings, data-deduplication, and encryption policies apply to the data in Work Folders.
Multi-Factor Authentication ^
For some scenarios, organizations will want to use multi-factor authentication. With an additional authentication factor beyond the set of credentials for a user account, organizations can more safely determine if the user is actually the one authenticating.
While tokens and smartcards have been around for quite some time, organizations can also benefit from the “consumerization” trend in terms of multi-factor authentication. Most people own a smartphone (either one the organization gave them or one they purchased themselves), and people tend to keep it handy. Wouldn’t it be awesome to use that device as an additional authentication factor, by sending it a challenge in the form of a phone call, a text message, or a challenge from a soft token supplied by an application running on the device?
With Microsoft Azure Multi-Factor Authentication (MFA), you can.
The need for a lab ^
Many organizations are looking into these features to accommodate the Bring Your Own Device (BYOD) trend and to find a balance between making colleagues productive on their own devices and keeping control of their IT infrastructures.
As I’ve been explaining many of the new BYOD-related features, I’ve found that, for most systems administrators and CIOs, the concepts of claims-based authentication are hard to grasp and even harder to make the (business) case for. A lab, where colleagues can experience what it feels like to use their own devices to access an organization’s apps and data in a secure manner, is a big help.
That’s why, in this series of articles, I’ll walk you through setting up such a lab.
First, let’s look at the choices I made to make this lab accessible from the outside world and to set it up to be as cost-efficient and as usable as possible.
I decided to use Microsoft Azure to build the BYOD test lab. Azure is really easy to use, and this step-by-step guide shows it. Of course, you could use this guide to build your on-premises test lab, but beware that this will take some more effort and upfront investments.
With the choice for A0 virtual machines in Azure, the lab environment would cost approximately $30 per month, but only when we leave the virtual machines on 24/7. Of course, we don’t need to do that…
When you’re an active MSDN subscriber, you already have access to a monthly spend of Microsoft Azure. This will be more than enough to run this lab environment 24/7.
To build this lab, you’ll need to register a domain name. I’ve registered the domain name demo.4sysops.com for this lab, and I’m using the Domain Name Server (DNS) service for public name resolution to the lab environment in Microsoft Azure.
In the next eight articles in this series, we’ll build a BYOD test lab in Azure. In the tenth, and final, article of this series, I’ll explain how demoing the BYOD features (described above) might help you build a business case for (securely) embracing BYOD and to explain the technical underpinnings as clearly as possible.