What's new in Active Directory Federation Services for Windows Server 2016 Technical Preview

 

What's new in Active Directory Federation Services for Windows Server 2016 Preview

If you are looking for information on earlier versions of AD FS, see the following articles: ADFS in Windows Server 2012 or 2012 R2 and AD FS 2.0

Introduction

Active Directory Federation Services is an extension to Active Directory that provides sign on with common credentials across a wide variety of applications including Office 365, cloud based SaaS applications, and applications on the corporate network.

• For the IT organization, we enable you to provide authentication and access control to both modern and legacy applications, on premises and in the cloud, based on the same set of credentials and policies, ensuring that you are only allowing access to users, devices and network locations that meet your corporate policies.

• For the user, we provide a seamless sign on using the same, familiar account credentials.

• For the developer, we provide an easy way to authenticate users whose identities live in the organizational directory so that you can focus your effort on the application, not authentication or identity.

This article takes you through what is new in the AD FS in Windows Server 2016 Preview.

AD FS in Windows Server 2016

With the new version of AD FS, we’re providing you with more options for allowing easier sign on for a diverse set of users and devices, while keeping control over who has access to what and from which device.

Our improvements are organized around the following themes.

• Better way to sign on to Azure AD and Office 365

• Better sign on experiences

• More options for strong authentication

• Easier deployment and management

• Conditional access

• Seamless sign on from Windows 10 and Microsoft Passport

• Better for developers

Better way to sign on to Azure AD and Office 365

One of the most common usage scenarios for AD FS continues to be providing sign on to Office 365 and other Azure AD based applications using your on premises Active Directory credentials.

Based on your feedback, we’ve extended hybrid identity by providing support for authentication based on any LDAP v3 compliant directory, not just AD.

This allows you to enable sign in to AD FS resources from:

• Any LDAP v3 compliant directory including AD LDS and third party directories

• Un-trusted or partially trusted Active Directory domains and forests

Support for LDAP v3 directories is done by modeling each LDAP directory as a 'local' claims provider trust. This enables the following admin capabilities

• Restrict the scope of the directory based on OU.

• Map individual attributes to AD FS claims, including login ID.

• Map login suffixes to individual LDAP directories

• Augment claims for users after authentication by modifying claim rules

For more seeConfigure AD FS to authenticate users stored in LDAP directories

Better sign on experiences

Customize sign in experience for AD FS applications

We heard from you that the ability to customize the logon experience for each application would be a great usability improvement, especially for organizations who provide sign on for applications that represent multiple different companies or brands.

Previously, AD FS in Windows Server 2012 R2 provided a common sign on experience for all relying party applications, with the ability to customize a subset of text based content per application. With Windows Server 2016, you can customize not only the messages, but images, logo and web theme per application. Additionally, you can create new, custom web themes and apply these per relying party.

For more see Customizing user signin for AD FS relying parties

Seamless sign on from Windows 10

Users on Windows 10 devices and computers will be able to access applications without having to provide additional credentials, just based on their desktop login, even over the extranet.

More options for strong authentication

Enable New Factors of Authentication and Eliminate Passwords

AD FS in Windows Server 2016 provides more ways to authenticate different types of identities and devices. In addition to the traditional Active Directory based logon options (and new LDAP directory support), you can now configure device authentication or Azure MFA as either primary or secondary authentication methods.

Using either the device or Azure MFA authentication methods, you can create a way for managed, compliant, or domain joined devices to authenticate without the need to supply a password, even from the extranet.

Note

In addition, we are introducing a built-in Azure MFA based authentication. In the current preview (November 2015), this can only be enabled as part of a special opt-in program, so that we can setup your tenant to support this.

Stronger sign on from Windows 10

In addition to seamless single sign on based on desktop login, Windows 10 users can sign on to AD FS applications based on Microsoft Passport credentials, for a more secure and seamless way of authenticating both users and devices.

Easier deployment and management

Moving from AD FS in Windows Server 2012 R2 to AD FS in Windows Server 2016 is easier

Previously, migrating to a new version of AD FS required exporting configuration from the old farm and importing to a brand new, parallel farm.

Now, moving from AD FS on Windows Server 2012 R2 to AD FS on Windows Server 2016 has gotten much easier. Simply add a new Windows Server 2016 server to a Windows Server 2012 R2 farm, and the farm will act at the Windows Server 2012 R2 farm behavior level, so it looks and behaves just like a Windows Server 2012 R2 farm.

Then, add new Windows Server 2016 servers to the farm, verify the functionality and remove the older servers from the load balancer. Once all farm nodes are running Windows Server 2016, you are ready to upgrade the farm behavior level to 2016 and begin using the new features.

For more see Walkthrough: Upgrading to AD FS in Windows Server 2016

Application Policies

Previously custom AD FS policies have been configured in claim rules language, making it difficult to implement and maintain more complex policies. Now, AD FS in Windows Server 2016, policies are easier to configure with wizard based management that allows you to avoid writing claim rules even for conditional access policies:

The new access control policy templates enable the following new scenarios and benefits:

• Templates to simplify applying similar policies across multiple applications

• Parameterized policies to support assigning different values for access control (e.g. Security Group)

• Simpler UI with additional support for many new conditions

• Conditional Predicates (Security groups, networks, device trust level, require mfa)

For more see Access Control Policies in AD FS

Delegated Service Management

AD FS for Windows Server 2016 introduces the ability to have separation between server administrators and AD FS service administrators. This means that there is no longer a requirement for the AD FS administrator to be a local server administrator. Instead, you can designate a standard security group.

Audit Enhancements

In AD FS for Windows Server 2016, its much easier to consume and manage audit data. The number of audits has been reduced from an average of 80 per logon to 3, and the new audits have been schematized. These enhancements are enabled by default in new AD FS for Windows Server 2016 farms.

For more see Auditing Enhancements to AD FS in Windows Server 2016

User certificate authentication over port 443

In AD FS on Windows Server 2012 R2, certificate authentication could not be done over port 443. This is because you could not have different bindings for device authentication and user certificate authentication on the same host.

In AD FS in Windows Server 2016 this has changed. You can now configure user certificate authentication on standard port 443. This can be done at the time of the farm creation of later via PowerShell.

For more see AD FS support for alternate hostname binding for certificate authentication

Conditional access

AD FS in Windows Server 2016 builds on our previous device registration capabilities by enabling new scenarios, working with Azure AD, to require compliant devices and either restrict or require multiple factors of authentication, based on management or compliance status.

Azure AD and Intune based conditional access policies enable scenarios and benefits such as:

• Enable Access only from devices that are managed and/or compliant

• Restrict access to corporate ‘joined’ PC’s (including managed devices and domain joined PC’s)

• Require multi factor authentication for computers that are not domain joined and devices that are not compliant

AD FS in Windows Server 2016 can consume the computer or device compliance status, so that you can apply the same policies to your on premises resources as you do for the cloud.

Compliance is re-evaluated when device attributes change, so that you can always ensure policies are being enforced.

Seamless sign on from Windows 10 and Microsoft Passport

Domain Join in Windows 10 has been enhanced to provide integration with Azure AD, as well as stronger and more seamless Microsoft Passport based authentication. This provides the following benefits after being connected to Azure AD:

• SSO (single-sign-on) to Azure AD resources from anywhere.

• Strong authentication and convenient sign-in with Microsoft Passport and Windows Hello.

AD FS in Windows Server 2016 provides the ability to extend the above benefits and device policies to on premises resources protected by AD FS.

For more see Windows 10 Sign on – enabling device authentication with AD FS

Better for developers

Enable new protocols for modern authentication

AD FS for Windows Server 2016 builds upon the Oauth protocol support that was introduced in Windows Server 2012 R2, to enable the most current and industry standard based authentication flows among web apps, web APIs, browser and native client based apps.

Windows Server 2012 R2 offered support for the Oauth authorization grant flow and authorization code grant type, for public clients only.

In Windows Server 2016, the following additional protocols and features are supported:

• OpenId Connect support

• Additional Oauth authorization code grant types

  • Implicit flow (for single page applications)

  • Resource Owner password (for scripting apps)

• Oauth confidential clients (clients capable of maintaining their own secret, such as app or service running on web server)

• Oauth confidential client authentication methods

  • Symmetric ( shared secret / password)

  • Asymmetric keys

  • Windows Integrated Authentication (WIA)

• • Support for “on behalf of” flows as an extension to basic Oauth support.

For more see Enabling Oauth Confidential Clients with AD FS 2016 and Enabling OpenId Connect with AD FS 2016

Configure application groups for modern authentication

Registering modern applications has become simpler using AD FS in Windows Server 2016. Now instead of using PowerShell to create a client object, modeling the web api as an RP, and creating all of the authorization rules, we can use the new Application Group wizard.

You can create an initial application group based on any of the in-built templates, for example “Server application and Web API”. Then, add additional clients or servers depending on the scenario you need.