First published on CloudBlogs on Jul, 25 2013 by the Microsoft Azure Active Directory Team
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.
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.
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.
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…”
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:
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) .
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:
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:
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.