This is a step by step guide to installing and configuring Windows Server 2016 Active Directory Federation Services (AD FS) for use with Office 365.  If you still wish to deploy the previous version of AD FS (Windows Server 2012 R2 AD FS), then please start with this post.  For those with a keen eye, the 2012 R2 post was published exactly three years ago today.

The act of deploying and configuring AD FS 2016 for Office 365 will be broken down into three separate blog posts:

1. Install AD FS (this post)
   
2. Install AD FS Proxy
   
3. Leverage AD FS with Office 365
   

We shall install AD FS 2016 since there are numerous compelling features in this release!

AD FS Role Planning

The AD FS role should be deployed within the corporate network, not in the DMZ.  The AD FS proxy role (WAP in Windows Server 2016) is intended to be installed into the DMZ.

The default topology for Active Directory Federation Services (AD FS) is a federation server farm, using the Windows Internal Database (WID).  This may contain several federation servers hosting your organization’s Federation Service. In this topology, AD FS uses WID as the store for the AD FS configuration database for all federation servers that are joined to that farm. The farm replicates and maintains the Federation Service data in the configuration database across each server in the farm.

Since the availability of Office 365 relies upon the availability of AD FS when the domain is federated there is a strong recommendation to have at least two AD FS servers with a redundant AD FS proxy infrastructure.  This will also require a load balancing solution as well for both internal and external endpoints.

Please review the design guidance on TechNet.

AD FS Service Account

We can use a standard service account or a Group Managed Service Account (gMSA). Since this is a Windows Server 2012 or newer feature, you will require at least one Windows Server 2012 DC or newer.

You need to decide if you want to use a gMSA service account or a standard service account.  The advantage of the gMSA is that it will automatically update its password.  You must manually update and orchestrate the password change for a standard service account.

If using a regular (non gMSA) service account pre-create using your standard process to document the account and its password.

You will need to create the Key Distribution Services KDS Root Key if creating a gMSA for the first time in the environment.

While the advantage of a gMSA is that it automates the password change process, note that you must create the Key Distribution Services (KDS) Root Key before AD will allow gMSA creation.

Windows Server 2012 domain controllers require a root key to begin generating gMSA passwords. The domain controllers will wait up to 10 hours from time of creation to allow all domain controllers to converge their AD replication before allowing the creation of a gMSA. The 10 hours is a safety measure to prevent password generation from occurring before all DCs in the environment are capable of answering gMSA requests. If you try to use a gMSA too soon the key might not have been replicated to all Windows Server 2012 DCs and therefore password retrieval might fail when the gMSA host attempts to retrieve the password. gMSA password retrieval failures can also occur when using DCs with limited replication schedules or if there is a replication issue.

If you have a test lab with a single DC then you can run the below command so that it is immediately effective.  Note the minus 10 hours on the Effective time.

In the wingtiptoys lab there are multiple DCs so the KDS Root key was created in advance.

was executed on a Windows Server 2012 R2 DC.

Elevated AD permissions are required to complete this procedure

Kerberos SPN

It is required that a Service Principal Name (SPN) is configured for the service account which will run the federation service.  The installation process should set the required Service Principal Names (SPN) on the account.  If not you should be prompted to do so.

This can happen if you are building a totally separate AD FS 2016 farm from an existing 2012 R2 farm and you used the same AD FS namespace, e.g. sts.wingtiptoys.ca for both farms.

You can verify the SPN set on the existing farm using SETSPN which is a built-in Windows utility.  Note that the SPN is not set on the computer object of an AD FS server,  It is set on the service account.  In the below example, the existing service account for the 2012 R2 farm is call ADFS-Service.

This is an example where a regular service account is used:

And for a gMSA account:

AD FS Namespaces

Select what federation namespace you want to access AD FS.  Typically this is along the lines of:

sts.wingtiptoys.ca

adfs.tailspintoys.ca

Note that this is the namespace for the AD FS service.  Since we will be using Kerberos to access AD FS internally, there must be a Service Principle Name (SPN) registered for this name.  This will be associated to the service account, and since SPNs operate in the “Highlander – there can be only one!” mode you do not want to duplicate the SPN on the AD FS server by naming the computer the same as the AD FS namespace.

You also want to discuss what display name should be chosen, as this will be visible to users.  The name chosen is an optics issue, rather than technical.

For device registration or for modern authentication to on-premises resources using pre-Windows 10 clients, the SAN must contain enterpriseregistration.<upnsuffix> for each UPN suffix in use in your organization.

This would be enterpriseregistration.wingtiptoys.ca in this environment.

AD FS 2016 adds support for a new feature to permit access to device authentication and user authentication on the same TCP port.  In AD FS 2012 R2 this required separate TCP ports, where TCP443 and 49433 were used for user and device authentication respectively.  This is a called alternate TLS client binding mode and is new in Windows 2016 AD FS.   Now it is possible to create multiple bindings on the same TCP port.

There are two ways in which AD FS 2016 can be deployed:

• Use separate ports – same as Windows 2012 R2 AD FS – TCP 443 and 49433
  
• Use same port – TCP 443 with two namespaces. sts.wingtiptoys.ca and also certauth.sts.wingtiptoys.ca
  

Note that is a little different from Server Name Indication (SNI) which was previously added in Windows 2012 R2 AD FS.

While this post focuses on the deployment of AD FS for Office 365, you should also consider if the farm will also be used for other services.  For this reason you may want to add in the additional names to the certificate even if you do not plan to use them immediately.

Depending upon the environment and the devices you wish to support, add the names to the certificate request.

These names must also be created in DNS.

Internet Access

The AD FS server will require access to the Internet in order to complete the configuration of the solution.  This may be an issue if your servers are behind a proxy solution.

Certificates

Since AD FS leverages SSL, we need to have a SSL certificate.  You could try three options, but only one will work:

1. Self-signed certificate
   
2. Certificate issued from internal PKI
   
3. Certificate from 3rd party public CA
   

Clients needs to see a valid Service Communication Certificate on your AD FS infrastructure, so you are going to have to purchase a certificate from a public CA.  External clients and devices such as mobile phones will not trust a service communication certificate that is either self-signed or from your internal CA, which results in tears.  We can certainly use self-signed certificates for the Token Decryptingand Token Signing Certificate.  These are separate from the service communication cert.  This is the default configuration in fact.

Note that certificates are only to be requested after all of the AD FS namespaces have been reviewed.  If you do not plan the namespaces, then there is a good chance you will have to go back to the issuing CA and request a new certificate with new or updated names.  Mistakes will cost time and money.

This post assumes that you have already acquired and installed a valid 3rd party certificate onto the AD FS and WAP server[s].  If required, you can follow the steps in How To Request Certificate Without Using IIS or Exchange to obtain the certificate with the correct names.

Please follow the documentation from your chosen CA to request, install and complete the certificate.  The steps required vary from vendor to vendor and also over time.  Make sure you are not missing any updated intermediate certificates!  How would you know?  Follow their  process!!

For the purposes of this post we shall deploy the initial AD FS server, and in a future post add another AD FS server for redundancy.

If you wish to use the Device Registration Service (DRS), then add the additional name onto the certificate.  Even if you are not using DRS now you may want to save time updating certificates later on. See also the above note on AD FS certauth.

Database

By default AD FS will deploy to a Windows Internal Database (WID).  Each AD FS server in the farm will have a local WID, which are kept up to date by a replication process.

The WID database will provide enough scalability for most deployments.

Note that due to the replication process, WID does not support SAML artefact resolution or token replay detection.

Both SAML artefact resolution and token replay detection are supported in a SQL Server farm.  Though neither are currently in-scope for Office 365.  You may require these features for other applications or services which be linked to this AD FS farm.

Installing AD FS On Windows Server 2016

After starting up server manager’s add roles and features wizard, select Active Directory Federation Services, then click next.

We don’t need to add any additional features.  Remember that the IIS dependency was removed in AD FS 2012 R2.

Clicking next takes us to the AD FS splash screen.  Note that it helpfully tells us that the specific AD FS proxy role has been removed in Windows 2016 and how to go about installing it.

If needed the help links along the bottom are:

Learn more about Azure Active Directory

Configure Office 365 with Azure Active Directory Connect

Clicking next will then install the necessary bits.

Bits are being shuffled around…

Shuffling has been completed, and the installation is complete.   You can launch the AD FS configuration wizard from here, or alternatively if this window is closed it can be launched from Server Manager.

Before starting the AD FS configuration wizard note that the 3rd party certificate was previously installed and tested.

The choice of service account type was also made prior to starting the installation wizard.  in this case the KDS Root container was pre-created.

The wizard also states that you must have access to Domain Admin (DA) credentials!

Note that you are only given an option to either make a new AD FS farm or add this box to an existing farm.  This saves the painful issue from older AD FS builds, where AD FS was not installed into a farm you were then unable to add the second AD FS server for redundancy.  In that case you had to build a brand new farm from scratch.

AD FS Prerequisites – points to the Windows 2012 R2 prerequisites

Azure Active Directory Connect

Provide your domain admin credentials.

We need to select the SSL certificate that we will use and also provide the AD FS name we selected in the design process.

In this case the name is sts.wingtiptoys.ca   — note that there is no concept of an InternalURL or ExternalURL for the AD FS namespace.  Clients will use the same name on the intranet and internet to locate AD FS.  Thus split DNS will direct clients to the correct endpoint based on their location and make life simple!

Type in the chosen display name, and click next.

As mentioned earlier it is possible to use a gMSA as the AD FS service account.  gMSA will automatically update the service account’s credentials and administrators will also be oblivious as to its password.  Note that if you do want to use a GMSA, please review the required setup for this, noting the DC version requirements and the steps you must manually perform.  Also allow time to pre-create the KDS Root Container.

If the required steps are not performed, you will be unable to use a gMSA.  Note that the gMSA option is greyed out in the example below, as the KDS Root Container has not been created.

Clicking “show more” reveals why this is the case.

Creating the KDS Root key, unlocks the the option to create a gMSA.  As mentioned above, the KDS Root Key was previously created, and then the next day AD FS was installed and configured.  Note that in the example below, the option to use a gMSA is enabled.

Specify the name of the gMSA account to create.  In this case it will be called gMSA-STS.

Select the database configuration as per the design. The Wingtiptoys corporation will use WID.

Review the options and when happy, pull the trigger!

Pre-requisite Checks are performed.

Clicking “Show More” will display the highlighted pop-up box.

Click Configure to start the configuration process.

When configuration has completed, the results screen is displayed.  This should look like the below.

For reference the help links are included below:

Next steps required for completing your federation service deployment

Need to monitor AD FS service?  Use Azure Active Directory Connect Health

Installing AD FS 2016 Using PowerShell

For reference the PowerShell scripts for farm creation using both types of service accounts are below.

Note that all of the same pre-work must still be done.   You will also need to update the commands so that your certificate thumbprint is used.  Using the Wingtiptoys thumbprint will not work out well for you…

gMSA Service Account

#
# Windows PowerShell script for AD FS Deployment
#

Import-Module ADFS

Install-AdfsFarm `
-CertificateThumbprint:”B67B94AF838E42184F96EE63A8AFCF4C63B054D5″ `
-FederationServiceDisplayName:”Wingtiptoys STS” `
-FederationServiceName:”sts.wingtiptoys.ca” `
-GroupServiceAccountIdentifier:”WINGTIPTOYS\gMSA-STS`$”

Standard Service Account

#
# Windows PowerShell script for AD FS Deployment
#

Import-Module ADFS

# Get the credential used for the federation service account
$serviceAccountCredential = Get-Credential -Message “Enter the credential for the Federation Service Account.”

Install-AdfsFarm `
-CertificateThumbprint:”B67B94AF838E42184F96EE63A8AFCF4C63B054D5″ `
-FederationServiceDisplayName:”Wingtiptoys STS” `
-FederationServiceName:”sts.wingtiptoys.ca” `
-ServiceAccountCredential:$serviceAccountCredential

Next Steps

We are not quite done yet, and there a couple of additional things to do!

AD FS Update(s)

Ensure that you continue to patch and maintain Windows updates on the servers.  This will patch and maintain AD FS 2016.

Required Updates for Active Directory Federation Services (AD FS) and Web Application Proxy (WAP)

DNS A Record

We must create the DNS record  for the AD FS instance.  This maps to the AD FS namespace that we previously planned.  Create this A record in your internal DNS infrastructure.

Ideally you will have multiple AD FS servers for resiliency, in which case you will need to create a load balanced VIP for this service.  Please follow the steps for your specific LB device.  There are specific health check pages for the LB to monitor, which we will look at in a later post.  The DNS A record should resolve to the VIP.   For testing purposes, use a hosts file on a client to check out individual AD FS servers – do not try and just use the IP address of an AD FS server in your browser, it will not work.

Once the DNS record has been created and propagated, ensure that it resolves correctly.

One thing to mention here, if you create a CNAME and point that to the server hosting AD FS chances are that you will run into a never ending authentication prompt situation.

In the below example the AD FS namespace is called sts.wingtiptoys.ca and a CNAME was used to direct traffic to the AD FS server called ADFS-2016-1.wingtiptoys.ca.    This will likely cause the client to obtain a Kerberos ticket for the incorrect name.  As a result, authentication will not work.

The easiest way to stop this is to use  a regular A record, like so:

There is also an option contained in KB 911149  that some folks have mentioned.

Additional Steps

For additional operational tasks please review: AD FS 2016 Operations.

Verify Event logs

Ensure that there are no errors in the System of Application event logs.  Additioally also review the AD FS event log.  Please note that this log is located underneath the Application and Services Logs container.

Verify Federation Service Metadata

Open Internet Explorer and navigate to your AD FS server’s federation metadata URL.

This will be something like the below, just change the FQDN to match your environment.

https://adfs.tailspintoys.ca/federationmetadata/2007-06/federationmetadata.xml

https://sts.wingtiptoys.ca/federationmetadata/2007-06/federationmetadata.xml

The result should show this:

Note that if the federation metadata page looks like the below, the AD FS endpoint was not added to the local intranet security zone in IE.  More on that topic later in this post.

Verify AD FS Sign-In Page

Note that AD FS 2016 disables the idpinitiatedsignon page by default, and you will need to manually enable it using:

Browse to the AD FS sign-in page and test that you are able to authenticate.

The URL will be similar to the below, again change the FQDN to match your organisation’s.

https://adfs.tailspintoys.ca/adfs/ls/idpinitiatedsignon.htm

https://sts.wingtiptoys.ca/adfs/ls/idpinitiatedsignon.htm

You should see the below, and be prompted to sign in:

Depending upon how IE is configured you will either be prompted to provide credentials or be automatically signed-in.

If you want to have users be automatically signed-in then configure your browser settings to trust the federation server role by adding your federation service name (for example https://sts.wingtiptoys.ca) to the browser’s local intranet zone. This will enable seamless sign-in using Windows Integrated Authentication.

Once we are happy that the AD FS instance is functioning appropriately we can then move onto installing the AD FS proxy role (WAP).

This will be covered in the second post in this series, to prevent this one getting too long!

Verify Listening Ports

If you want to investigate the TCP ports which the AD FS server is listening on, netstat can be used for this.

Verify Netsh Bindings

The same applies if you want to see the SSL bindings.  We can use netsh to review them:

Additional Issues

The below are some issues which you may encounter during AD FS deployment.  The list is not exhaustive, and will change over time.

Configuration Database Already Exists

If you are re-installing AD FS onto an existing instance it will check if the configuration database exists.  If this is the case you can then overwrite the existing one.

gMSA Root Key Not Replicated

If insufficient time has elapsed after creating the KDS Root Key, then you will have issues creating a gMSA account.

We need to hurry-up and wait.

Should you proceed without heeding the warning, the below will be your prize.

Certauth and EnterpriseRegistration SAN Names

If the certauth and enterpriseregistration SAN names are not present on the certificate, then the AD FS 2016 installation wizard will flag a warning on this.

Cheers,

 

• Active Directory Federation Services
  • AD FS Overview
    • What’s new in Active Directory Federation Services for Windows Server 2016
    • AD FS Scenarios for Developers
    • AD FS 2016 Requirements
  • AD FS Design
    • AD FS Design Guide
      • AD FS Design Guide in Windows Server 2012 R2
        • Identify Your AD FS Deployment Goals
        • Plan Your AD FS Deployment Topology
          • Federation Server Farm Using WID
          • Federation Server Farm Using WID and Proxies
          • Federation Server Farm Using SQL Server
        • AD FS Requirements
      • AD FS Design Guide in Windows Server 2012
        • Identifying Your AD FS Deployment Goals
          • Provide Your Active Directory Users Access to Your Claims-Aware Applications and Services
          • Provide Your Active Directory Users Access to the Applications and Services of Other Organizations
          • Provide Users in Another Organization Access to Your Claims-Aware Applications and Services
        • Mapping Your Deployment Goals to an AD FS Design
          • Web SSO Design
          • Federated Web SSO Design
        • Determine Your AD FS Deployment Topology
          • AD FS Deployment Topology Considerations
          • Stand-Alone Federation Server Using WID
          • Federation Server Farm Using WID
          • Federation Server Farm Using WID and Proxies
          • Federation Server Farm Using SQL Server
        • Planning Your Deployment
          • Using AD DS Claims with AD FS
          • Best Practices for Secure Planning and Deployment of AD FS
          • Planning for Interoperability with AD FS 1.x
          • When to Use Identity delegation
          • Deploying AD FS in the Account Partner Organization
            • Review the Role of the Federation Server in the Account Partner
            • Review the Role of the Federation Server Proxy in the Account Partner
            • Prepare Client computers in the Account Partner
          • Deploying AD FS in the Resource Partner Organization
            • Review the Role of the Federation Server in the Resource Partner
            • Review the Role of the Federation Server Proxy in the Resource Partner
            • Determine Your Federated Application Strategy in the Resource Partner
        • Planning Federation Server Placement
          • When to create a Federation Server
          • Where to Place a Federation Server
          • When to create a Federation Server Farm
          • Certificate Requirements for Federation Servers
            • Token-Signing Certificates
            • Service Communications Certificates
          • Name Resolution Requirements for Federation Servers
        • Planning Federation Server Proxy Placement
          • When to create a Federation Server Proxy
          • Where to Place a Federation Server Proxy
          • When to create a Federation Server Proxy Farm
          • Certificate Requirements for Federation Server Proxies
          • Name Resolution Requirements for Federation Server Proxies
        • Planning for AD FS Server Capacity
          • Planning for Federation Server Capacity
          • Planning for Federation Server Proxy Capacity
        • Appendix A: Reviewing AD FS Requirements
  • AD FS Deployment
    • AD FS Deployment Guide
    • Best Practices for Securing AD FS
    • Plan Device-based Conditional Access on-Premises
    • Required updates for AD FS and WAP
    • Set up Geographic Redundancy with SQL Server Replication
    • Set up the lab environment for AD FS in Windows Server 2012 R2
    • Upgrading to AD FS in Windows Server 2016 using a WID database
    • Upgrading to AD FS in Windows Server 2016 using a SQL database
    • Deploy Azure AD Connect Health to Monitor your on-premises identity infrastructure in the cloud
    • Windows Server 2016 and 2012 R2 AD FS Deployment Guide
      • Deploying a Federation Server Farm
        • Join a computer to a Domain
        • Enroll an SSL Certificate for AD FS
        • Install the AD FS Role Service
        • Configure a Federation Server
        • Configure a federation server with Device registration Service
        • Configure Corporate DNS for the Federation Service and DRS
        • Verify your Windows Server 2012 R2 Federation Server Is Operational
      • Deploying Federation Server Proxies
      • Azure Active Directory Connect
    • Windows Server 2012 AD FS Deployment Guide
      • Planning to Deploy AD FS
      • Implementing Your AD FS Design Plan
      • Checklist: Implementing a Web SSO Design
      • Checklist: Implementing a Federated Web SSO Design
      • Configure Partner Organizations
        • Checklist: Configure the Account Partner Organization
        • Checklist: Configure the Resource Partner Organization
        • Add an attribute Store
        • Create a Claims Provider Trust Using Federation Metadata
        • Create a Relying Party Trust Using Federation Metadata
        • Add a Claim Description
        • Configure Client computers to Trust the Account Federation Server
        • Distribute Certificates to Client computers by Using Group Policy
      • Configuring Claim Rules
        • Checklist: Creating Claim Rules for a Claims Provider Trust
        • Checklist: Creating Claim Rules for a Relying Party Trust
        • Create a Rule to Pass Through or filter an Incoming Claim
        • Create a Rule to Send an AD FS 1.x compatible Claim
        • Create a Rule to Permit All Users
        • Create a Rule to Permit or Deny Users Based on an Incoming Claim
        • Create a Rule to Send LDAP attributes as Claims
        • Create a Rule to Send Group Membership as a Claim
        • Create a Rule to Transform an Incoming Claim
        • Create a Rule to Send an Authentication Method Claim
        • Create a Rule to Send Claims Using a Custom Rule
      • Deploying Federation Servers
        • Checklist: Setting Up a Federation Server
        • Add a Host (A) Resource Record to Corporate DNS for a Federation Server
        • Manually Configure a Service Account for a Federation Server Farm
        • Install the Federation Service Role Service
        • Create the First Federation Server in a Federation Server Farm
        • Create a Stand-Alone Federation Server
        • Add a Federation Server to a Federation Server Farm
        • Add a Token-Signing Certificate
        • Add a Token-Decrypting Certificate
        • Set a Service Communications Certificate
        • Verify That a Federation Server Is Operational
      • Deploying Federation Server Proxies
        • Checklist: Setting Up a Federation Server Proxy
        • Join a computer to a Domain
        • Configure Name Resolution for a Federation Server Proxy in a DNS Zone That Serves Only the Perimeter Network
        • Configure Name Resolution for a Federation Server Proxy in a DNS Zone That Serves Both the Perimeter Network and Internet Clients
        • Export the Private Key Portion of a Server Authentication Certificate
        • Import a Server Authentication Certificate to the Default Web Site
        • Install the Federation Service Proxy Role Service
        • Configure a computer for the Federation Server Proxy Role
        • Verify That a Federation Server Proxy Is Operational
        • Configure Performance Monitoring
      • Interoperating with AD FS 1.x
        • Checklist: Configuring AD FS to Consume Claims from AD FS 1.x
        • Checklist: Configuring AD FS to Send Claims to an AD FS 1.x Federation Service
        • Checklist: Configuring AD FS to Send Claims to an AD FS 1.x Claims-Aware Web Agent
        • Create a Relying Party Trust Manually
        • Create a Claims Provider Trust Manually
        • Create a Rule to Send an AD FS 1.x compatible Claim
    • Deploy Azure AD Connect Health
    • Migrate Active Directory Federation Services Role Services to Windows Server 2012 R2
      • Prepare to Migrate the AD FS Federation Server
      • Migrate the AD FS Federation Server
      • Migrate the AD FS Federation Server Proxy
      • Verfiy the AD FS Migration to Windows Server 2012 R2
    • Migrate Active Directory Federation Services Role Services to Windows Server 2012
      • Prepare to Migrate the AD FS 2.0 Federation Server
        • Prepare to Migrate the AD FS 2.0 Stand Alone or Single Node Farm Server
        • Prepare to Migrate the AD FS 2.0 WID Farm
        • Prepare to Migrate the AD FS 2.0 SQL Farm
      • Prepare to Migrate the AD FS 2.0 Federation Server Proxy
      • Migrate the AD FS 2.0 Federation Server
        • Migrate the AD FS 2.0 Stand Alone or Single Node Farm Server
        • Migrate the AD FS 2.0 WID Farm
        • Migrate the AD FS 2.0 SQL Farm
      • Migrate the AD FS 2.0 Federation Server Proxy
      • Migrate the AD FS 1.1 Web Agents
  • AD FS Development
    • Custom Id Tokens in AD FS
    • AD FS On-behalf-of Authentication in Windows Server 2016
    • Enabling OpenId Connect with AD FS 2016
    • Enabling Oauth Confidential Clients with AD FS 2016
    • Single log-out for OpenID Connect with AD FS
    • Single Page Application with AD FS
  • AD FS Operations
    • AD FS Access Control Policies
      • Access Control Policies in AD FS for Windows Server 2016
      • Access Control Policies in AD FS for Windows Server 2012 R2
      • Access Control Policies in AD FS 2.0
    • AD FS Prompt login parameter support
    • AD FS 2016 Single Sign On Settings
    • AD FS Rapid Restore Tool
    • AD FS support for alternate hostname binding for certificate authentication
    • AD FS user sign-in customization
    • Add an attribute Store
    • Compound authentication and AD DS claims in AD FS
    • Configure AD FS 2016 and Azure MFA
    • Configure AD FS Extranet Lockout Protection
    • Configure AD FS to authenticate users stored in LDAP directories
    • Configure AD FS to Send Password Expiry Claims
    • Configure additional Authentication Methods for AD FS
    • Configure Authentication Policies
    • Configure Claim Rules
    • Configure Device-based Conditional Access on-Premises
    • Configure intranet forms-based authentication for devices that do not support WIA
    • Configuring Alternate Login ID
    • Create a Claims Provider Trust
    • Create a Non-Claims Aware Relying Party Trust
    • Create a Relying Party Trust
    • Device Authentication Controls in AD FS
    • Improved interoperability with SAML 2.0
    • Join to Workplace from Any Device for SSO and Seamless Second Factor Authentication Across company Applications
    • Manage Risk with additional Multi-Factor Authentication for Sensitive Applications
    • Manage Risk with Conditional Access Control
    • Managing SSL Certificates in AD FS and WAP 2016
    • Managing SSL Protocols in AD FS
    • Plan Device-based Conditional Access on-Premises
    • Set up an AD FS lab environment
    • Walkthrough Guide: Manage Risk with additional Multi-Factor Authentication for Sensitive Applications
    • Walkthrough Guide: Manage Risk with Conditional Access Control
    • Walkthrough: Workplace Join with a Windows Device
    • Walkthrough: Workplace Join with an iOS Device
    • Walkthrough: Workplace Join with an Android Device
  • AD FS Technical Reference
    • AD FS and certificate KeySpec property information
    • Auditing Enhancements to AD FS in Windows Server
    • Understanding Key AD FS Concepts
      • The Role of attribute Stores
      • The Role of the AD FS Configuration Database
      • The Role of Claims
      • The Role of Claim Rules
      • The Role of the Claims Engine
      • The Role of the Claims Pipeline
      • The Role of the Claim Rule Language
      • Determine the type of Claim Rule Template to Use
      • How URIs Are Used in AD FS
    • Device registration Technical Reference
  • AD FS 2016 FAQ
• Securing Privileged Access
  • Privileged Access Workstations
  • Securing Privileged Access Reference Material
• Software Restriction Policies
  • Software Restriction Policies Technical Overview
  • Administer Software Restriction Policies
    • Determine Allow-Deny list and Application Inventory for Software Restriction Policies
    • Work with Software Restriction Policies Rules
  • Use software restriction policies to help protect your computer against an email virus
  • Troubleshoot Software Restriction Policies

Installing ADFS-2016 using PowerShell