With the impending release of Windows Server 2016, we will soon have a new version of AD FS available to use with our various cloud deployments. I thought this would be a good time to start looking at the new features and functionality of Active Directory Federation Services (AD FS) in the new version of Windows Server.
In this post, I’m going to introduce three new features to AD FS in Windows Server 2016: The upgrade process, improved auditing, and the AD FS rapid restore tool. In a future blog post (after Windows Server 2016 is released), I’ll dive into the specifics of setting up and using each of these features.
With the previous versions of AD FS, the process of upgrading your farm included installing a new farm and then switching your DNS records to point to it. That’s not so much of an upgrade as it is a replacement.
The process of upgrading your AD FS farm is very similar to the process of upgrading your Active Directory, so it should be familiar and straightforward. With Active Directory, we talk about Forest Function Level (FFL) and Domain Function Level (DFL). With AD FS, we talk about Farm Behavior Level (FBL).
Coming from Server 2012 R2, you can add new Server 2016 AD FS servers to your existing farm, and then remove your existing Server 2012 R2 AD FS servers. Once all the servers in your AD FS farm are running on Server 2016, you can upgrade the farm function level and start taking advantage of the new features in AD FS. If your AD FS farm is running without a SQL database (using WID), then you will need to designate one of your Server 2016 AD FS servers as the primary node before you can do the FBL promotion by running the following PowerShell Cmdlet:
Set-AdfsSyncProperties -Role PrimaryComputer
Once the primary AD FS server has been set, you’ll need to do a forest prep and a domain prep, then you can run the PowerShell Cmdlet:
Invoke-AdfsFarmBehaviorLevelRaise
If you’ve ever had to figure out who logged into an application via your current AD FS deployment, you likely know that auditing has been somewhat lacking in previous versions of AD FS. In some cases, the current versions of AD FS will log multiple audit events for a single event, and in some cases it will not log anything. With Server 2016 AD FS, auditing is much improved.
With Server 2016, AD FS auditing is on be default at the basic level. There are three possible audit levels for your AD FS servers: None, Basic (default), and Verbose. Verbose will log all events, Basic will log a maximum of 5 events for a single request, and hopefully you can figure out what you get with a logging level of none.
I’m still testing out the usability of this logging in my lab, but early results look positive. It looks like the AD FS logging in this version is much improved, but I’ll get into more detail on that in a later blog post.
Since the beginning of time, or at least the beginning of Office 365, one of the major conflicts with a migration to the cloud has been that gaining a full-featured experience requires a significant number of on-premises servers. AD FS, for example, can provide a “Single Sign On” experience but requires that quite a lot of servers be deployed to ensure high availability.
The new AD FS rapid restore tool gives administrators the ability to export the configuration of a single AD FS server so a new AD FS server can be quickly deployed in the event of a server failure, or the rapid restore tool can be used to duplicate your AD FS servers into a dev/test environment.
The rapid restore tool backs up the following information
The AD FS rapid restore tool can be used on either Server 2016 or Server 2012 R2 AD FS. It does require .NET 4.0 or better installed on the server, and the recovered server must be on the same version as the original source server.
Once installed, you can back up an AD FS server with the Backup-ADFS PowerShell cmdlet. Restores are done via the Restore-AD FS cmdlet.
I’ll be running through a few test backup and restores in the coming weeks, and I’ll be sure to report my experience here. I expect this to be an option that smaller organizations might choose to use instead of building out a huge redundant AD FS infrastructure.
AD FS has the ability to support customized rules that allow some users to authenticate under specified conditions. The most common scenario I see is to have hourly employees only be able to log into their Office 365 email account when they are physically at work.
This can be accomplished using claims issuance policies, but these policies are very difficult to configure and support. With Server 2016 AD FS, we have the ability to control this type of authentication via Access Control Policies that look and feel very much like Group Policy Objects in Active Directory.
AD FS comes with built-in access control policy templates that will cover most of the common scenarios that organizations want to enforce. Permitting a specific group to authenticate or not authenticate at specific times or requiring multi factor authentication for users authenticating off the corporate network are examples of access policies you can configure.
It looks to me like Server 2016 is bringing some pretty impressive improvements to AD FS. The three improvements I covered here are, in my opinion, the highlights of this new release, but there are other features we’ll talk about.
As I write this it’s the Friday before Ignite, so it’s time for me to wrap this up and pack my bags. I’m off to Atlanta to learn some stuff and enjoy some beverages. Hopefully I will see (or saw if you’re reading this in the future) you there!