After almost 14 years on the market, Active Directory Domain Services (AD DS) continues its dominant role as the primary identity building block in most enterprises. In Windows Server 2012 R2, enhancements to AD DS and its newer sibling Active Directory Federation Services (AD FS) are more notable for how they enable new features and scenarios in other products, rather than in AD alone. In this first of two articles detailing the identity and access management-related changes to Windows Server 2012 R2, I'm going to focus on R2's BYOD scenario, Workplace Join, and the roles AD DS, AD FS, and a brand new identity component play in making it happen.

Connect to applications and services from anywhere with Web Application Proxy

The biggest new identity-related capability in Windows Server 2012 R2 is the ability to provide secure access to certain types of corporate resources from mobile devices (such as an iPhone or iPad) with sophisticated authentication and access control. This scenario is known officially as "Connect to applications and services from anywhere with Web Application Proxy"; it currently supports IOS only, but Android support is supposed to be available soon. Authorized devices can have single sign-on to a variety of applications, plus additional capabilities of multi-factor authentication and conditional authorization in ways that aren't possible with AD DS alone.

Figure 1: Connecting to applications via Web Application Proxy

Figure 1 shows the architectural overview of this scenario. Mobile devices reach corporate resources through a new interface, the Web Application Proxy (WAP). Administrators can publish applications that are browser-based, or support claims, or use RESTful APIs through the WAP portal. The WAP is connected to AD FS, which handles both authentication and authorization of these devices to the published applications. (Microsoft calls these applications AD FS-secured resources.)

Making this scenario work required some minor updates to AD DS, some major updates to AD FS, and the creation of a whole new role feature. It requires the AD DS schema to be at Windows Server 2012 R2 in order to handle the additional device-related attributes, but no domain controller (and therefore no forest or domain functional level) upgrade is required. It does, however, require Windows Server 2012 R2 AD FS, and the Web Application Proxy (below).

Let's step through these three identity related enhancements one at a time.

Workplace join

You don't want to join just any old device to your work environment; you only want to connect devices of authenticated employees. But how do you prove that a given device truly belongs to an employee? To get this accomplished, Microsoft created a ceremony called Workplace Join, where a user's mobile device(s) become associated with their Active Directory user object. I've best heard Workplace Join described as a lightweight domain join – it has some, but not all, of the characteristics of a traditional full domain join. When a device is successfully joined to the workplace (note the differentiation "workplace" and "domain") via the Device Registration Service, it has a certificate installed on it to maintain the workplace user association and thus becomes a known device. From this point, AD FS manages resource access through global authentication policies, multi-factor authentication if desired, and multi-factor access control.

For more information on Workplace Join, read the overview or the walkthrough guide.

Multi-factor authentication

Multi-factor authentication (MFA) is an AD FS enhancement that allows you to require one or more authentication methods on a workplace-joined device, in addition to built-in methods (for example Integrated Windows Authentication) to access an ADFS-secured web resource. You'd use this feature if you had a sensitive application (for example, an HR database) that required higher security. You have a choice of either certificate authentication or Windows Azure multi-factor authentication. Using the Azure MFA option (a subscription fee applies) turns this feature into a true hybrid service, communicating between on-premises and Azure and providing text or voice calls to a mobile device, or a one-time password app on that device. It also has the advantage of getting new MFA enhancements when they're released to web.

This hybrid option requires an on-premises MFA Server (downloadable from the MFA Management section of your Azure portal) to handle the communication to the Azure MFA provider you create in your subscription. Your Azure MFA provider then connects to Azure's MFA Service. You can also link your Azure MFA provider to your Azure Active Directory tenant if you want to use MFA for an Azure service (e.g. Office 365). In a nice security touch, Microsoft has made MFA free for global administrators of your Azure AD tenant.

For more information on multi-factor authentication, watch an overview video, read the overview or the walkthrough guide.

Multi-factor access control

Multi-factor access control (MFAC for simplicity) is an AD FS enhancement that allows you to choose from a wide range of conditions under which a user can access an AD FS-secured corporate resource - not just a user's group membership. This is a very powerful and flexible means of determining access to a resource. With this feature, Microsoft has expanded the how you can use claims in the enterprise (See my previous article on how claims can be used in Windows Server 2012 to control file server access). By using claims instead of only security groups, you can control resource access based on a wide range of conditions such as user name, authentication time stamp, network location, or even the number of days before the user's password expires; there are 62 claim types to choose from. A few of these claim types are shown in green in Figure 1.

I wish this feature was named "conditional access control" or "context-sensitive access control", both to avoid confusion with MFA and to more accurately describe it. Though MFAC does control access based on multiple factors (62 of them if you want), "multi-factor" is widely associated with a strong authentication method such as a smart card or a PIN sent to a cell phone. MFAC's capabilities are broader, and MFAC is an example of a new breed of security system – one that takes into account many more environment variables than "what you know" and "what you have". I believe these new, fine-grained access control models will be as important as strong authentication is today.

Advanced conditional access control models demonstrate, for example, a solution to the annoying problem of a web session timing out because you're inactive in it. You're still active at your computer (with recognizable keyboard and mouse patterns that indicate it's still you in the chair), you're just using other Windows. Why shouldn't the access control model know this and extend your session time?

For more information on multi-factor access control, read the overview or the walkthrough guide.

Web Application Proxy

All these new capabilities require a much beefier proxy server than in previous OS versions, and so Web Application Proxy has been introduced for Windows Server 2012 R2. You won't find this feature as part of the AD FS role; it's now a feature within the Remote Access role. An important function of Web Application Proxy is that it allows administrators to publish applications for external access, while controlling authentication and authorization policies (via AD FS). This service also acts as a reverse proxy. A Windows Server 2012 R2 server with the Web Application Proxy feature installed is a required component of this "connect to applications from anywhere" scenario.

For more information on Web Application Proxy, check out the TechNet overview. You can also watch Uday Hegde's TechEd 2013 presentation and demo of this scenario end-to-end.

I want to bring up an important point in case you've missed it: None of the applications in Figure 1 are SMB-based applications. This scenario doesn't support access to your \\server\share file servers; it only supports web-based applications and services – even inside your own data center. These identity and access enhancements are handled through AD FS, AD DS's modern authentication head. It's AD FS's support of claims, and the flexibility that the claims model provides, that makes this scenario possible. (For an excellent background on claims, I suggest you take some time to read through the Guide to Claims-Based Identity and Access Control, Second Edition.) Do I expect SMB support in a future release? I do not, unless it uses claims to control access. The computing world is moving towards web services with claims and RESTful interfaces. And these applications and services are far more cloud-portable than their predecessors.

Related: What's new in Active Directory for Windows Server 2012, Part 2: New Features in AD DS, AD FS, AD CS, and other stuff

Follow Sean on Twitter at @shorinsean.