Improvements in Active Directory Federation Services Windows Server 2016

One way this can be achieved is by using the new Azure Multi Factor Authentication (MFA) adapter for AD FS. In the past, you needed to have an MFA server on premises (which is still supported), but now it’s simply a matter of configuring the adapter in AD FS. Once it is configured, users use the mobile app to sign in. You can configure it to use just a username and a One-Time Password (OTP) in the authenticator app or use the app as a secondary means of authentication alongside either username/password, smartcard, or user/device certificate. The authenticator app is available for all mobile platforms.

The second option is using Windows Hello for Business. This approach uses modern biometric hardware and has been available for consumers since the release of Surface Pro 4/Surface Book. (I use my face to login to the PC on which I’m writing this article all the time—it works great.) Today, if you want to use it with your business AD/AD FS infrastructure, you need to have Azure AD as well. Support for on-premises-only organizations is coming soon.

AD FS now fully supports the OAuth standard, as well as OpenID Connect. As a matter of fact, AD FS in Windows Server 2016 has been certified by OpenID.

While enhancements in standards support are mostly of interest to developers rather than IT Pros, one good improvement is application groups. Today many applications and services are decomposed into smaller parts, several of which may need authentication services. By using an application group, you can tie these entities together into one logical construct rather than having to create individual, dependent party trusts for each part.

Another big improvement is SAML 2.0 interoperability, which allows you to import groups of trusts. In Technical Preview 5, if there was a non-compliant part in a metadata document, an import would fail with an error. In the RTM version, it will continue the import and simply skip the non-compliant part.

Earlier versions of AD FS were a consultant’s dream. Each phase of policy processing—authentication, authorization and claims issuing—had to be configured independently using the claims rule language. The 2016 version now offers Access Control Policy Templates as an alternative. The old model is still there, but you can’t mix them; it’s one or the other.

You can either use the built-in templates that cover the most common scenarios or create custom templates. If you modify a custom template later, the changes will automatically apply to all parts based on that template. Templates can also be parameterized, which means you have to specify values when using the template. For instance, the template Permit specific group requires you to define to which group it applies each time you use it.

You can also use IP address ranges in claims rules without having to resort to regular expressions to define the scope.

Administrative role separation is also improved, as a specific group can be assigned as AD FS service administrators, and the built-in server administrators group isn’t automatically composed of AD FS administrators. You also don’t need to be a domain administrator to deploy AD FS, as long the DKM container for the keys and the permissions for the AD FS service account have been created.

Most production deployments use multiple AD FS servers in a farm. However, a single server deployment is often preferred, especially in smaller environments. For backup of the complete configuration for a single server or for lab scenarios in which you need a copy of a production setup, the free AD FS Rapid Restore Tool can be used with AD FS in Windows Server 2012, 2012 R2, and 2016.

It turns out that many service providers use AD FS to provide authentication as a service and need to customize login pages for individual applications, something that’s now possible.

Audit logging in previous AD FS incarnations is notoriously chatty, with multiple entries for a single request. This has led to most environments turning off auditing altogether. The new version is less chatty and more streamlined. A basic auditing level is enabled by default, and each request will generate a maximum of five events (less in my testing) with relevant information in the logs.

Also new in 2016 is the ability to authenticate users stored in any LDAP v3 compliant directory, including domains in untrusted forests and SQL Server. Each connection is stored in a local claims provider trust. Be aware that only forms-based authentication is available for LDAP-stored users; certificate-based and integrated Windows authentication is not available.

Also new is the ability to send password expiration claims to applications so that Office 365 applications can notify the user when their passwords are about to expire.

Previous versions weren’t exactly upgrade friendly. They required the building of a parallel infrastructure and exporting and importing configurations. Taking a leaf out of Hyper-V and clustering rolling upgrades in Windows Server 2016, AD FS introduces the Farm Behavior Level (FBL) feature. This means you can add 2016 nodes to an existing Windows Server 2012 R2 AD FS farm and they will work as normal 2012 R2 nodes. 

Once you have replaced all nodes in the farm with 2016-based nodes, you can raise the FBL to unlock the new features in 2016. Be aware that you won’t be able to test the new features until you unlock the features. So, if you need to perform a proof-of-concept test, you’ll have to set up a separate lab environment for that.

There are a lot of welcome improvements in this version of AD FS, especially for extranet access scenarios. A lot of them are based on user feedback, which seems to be the overall theme for Windows Server 2016. The smooth upgrade path should also entice administrators. AD FS has grown up considerably over the last few versions. If the last time you saw it was back in the 2008 timeframe, it’s time to take another look; it’s a lot easier to deploy and use.