Introduction

With the release of Windows Server 2016, Microsoft has introduced new and improved features. One of those features is ADFS 4.0, better known as ADFS 2016.

Organisations have already started leveraging ADFS 2016 as it covers most of their requirement, specially in terms of security.

In this series of blog posts, I will demonstrate how you can upgrade from ADFS v 3.0 (Running Windows Server 2012 R2) to ADFS 2016 (Running Windows Server 2016 Datacenter). In the series to come I will also cover Web Application Proxy (WAP) migration from Windows Server 2012 R2 to Windows Server 2016. Moreover, I will cover integration of Azure MFA with the new ADFS 2016.

The posts in this series assume you have knowledge in Windows Servers, AD, ADFS, WAP, and MFA. This blog post will not go into detailed step-by-step installation of roles and features. This blog post also assumes you have a running environment of AD, ADFS/WAP (2012 R2), AAD Connect already configured.

What’s New in ADFS 2016?

ADFS 2016 offers new and improved features included:

  • Eliminate Passwords from the Extranet
  • Sign in with Azure Multi-factor Authentication
  • Password-less Access from Compliant Devices
  • Sign in with Microsoft Passport
  • Secure Access to Applications
  • Better Sign in experience
  • Manageability and Operational Enhancements

For detailed description on the aforementioned points, please refer to this link.

Current Environment

  • 2x ADFS v3 Servers (behind an internal load balancer)
  • 2x WAP 2012 R2 Server (behind an external load balancer)
  • 2x AD 2012 R2 Servers
  • 1x AAD Connect server

At a high level design, this is how the ADFS/WAP environment looks:

sso

Future environment:

  • 2x ADFS 2016 Servers (behind the same internal load balancer)
  • 2x WAP 2016 Servers (behind the same external load balancer)
  • 2x AD 2012 R2 Servers
  • 1x AAD Connect Server

Planning for your ADFS and WAP Migration

At first, you need to make sure that your applications can support ADFS 2016, some legacy applications may not be supported.

The steps to implement SSO are as follows:

  1. Active Directory schema update using ‘ADPrep’ with the Windows Server 2016 additions
  2. Build Windows Server 2016 servers with ADFS and install into the existing farm and add the servers to the Azure load balancer
  3. Promote one of the ADFS 2016 servers as “primary” of the farm, and point all other secondary servers to the new “primary”
  4. Build Windows Server 2016 servers with WAP and add the servers to the Azure load balancer
  5. Remove the WAP 2012 servers from the Azure load balancer
  6. Remove the ADFSv3 servers from the Azure load balancer
  7. Raise the Farm Behavior Level feature (FBL) to ‘2016’
  8. Remove the WAP servers from the cluster
  9. Upgrade the WebApplicationProxyConfiguration version to ‘2016’
  10. Configure ADFS 2016 to support Azure MFA and complete remaining configuration

The steps for the AD schema upgrade are as follows:

  1. Prior to starting, the Active Directory needs to be in a health state, in particular replication needs to be performing without error.
  2. The Active Directory needs to be backed-up. Best to backup (at a minimum) a few Active Directory Domain Controllers including the ‘system state’
  3. Identify which Active Directory Domain Controller maintains the Schema Master role
  4. Perform the update using an administrative account by temporarily adding the account to the Schema Admin group
  5. Download and have handy the Windows Server 2016 installation media
  6. When ready to update the schema, perform the following:
  7. Open an elevated command prompt and navigate to support\adprep directory in the Windows Server 2016 installation media. Run the following: adprep /forestprep.
  8. Once that completes run the following: adprep/domainprep

Upgrading the Active Directory schema will not impact your current environment, nor will it raise the domain/forest level.

Part 2 of this series will be published early next week. Therefore make sure to please come back and check in details the migration process.

 

Category:
ADFS, Identity and Access Management, Office 365, PowerShell, Security, User Experience

Join the conversation! 5 Comments

  1. […] Part 1 of this series we have been getting ready for our ADFS v3.0 migration to ADFS v4.0 (ADFS […]

    Reply
  2. […] Part 1 and Part 2 of this series we have covered the migration from ADFS v3 to ADFS 2016. In this series […]

    Reply
  3. […] Part 1, and Part 2 of this series we have covered the migration from ADFS v3 to ADFS 2016. In this post […]

    Reply
  4. […] previous posts, Part 1 and Part 2 we have covered the migration of ADFS v3.0 to ADFS 2016. I have received some messages […]

    Reply

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: