In this article, we will setup the new AD FS 4.0 in Windows Server 2016 to publish external resources with the new Web Application Proxy feature. For this scenario, we will use IIS and SharePoint Server relying party and we will go through new features introduced in AD FS 4.0. This new version bring a lot of changes and features in regard of previous AD FS version.

This article will be in three parts : 

For a review of the new features included in AD FS 4.0 (vNext, Server 2016 TP) see :


Part 1 - AD FS 4.0 Discover & Setup

Lab Scenario

We want to test and understand new capabilities in AD FS 4.0 including :


  • Authentication Methods 
  • Access Control Policies
  • Applications Groups with Scope Descriptions
  • AD FS Service Delegation
  • Per Relying Party Theming


  • HTTP to HTTPS redirection
  • HTTP Publishing
  • Propagation of client IP address to back-end applications X-Forwarded-IP option
  • SharePoint Apps - Wildcard Domain publication

1. Install AD FS 4.0 Server

  • Install Windows Server 2016: (See Requirement)
  • Join to domain environment
  • Setup DNS to Public and Internal name resolution : "ADFS2016.CONTOSO.COM"

Certificate for Service Communication

There is no major change with certificate in AD FS 4.0 : SSL Communication, Token Signin and Token Decryption
For the Service Communication certificate, you will need to setup a SSL certificate with the following name :

  • DNS --> Used for the Service Communication
  • (NEW) DNS --> (Alternate) Used for Certificate Authentication on 443 (client)
  • DNS --> Used for Device Registration

Note : The certauth subdomain certificate allow you to have only the 443 port used under a different hostname rather than using the same hostname with the 49443 port. You can use the new PowerShell CMDlet : Set-AdfsAlternateTLSClientBinding. See this KB for additional information about this change.

  1. You can use both public or private certification authority. For this lab we used an Internal CA, issuing Web Server Template certificates with a default common name and additional DNS Name (Subject Alternative Name).
  2. Don't forget to plan certificates for published applications, you can use individual certificate or wildcard certificate. Wildcard certificate will be necessary for publishing wildcard domain through the WebApplicationProxy.

Install AD FS 4.0 role using Powershell (New ADFS Farm)

These steps are quite similar to AD FS in Windows Server 2012R2:

Install ADFS Role in a CMD.exe run as administrator :

Install-windowsfeature adfs-federation -IncludeManagementTools

Uninstall-windowsfeature adfs-federation -IncludeManagementTools

Install SSL Certificate :

  • Import to the local computer store with Private Key

Install ADFS Farm :

# Windows PowerShell script for AD FS Deployment

Import-Module ADFS
$credentials = Get-Credential
Install-AdfsFarm `
-CertificateThumbprint:"A909502DD82AE41433E6F83886B00D4277A32A7B" `
-FederationServiceDisplayName:"Contoso Corporation" `
-FederationServiceName:"" `

  • Using SQL Server for ADFSConfiguration Database
# Windows PowerShell script for AD FS Deployment
Import-Module ADFS
$credentials = Get-Credential
Install-AdfsFarm `
-CertificateThumbprint:"A909502DD82AE41433E6F83886B00D4277A32A7B" `
-FederationServiceDisplayName:"Contoso Corporation" `
-FederationServiceName:"" `
-GroupServiceAccountIdentifier:"CONTOSO\ADFS2016gMSA`$" `
-SQLConnectionString:"Data Source=SQLSRV\INSTANCE;Initial Catalog=ADFSConfiguration;Integrated Security=True;Min Pool Size=20"
  • After the completion you can use the Test-AdfsFarmInstallation cmdlet. You will be prompted for credential (domain user)

Test-AdfsFarmInstallation -FederationServiceName "ADFS2016.CONTOSO.COM"

2. Install WAP Server

  • Install Windows Server 2016
  • Join to Workgroup environment in a perimeter network
  • Plan communication between the WAP and the ADFS Server (443)
  • Setup host file for internal name resolution for ADFS and for published applications
    • 192.168.0.X

Install WebApplication Proxy 4.0 using Powershell

Install-WindowsFeature Web-Application-Proxy -IncludeManagementTools

Uninstall-WindowsFeature Web-Application-Proxy -IncludeManagementTools

Join WebApplication Proxy to an existing AD FS farm

Install-WebApplicationProxy `
-CertificateThumbprint 'BB01197C7EF3D88C326091BF528FCC1F5C5F794F' `
-FederationServiceName ''

3. AD FS General Settings - View and Configure

Enable the IDPInitiatedSignonPage

Now with AD FS 4.0 the page is disabled by default.
The logon page will be available only with the use of a Relying Party or with an Application Group.

  • You can enable again this idpinitiatedsignonpage easily :
Set-AdfsProperties -EnableIdPInitiatedSignonPage:$true

  • Also, you can enable RelayState for creating direct logon URL for target Relying Party :

Set-AdfsProperties -EnableRelayStateForIdpInitiatedSignOn:$true

AD FS Service Delegation :

This is a new feature introduced with AD FS 4.0. You can now delegate permission for administering the AD FS Configuration

Default Settings

DelegateServiceAdministration … (AD Groups)
AllowSystemServiceAdministration FALSE
AllowLocalAdminsServiceAdministration TRUE

If you want to delegate the AD FS Management run :

Set-AdfsProperties -DelegateServiceAdministration "CONTOSO\ADFS_Delegated_Admins"

You can check if the policy is correctly applied, by running :

runas /noprofile /user:contoso\adfs_admin "mmc %windir%\ADFS\Microsoft.IdentityServer.msc"

If the user is not present in the ADFS_Delegated_Admins group, he will receive : ADMIN0120: The client is not authorized to access the endpoint

Tokens and SSO Lifetime :

No majors change for this part:
Default Settings:

ADFS Property Name
Default Value
PreventTokenReplays TRUE FALSE if using WID
ProxyTrustTokenLifetime 21600
ReplayCacheExpirationInterval 60
SignedSamlRequestsRequired FALSE
SamlMessageDeliveryWindow 5
SignSamlAuthnRequests FALSE
SsoLifetime 480
PersistentSsoLifetimeMins 60480
KmsiLifetimeMins 1440
PersistentSsoEnabled TRUE
PersistentSsoCutoffTime 01-01-01 01:00
KmsiEnabled FALSE
LoopDetectionEnabled TRUE
LoopDetectionTimeIntervalInSeconds 20
LoopDetectionMaximumTokensIssuedInInterval 5
PasswordValidationDelayInMinutes 60

BrowserSSO and UserAgents:

  • For the WIASupportedUserAgents, we can see a new default one : MS_WorkFoldersClients
    • The WorkFolders settings was a issue with 2012R2 : See this KB
  • For a complete list of actual UserAgents in AD FS, See this KB

WIASupportedUserAgents MSAuthHost/1.0/In-Domain, MSIE 6.0, MSIE 7.0, MSIE 8.0, MSIE 9.0, MSIE 10.0, Trident/7.0, MSIPC, Windows Rights Management Client, MS_WorkFoldersClient
BrowserSsoEnabled True
BrowserSsoSupportedUserAgents Windows NT 1, Windows Phone 1

Two new settings : BrowserSsoEnabled and BrowserSsoSupportedUserAgents. They work together.
When the BrowserSsoEnabled settings is set to true (by default) the browser will try to perform the authentication by itself on the BrowserSsoSupportedUserAgents.

  • Windows NT 1 refers to Windows 10 (and Server 2016)
  • Windows Phone 1 refers to Windows 10 Mobile

When this settings is active, end-users will see this screen when logging to a Relying Party or in the IdpInitiatedSignon page (if you have enabled it)
This behavior will be present on a Windows 10 computer and not for Windows 7.

Note : at this stade, there is no enough information to provide explication on what it's supposed to do. I guess this is for Device Certificate Authentication. 
As this BrowserSSO attempt take several second more than the "automatic logon with logged-on credential". You can disable this feature if you don't use it.

Authentication methods

  • Default authentication methods in AD FS 4.0 (default are in blue)
  • Added three new built-in method : Device, AzurePrimary and AzureMfa (in green)
Name AllowedForPrimaryExtranet AllowedForPrimaryIntranet AllowedForAdditionalAuth
FormsAuthentication TRUE TRUE FALSE
WindowsAuthentication FALSE TRUE FALSE
CertificateAuthentication TRUE TRUE TRUE
DeviceAuthentication TRUE TRUE FALSE
AzurePrimaryAuthentication TRUE TRUE FALSE
AzureMfaAuthentication FALSE FALSE TRUE

  • You can query this list by running : Get-AdfsAuthenticationProvider

Certificate Authority

Another feature introduced with AD FS 4.0 is the ability to configure in the management console the certificate issuance with two possible
modes. This will be used for User Logon and VPN Access.

  1. Standalone mode: AD FS Issue certificate
  2. Enrollment agent mode: AD FS request certificate to an Enterprise CA

You can manage these settings in the MMC or by running the powershell CMDLet :

For Standalone :

Set-AdfsCertificateAuthority -SelfIssued

For Enterprise CA

Set-AdfsCertificateAuthority `
-EnrollmentAgent `
-CertificateAuthority "ca.contoso.local\contoso-CA" `
-EnrollmentAgentCertificateTemplate "TemplateName" `
-LogonCertificateTemplate "TemplateName" `
-VPNCertificateTemplate "TemplateName" `

  • Note: You need to restart both ADFS and Proxy to take this configuration change.

Access Control Policies

This is a new cool feature introduced in AD FS 4.0, this will allow you to specify a default permission for a new Relying Trust or Application Groups.
You can either use default Access Control Policy or create new ACP

Name Description
Permit everyone Grant access to everyone.
Permit everyone and require MFA from extranet access Grant access to the intranet users and require MFA for the extranet users.
Permit specific group Grant access to users of one or more specified groups.
Permit everyone and require MFA from unauthenticated devices Grant access to everyone and require MFA from unauthenticated devices.
Permit everyone for intranet access Grant access to the intranet users.
Permit everyone and require MFA for specific group Grant access to everyone and require MFA for users of one or more specified groups.
Permit everyone and require MFA Grant access to everyone and require MFA for everyone.

Creating a new Access Control Policy

  • In the AD FS Management Console, go to Access Control Policy
  • Right click and "Add Access Control Policy"
  • Choose a Name and Description
  • Add a rule : PERMIT or EXCEPT
    • from specific network
      • Intranet, Internet or Specified by IPv4, IPV6 single address or range.
    • from specific group
    • from device with specific trust level
    • with specific claims in the request
    • and required multi-factor
  • Check : Require users to provide credentials each time at sign-in. (This was previously a per relying party setting)

This is much simpler than previous ADFS version where claims rules and regex language was used.
In my example; I will create a new Access Control Policy "Allow Restricted_Group ONLY From Intranet Network"
This took me 30 seconds and I can re-use this policy for future Relying Party !

Applications Groups

Applications Groups in AD FS 4.0 are template for publishing Client-Server or Standalone Applications :
We will see in the next part how to use these Application Group and how they work.

Client-Server Applications

Native Application and Web API
A multi-tier application consisting of a native application and a web API. The native application that runs on a phone, tablet, or PC needs to authenticate a user to get resources from a web API secured by ADFS
Access Control Policy, Application Permission Scopes
Server Application and Web API
A multi-tier application consisting of a daemon, server application or website that need to get resources from a web API secured by ADFS
Access Control Policy, Application Permission Scopes

Standalone Applications

Native application
A native application that runs on a phone, tablet, or PC needs to authenticate a user with ADFS -
Server Application or WebSite
A daemon, server application or website that can authenticate itself with ADFS
Application Credentials : Key, Windows Integrated, Shared Secret
A web API secured by ADFS
Access Control Policy, Application Permission Scopes

OAuth Scope Descriptions

The OAuth Scope Descriptions is designed to work with Applications Group.
Basically saying, this will replace the need of Claims Rules and offers a set of default handler for Application Group

ScopeName Description
email Request the email claim for the signed in user.
aza Scope allows broker client to request primary refresh token.
openid Request use of the OpenID Connect authorization protocol.
profile Request profile related claims for the signed in user.
logon_cert The logon_cert scope allows an application to request logon certificates, which can be used to interactively logon authenticated users.
user_impersonation Request permission for the application to access the resource as the signed in user.
vpn_cert The vpn_cert scope allows an application to request VPN certificates, which can be used to establish VPN connections using EAP-TLS authentication.

Per Relying Party Theming

You have now the possibility to set custom theming for individual Relying Party with

Set-AdfsRelyingPartyWebContent `
-TargetRelyingPartyName "RelyingPartyName" `
-CompanyName "CONTOSO INC" `
-OrganizationalNameDescriptionText "RP_TRUST CONTOSO" `
-SignInPageDescription "Please enter your credential to login" 

Using additional LDAP to Authenticate Users (Local Claims Provider)

And finally for this first part, you have now the ability to authenticate user from any other LDAP directory with the new

In the next part, we will see how publish application using the new features.