Share via

AD FS 4.0 : Discover, Setup and Publish Application: Part1

  • Article

Introduction

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 :

(part1)

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

(part2)

  • 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 Name=adfs2016.contoso.com --> Used for the Service Communication
  • (NEW) DNS Name=certauth.adfs2016.contoso.com --> (Alternate) Used for Certificate Authentication on 443 (client)
  • DNS Name=enterpriseregistration.contoso.com --> 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:"adfs2016.contoso.com" `
-GroupServiceAccountIdentifier:"CONTOSO\ADFS2016gMSA`$"
  • 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:"adfs2016.contoso.com" `
-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 adfs2016.contoso.com

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 'adfs2016.contoso.com'

3. AD FS General Settings - View and Configure

Enable the IDPInitiatedSignonPage

Now with AD FS 4.0 the https://adfs2016.contoso.com/adfs/ls/IdpInitiatedSignon 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

Notes

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

  • For additional information : see Access Control Policies in AD FS

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
Web API
 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

Sample:

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
*New-AdfsLdapServerConnection
*

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