Deploy Active Directory Federation Services (AD FS) 3.0 in a pre Windows Server 2012 R2 era

As you probably know a prerequisite for implementing Active Directory Federation Services (AD FS) based on Windows Server 2012 R2 is to have at least a Windows Server 2012 R2 domain controller available in your infrastructure.

This in order to take benefit of using Group Managed Service Accounts (GMSA – generated and maintained by the Key Distribution Service (KDS) on at least Windows Server 2012 domain controllers). The same applies to Device Registration service (DRS) aka Workplace Join, which is responsible for activation and enrolment of controlled devices and represented by a new schema class in Active Directory Domain Services (AD DS).

During a Windows Intune proof of concept (PoC) engagement we had to deal with an environment having native Windows Server 2008 R2 domain controllers available.

As DRS was not a deliverable of this PoC we could bypass the AD FS prerequisite by using a default service account.  “gMSA is not required to be the service account that AD FS runs on. It is an additional optimization that is available to customers if they have Windows Server 2012 domain controllers or above available”. So this paves the way for continuing the PoC using the traditional service account option during the installation of AD FS.

Make sure the service account you manually created is moved to the Managed Service Accounts container otherwise you will not pass the AD FS pre-requisite checks during the AD FS configuration wizard.

After moving the service account to the Managed Service Accounts container we passed the pre-requisite checks and configured AD FS successfully!

The process of configuring manually a service account for AD FS is described here.

From AD DS perspective you are able to deploy AD FS 3.0 taking into account:

Domain controller requirements

• For AD FS to be supported, domain controllers in all user domains and in the domain that AD FS servers are joined to must be running Windows Server 2008 or later.

Domain functional-level requirements

• All user account domains and the domain that the AD FS servers are joined to must be operating at the domain functional level of Windows Server 2003 or higher.

Schema requirements

• AD FS does not require schema changes or functional-level modifications to AD DS.
• To use Workplace Join functionality, the schema of the forest that AD FS servers are joined to must be set to Windows Server 2012 R2.

Service account requirements

• Any standard service account can be used as a service account for AD FS. Group Managed Service accounts are also supported. This requires at least one domain controller (it is recommended that you deploy two or more) that is running Windows Server 2012 or higher.
• For Kerberos authentication to function between domain-joined clients and AD FS, the ‘HOST/<adfs_service_name>’ must be registered as a SPN on the service account. By default, AD FS will configure this when creating a new AD FS farm if it has sufficient permissions to perform this operation.
• The AD FS service account must be trusted in every user domain that contains users authenticating to the AD FS service.

Domain Requirements

• All AD FS servers must be a joined to an AD DS domain.
• All AD FS servers within a farm must be deployed in a single domain.
• The domain that the AD FS servers are joined to must trust every user account domain that contains users authenticating to the AD FS service.

Multi Forest Requirements

• The domain that the AD FS servers are joined to must trust every user account domain or forest that contains users authenticating to the AD FS service.
• The AD FS service account must be trusted in every user domain that contains users authenticating to the AD FS service.

Sources:

http://blog.stangroome.com/2013/07/28/avoid-password-management-with-group-managed-service-accounts/

http://blog.auth360.net/2013/09/13/first-impressions-ad-fs-and-windows-server-2012-r2-part-i/

http://technet.microsoft.com/en-us/library/dn554247.aspx#BKMK_4