Active Directory IT controls to manage risk when users access company resources from a wide variety of devices

[TechCommunityAPIAdmin]

First published on CloudBlogs on Jul, 25 2013 by the Microsoft Azure Active Directory Team

Hi,

I’m Samuel Devasahayam (you can call me ‘Sam’) and I am a lead program manager in the Active Directory team responsible for Active Directory Federation Service (AD FS)

In prior posts, you read how Active Directory in Windows Server 2012 R2 (the preview build is available here ) extends the device support in Active Directory and enables users to access Web resources through the new Web Application Proxy (we'll blog more about this soon). As you can see from these posts, our focus has been to give end users the ability to use their devices to work from anywhere, while giving IT professionals the tools and technologies they need to effectively govern access to their company resources.

With the new version of Active Directory Federation Services (AD FS) in Windows Server 2012 R2 (WS2012R2), we’ve added a number of capabilities to provide more IT controls to satisfy their risk management needs. For those of you who may not be familiar with AD FS, you can think of this as an authentication head on top of Active Directory Domain Services (ADDS) and extends the reach of AD users to resources that are on-premises, in the cloud or partner organizations. AD FS is a standard role that is available in Windows Server.

Let’s dive into these new capabilities.

Flexible Authentication with Multi-Factor Authentication (MFA)

An important part of managing risk is managing how the user authenticates to a specific resource. This is when the user “logs in” and provides a credential (say username/password) to access an application. Different applications may require different forms of credentials (that vary in strength) based on the sensitivity of the resource and the context with which the user accesses this application (for example their location).

We have heard a lot of feedback on the need for administrators being able to differentiate policies for sensitive applications and require MFA based on location or based on user characteristics. For example, “ require MFA for application X when users are accessing from the extranet ” OR “ require MFA for all application admins for application Y ”.

The new version of AD FS in WS2012R2 conceptualizes authentication as a two-stage process, the primary authentication stage and an additional authentication stage.

Primary Authentication:

This is the first stage of authentication that governs all applications. This is where the user’s primary credential (e.g. username and password) is collected and authenticated. This stage requires authentication from Active Directory Domain Services (AD DS). Most admins need to differentiate and govern authentication based on whether the user is inside the firewall or outside the firewall (intranet vs. extranet). We’ve given some simple controls for the admin to control this and it is as simple as clicking a check-box in the AD FS management console. In addition, the admin also has the choice to enable device authentication to augment the user credential with certificates provisioned by the Device Registration Service (DRS) to Workplace Joined devices.

Triggering Additional Authentication:

This is the policy that governs whether the additional stage of authentication should be triggered. This is done only after the primary authentication has successfully completed. This way we have data about the user, device as well as location to write this policy on a per application basis. As a result, this provides a lot of flexibility for admins to demand additional authentication based on their business requirements. For example an admin could author policies like “Only trigger additional authentication if…”

• “…users are accessing resources from the extranet”
• “…the user is part of the ‘application administrators’ security group”
• “…the user is accessing from a non-Workplace Joined device and accessing resources from the extranet”

Extensible Additional Authentication:

The obvious question that comes up is “what happens after triggering additional authentication”? AD FS out of the box supports X509 certificate (think smartcard or other CSP based schemes that use client TLS) authentication as an additional (or secondary) authentication provider. Besides X.509 authentication, we see a lot of customers using a wide range of other multi-factor authentication (MFA) mechanisms. These range across hard/soft One Time Password (OTP) tokens, phone (voice, SMS), email as well as security Q&A. With the prior version of AD FS, it was difficult to natively integrate any 3 ^rd party MFA providers into AD FS. With the new version of AD FS in WS2012R2, we have  added a framework with which any 3 ^rd party MFA vendor can write a provider that integrates directly with AD FS. This was done with a view to:

1. Ensure AD FS has knowledge about the additional authentication,
2. Provide a consistent sign-in experience for the end user, and
3. Provide MFA providers with the ability to control the input and validation process when collecting additional credentials (e.g. OTP or Q&A) from the user with support for a multi-leg challenge-response sequence.

In the recently concluded TechEd conference we showcased ( session link ) integration with Microsoft’s own PhoneFactor service (code named Active Authentication) as well as SafeNet’s authentication service with OTP and GridSure (SafeNet blog link) .

Multi-Factor Access Control

Authorization is a key aspect of granting access to resources and can be dictated by organizational, departmental or application polices. AD FS in Windows Server provides admins the capability to author authorization policies that governs “Who gets to access this specific application” (essentially this is who gets the security token for the application). These are called “Issuance Authorization Rules” that is attached to every application (a.k.a. relying party rust). In prior versions of AD FS, you were restricted to making decisions based on user or authentication data.While still useful, it was not feasible to author polices based on location (for example based on whether the user is coming from the extranet) or based on devices

With the new version of AD FS in WS2012 R2 embracing devices (personal or corporate owned), we’ve added more types of data for the admin to make these decisions. With Workplace Join, we now have data on whether the request is originating from a device that is known to AD. Admins can now use this to gate access to applications and hence limit access from any unknown device. Similarly, knowledge about how the user was authenticated (e.g. whether MFA was performed in the second stage as described earlier) can also be used to make an authorization decision. We’ve also heard a lot of feedback about admins needing to gate access based on location. To facilitate this, we supply information about the location (a simple Boolean for extranet detection as well as the IP address of the client) to use when writing authorization rules. Examples of such rules are:

• “Allow only Workplace Joined devices when connecting from the extranet to the payroll-application”
• “Allow only users belonging to the ‘finance’ security group when connecting from the extranet to the finance-application”

Additional Risk Mitigations

Governing how users log in to an application or how users are authorized to gain access to an applications aren’t the only areas that we focused to provide the right set of IT controls to mitigate risk associated with access to resources. Some additional capabilities that we’ve added in Windows Server 2012 R2 are:

• Soft Account Lockout for Extranet Access: This allows you to set a password lockout policy for access that occurs from the extranet and if the threshold of bad passwords is exceeded, the user will be locked out for a time period ('observation window') specified by the policy. This is independent of the ADDS password lockout mechanisms and can be layered on top of it.
• Per Application Force Re-authentication: This is the ability for admins to require users to provide a fresh set of credentials every time they access the application. Typically, one would use this for sensitive applications where the user is always asked to provide a fresh set of credentials (no Single Sign-On) and even combine this with MFA
• Global SSO revocation: This is the ability for admins to revoke all prior SSO state for all end users and require fresh credentials when accessing any application.
• Access Protection from lost devices: To revoke any access to corporate resources from a device that is lost or stolen, we’ve also provide the ability for admins to simply disable/delete the registered device (the User@Device object in AD) and as a result all access from this device is revoked or the end user is required to provide new set of credentials or workplace join their device to regain access to corporate resources. In addition, audit failure events will be logged that contain the device certificate information and the IP address for admins to track.

Summary

We hope that the above set of capabilities continues to push the envelope to help IT manage risk when resources are being accessed from a wide variety of resources.

Please let us know (comment on this post) if you have any feedback, suggestions and things that you would like to see in future versions of Active Directory.

You can find more information at our TechNet site here . You can also read about People-centric IT ( link ) that brings together a solution across Windows, Windows Server, Systems Center and Windows Intune to enable BYOD scenarios in an organization.

Thanks, Sam