What’s New In Windows Server 2016 Standard Edition Part 2 - Identity

In the first post of this series I highlighted that with Windows Server 2016 there are some feature differences between the Standard and the Enterprise Editions that might get lost in some of the messaging, so in this series of posts I'm going to be highlighting the feature set of Windows Server 2016, and will include information from a few different resources, but the primary one is the Windows Server 2016 Technical Preview 5 Feature Comparison, along with some other useful links. As mentioned in the first post of the series, these will focus on what's new from a Windows Server 2012 R2 perspective, rather than Windows Server 2008 R2 or Windows Server 2012 perspective, I will focus on those later if needed.

Today's topic is identity, and following you will find the information from the Feature Comparison Guide, including some links to additional resources.

Please note that these are subject to change and are based on Windows Server 2016 Technical Preview 5. If any adjustments need to be made, please leave a comment.

Identity

Identity is the new control plane to secure access to on-premises and cloud resources. It centralizes your ability to control user and administrative privileges, both of which are very important when it comes to protecting your data and applications from malicious attack. At the same time, our users are more mobile than ever, and need access to computing resources from anywhere.

Active Directory Domain Services (AD DS)

Active Directory Domain Services (AD DS) stores directory data and manages communication between users and domains, including user logon processes, authentication, and directory searches. An Active Directory domain controller is a server that is running AD DS.

New Domain Services Capabilities

New in Windows Server 2016:
• Privileged Access Management. This capability, which allows organizations to provide time-limited access to administrator accounts, will be covered in more detail in a later post in this series.
• Azure Active Directory Join. There are enhanced identity experiences when devices are joined to Azure Active Directory. These include applying Modern settings to corporate-owned workstations, such as access to the Windows Store with corporate credentials, live tile and notification settings roaming, and backup/restore.
For more information, see Windows 10 for the enterprise: Ways to use devices for work.
• Microsoft Passport. Active Directory Domain Services now supports desktop login from Windows 10 domain joined devices with Microsoft Passport.  Microsoft Passport offers stronger authentication than password authentication with device specific and TPM protected credentials. For more information, see, Authenticating identities without passwords through Microsoft Passport.

Active Directory Federation Services (AD FS)

AD FS is a standards-based service that allows the secure sharing of identity information between trusted business partners (known as a federation) across an extranet. Active Directory Federation Services (AD FS) builds on the extensive AD FS capabilities available in the Windows Server 2012 R2 timeframe. Key enhancements to AD FS in Windows Server 2016, including better signon experiences, smoother upgrade and management processes, conditional access, and a wider array of strong authentication options, are described in the topics that follow.

Better 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.

AD FS extends hybrid identity by providing support for authentication based on any LDAP v3 compliant directory, not just Active Directory. 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 see Configure AD FS to authenticate users stored in LDAP directories

Improved Sign-On Experience

AD FS now allows for customization of the sign-on experience. This is especially applicable to organizations that host applications for a number of different customers or brands. 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.

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.

Strong Authentication Options

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 Multi-Factor Authentication (MFA) 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. 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.

Simpler Upgrade, Deployment, and Management

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. The migration can occur like this:
• 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.
• 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.

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).

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.

In AD FS for Windows Server 2016, it is 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.

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 Windows Server 2016 this has changed. You can now configure user certificate authentication on standard port 443.

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.

Developer Focus

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:  o Symmetric (shared secret / password).  o Asymmetric keys.
- Windows Integrated Authentication (WIA).

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

Registering modern applications has also 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, you can use the new Application Group wizard.

Web Application Proxy

The Web Application Proxy is a Windows Server service that allows for secure publishing of internal resources to users on the Internet.

Web Application Proxy

Web Application Proxy supports new features including pre-authentication support with AD FS for HTTP Basic applications such as Exchange Active Sync. Additionally, certificate authentication is now supported. The following new features build on the existing application publishing capabilities found in the Web Application Proxy in Windows Server 2012 R2:
• Pre-authentication for HTTP basic application publishing: HTTP Basic is the authorization protocol used by many protocols, including ActiveSync, to connect rich clients, including smartphones, with your Exchange mailbox. Web Application Proxy traditionally interacts with AD FS using redirections which is not supported on ActiveSync clients. This new version of Web Application Proxy provides support to publish an app using HTTP basic by enabling the HTTP app to receive a non-claims relying party trust for the application to the Federation Service. For more information on HTTP basic publishing, see Publishing Applications using AD FS Pre-authentication
• Wildcard Domain publishing of applications: To support scenarios such as SharePoint 2013, the external URL for the application can now include a wildcard to enable you to publish multiple applications from within a specific domain, for example, https://*.sp-apps.contoso.com. This will simplify publishing of SharePoint apps.
• HTTP to HTTPS redirection: In order to make sure your users can access your app, even if they neglect to type HTTPS in the URL, Web Application Proxy now supports HTTP to HTTPS redirection.
• Publishing of Remote Desktop Gateway Apps: For more information on RDG in Web Application Proxy, see Publishing Applications with SharePoint, Exchange and RDG
• New debug log: for better troubleshooting and improved service log for complete audit trail and improved error handling. For more information on troubleshooting, see Troubleshooting Web Application Proxy
• Administration Console UI improvements
• Propagation of client IP address to backend applications

Comments

• Anonymous
  September 04, 2016
  Hi Mark, Excellent Article.Thanks for keeping us update.