In-Depth

Active Directory Retooled for the Changing Workplace

Windows Server 2016 Technical Preview 3 introduces major changes to Active Directory including LDAP v3 authentication via AD FS and sign-on support using biometrics, OpenIDConnect and OAuth.

• By Brien Posey
• 10/05/2015

Windows Server Active Directory first appeared 15 years ago with the launch of Windows 2000 Server. It had the ambitious aspiration at the time taking on Novell Directory Services, what was then the incumbent default enterprise network directory. While Active Directory didn't become pervasive overnight, Microsoft ultimately achieved critical mass by enhancing it in various ways over the years. It did so by always adhering to the same basic structure as when it first debuted so long ago.

Windows Server 2016 will likely end up introducing the most significant updates to date in the evolution of Active Directory. While it's true Active Directory is still backward-compatible with the directory services model enterprises use today, Microsoft is introducing a number of new or improved features and capabilities into Active Directory.

In order to understand the nature of these changes, it's important to realize things were much different when Microsoft introduced Active Directory. When Microsoft released Windows 2000 Server, the idea of operating in the cloud was unheard of. In fact, basic Internet connectivity was just first starting to take off. Consequently, Active Directory was designed to be an enterprise-level authentication and policy control mechanism, and that's really about it.

Today things aren't so simple. Organizations typically have resources in the local datacenter, in remote datacenters, in Software-as-a-Service (SaaS) clouds, and in Infrastructure-as-a-Service (IaaS) clouds. Active Directory was never designed to function in IT environments where resources are so widely decentralized.

This is where Windows Server 2016 Active Directory comes into play. Windows Server 2016 Active Directory can still do the same things it always does with domain controllers today, but it also introduces a variety of new or enhanced capabilities to help organizations cope with the decentralized nature of today's IT resources.

Active Directory Federation Services
One of the Active Directory components that has received a lot of attention over the last few years is Active Directory Federation Services (AD FS). AD FS is a Windows Server component that provides users with single sign-on access to IT resources that are located outside of traditional organizational boundaries. Today the most common use for AD FS is probably allowing Active Directory users to seamlessly access Microsoft Office 365.

As well as AD FS works, however, its primary limitation to date is that it's designed to work with Active Directory. Although most organizations have Active Directory in place, larger organizations may also have any number of non-Microsoft directories from the likes of IBM Corp., Oracle Corp. or even legacy Novell, among numerous others. In the past, there hasn't been a way to seamlessly connect users of these directories to Office 365 or other line-of-business (LOB) apps.

In Windows Server 2016, Microsoft is adding support for any LDAP v3 directory. This means users with accounts in non-Microsoft directories will be able to authenticate through AD FS and access Office 365 or other LOB apps, so long as the directory is LDAP v3 compliant.

To understand how this LDAP support works, it's important to understand how AD FS normally handles Office 365 connectivity. Users, when they log in, are authenticated by a DC. When the login is complete, the DC issues a Ticket Getting Ticket, which is stored in a cache on the user's desktop.

For example, if the user decides to access Microsoft Office 365, the login page redirects the browser to the Microsoft Federation Gateway. At this point, the user can enter his regular domain credentials. Upon doing so, the Microsoft Federation Gateway contacts the organization's AD FS server. The AD FS server acquires the user's Ticket Getting Ticket and presents it to the DC, which responds by issuing a service ticket. This service ticket is sent to the AD FS server and establishes the user's identity. With this service ticket in hand, the AD FS server can contact Active Directory and request a series of attributes for the user. One of the attributes returned in this exchange is the user principal name (UPN). AD FS then uses this information to create a token, which is passed through the user's Web browser, back to the Microsoft Federation Gateway. The gateway verifies the authenticity of the token and then creates its own token, which contains the user's UPN. This token is sent back to the user's Web browser and is then used to log the user into Office 365.

This process is sometimes referred to as claims-based authen­tication. A claim is really nothing more than the assertion of a piece of information such as a name or a UPN. A claim is issued by a claims provider and then encapsulated into a security token.

A claims provider also acts as an authentication mechanism. As such, Active Directory is treated as a local claims provider. The way Microsoft is enabling LDAP v3 support for AD FS is each LDAP directory will be treated as a claims provider. In other words, any LDAP directory will be able to authenticate user accounts and will communicate with the AD FS server in order to establish claims-based authentication.

The nice thing about this approach is that in some cases it eliminates the need for forest-level trusts. LDAP directories and Active Directory can communicate with the AD FS server without the need for any sort of trust relationship between one another. This same basic principle can also apply to organizations that have multiple Active Directory forests. Such organizations will be able to connect each Active Directory forest to AD FS without the need for directory-level trust. This might be especially useful in the case of corporate mergers or acquisitions.

Although AD FS has been discussed primarily with regard to its support for LDAP v3, Microsoft has introduced a significant number of new AD FS-related features in the most recent Windows Server 2016 Technical Preview. Although space limitations prevent explaining all of the new features in detail, some of the AD FS-related changes are geared toward developers, such as enhancements for building modern applications with OpenIDConnect and OAuth. Other features, however, are designed to simplify deployment, such as enhanced support for geo deployments using SQL with merge replication and support for certificate-based authentication (smart card authentication) over Port 443.

Microsoft Passport
Microsoft is also introducing a number of security enhancements for Active Directory. One of the most useful new security features is Microsoft Passport, which isn't to be mistaken for the Microsoft Passport the company offered several years ago.

The new Microsoft Passport is an authentication mechanism designed to overcome some of the problems with password-based authentication. Passwords are not only easily forgettable, they're not a true proof of identity, because anyone who knows a user's credentials can log in as that user.

Windows 10 seeks to decrease reliance on passwords by introducing PIN and biometric authentication capabilities (see the June 2015 cover story, "Hello, Windows 10"). PIN-based authentication requires a user to enter a four-digit numerical code rather than entering a password. Microsoft claims PIN-based authentication is more secure than password-based authentication because the PIN is device-specific and cannot be used remotely. Biometric authentication in Windows 10 can be based on a user's fingerprint, eyes, or face, but requires special hardware such as a fingerprint scanner or a facial recognition camera. The nice thing about biometrics (or PINs for that matter) is a password can't be stolen as it is typed in or transmitted across the network.

The problem with relying solely on biometric authentication is Active Directory was originally designed to support the use of passwords or smart cards -- not biometrics or PINs. This is where Microsoft Passport comes into play.

Most modern hardware is equipped with a TPM chip that allows cryptographic keys to be stored at the hardware level. During the login process, the user uses a PIN or biometrics to gain access to the device. Upon doing so, the device OS sends the authentication information to an identity provider (in this case, Active Directory). The device then creates a public key, which it signs and sends to the identity provider for registration. The identity provider registers the key and then requests the device sign in using its private key. If the sign on is valid then the identity provider issues an access token that allows access to protected resources.

Azure AD Join
While enterprise client PCs are commonly joined to an Active Directory domain, mobile devices cannot usually be domain-joined. This means such devices cannot be secured by Group Policies, nor can the device identity be stored in Active Directory.

Microsoft attempted to address this problem in the previous version of Windows with its Workplace Join feature (see the February 2015 article, "Manager Mobile Devices and Policies in Active Directory"). This feature still exists in Windows 10, but has been renamed to Work Access. Workplace Join didn't allow mobile devices to be joined to Active Directory in the traditional sense, but authorized users could enroll their devices in an Active Directory-based workplace in order to gain access to protected resources.

With Workplace Join, it was difficult to set up and it could only be used to control access to specific types of resources. In Windows Server 2016, Microsoft is introducing Azure AD Join. Azure AD Join is similar to the Workplace Join feature, but is designed to provide a better overall experience.

The Workplace Join feature was designed to provide access to protected resources for users working from personal devices. Azure AD Join can still do that, but it's also designed to work with corporate-owned, Active Directory-joined devices, as well as corporate devices that aren't Active Directory-joined (such as tablets and phones).

In the case of a corporate device such as a Windows PC joined to Active Directory, users are able to log in using their regular Active Directory credentials. Upon doing so, they'll be able to access the Windows Store without the need for a personal Microsoft account. A user can add a personal Microsoft account to the machine but doing so only enables single sign-on for work/personal resources. It doesn't cause the user's settings to be roamed.

In the case of corporate-owned devices that aren't domain-joined, users are able to log in using Azure AD credentials. Upon authenticating into Azure AD, the user is able to perform a self-service device setup and the setup process automatically registers the device in Azure AD and enrolls the device for mobile device management (assuming Azure AD Premium is being used). As was the case for a domain-joined device, there's no requirement for the user to associate a personal Microsoft account with the device.

Personal Microsoft accounts are primarily used with personal devices. A user can log in to a personal device using a personal Microsoft account and use the device in the same way as before. Users who want to access corporate resources are able to add either an Active Directory or an Azure AD account to the device, which will provide the user with SSO access to protected resources. It's also possible to use conditional access control to limit access to corporate resources based on the device. For example, an administrator might create a policy that requires mobile devices to be secured with a PIN and to use device-level encryption. Conditional access control is an Azure AD Premium feature.

Looking at Windows Server 2016 TP3, the next release of the server OS promises some very welcome improvements to Active Directory, especially with regard to security. These enhancements will allow for use of non-Microsoft LDAP directories, biometric authentication and conditional access control for mobile devices.