Guide on federating ADFS with Azure Active Directory

Federation using Microsoft’s Active Directory Federation Services (AD FS) allows Azure AD to pass authentication requests from service providers such as Office 365 and back to your on-premises AD to provide a single sign-on experience to SaaS applications for your users. This provisioning of user identities from on-premise AD forest to Azure AD is currently handled by Azure AD Connect, previously it was handled by Directory synchronisation (DirSync).

Note: AD FS with DirSync has a drawback to this architecture as it can only synchronize with a single Windows Server AD forest and this has been replaced with Active Directory AD Connect. The major difference between AD FS and PTA here is that, outside the complexity of AD FS is. It enables us to support other methods of Password Authentication, 3rd party MFA, and Smart Cards Authentication.

Active directory Federation Services (AD FS):

AD FS provides secure access control and single sign on (SSO) across a wide variety of applications in the cloud such as O365, cloud based SaaS applications, and applications on-premise (corporate network). Here are some benefits of ADFS below;

This service enables your corporate firm to provide SSO functionality to legacy and modern applications both on-premise and in the cloud.
Provides Seamless sign-on option across all platforms with the same credentials.
Enables developers to focus on application development and not on authentication and identity, thereby providing developers with an easy way to authenticate users who reside in the organizations directory system.

AD FS 2016 enables three new options for sign on without passwords, enabling organizations to avoid risk of network compromise from phished, leaked or stolen passwords.

AD FS with MFA – This is one of the methods I will be testing to integrate Azure MFA authentication provider with AD FS. From AD FS 2016, there is a possibility to sign into application ONLY with the Azure MFA code without requiring you to enter your username and password at the initial time. This works by
Setting the Azure MFA as the primary authentication method where the end-user is prompted to username and the OTP code from the Azure Authenticator app
With Azure MFA set as the secondary (additional) authentication method, the user provides primary authentication credentials (using Windows Integrated Authentication, username and password, smart card, or user or device certificate), then sees a prompt for text, voice, or OTP based Azure MFA login.
With the newly integrated built-in Azure MFA adapter, setup and configuration for Azure MFA with AD FS is relatively straight forward.

Now, there is absolutely no need to have the MFA server setup on premise, we can leverage on the capabilities (functionalities) of Azure MFA.

Passwordless Access from Complaint Devices. AD FS provides the ability to sign-on and access control based on the compliance state of the device. Here if the device is non-compliant, users can re-initiate login when the device attribute changes and compliance is re-evaluated
Enable Access only from devices that are managed and compliant.
Enable Extranet Access only from devices that are managed or compliant
Require multi-factor authentication for computers that are not managed or not compliant

Depending on the deployment environment, I would not recommend this as devices are relatively not to date most of the time due to update testing. Having to define these rules will place an overhead.

Sign-in using Windows Hello for Business: Windows 10 introduces Windows Hello and Windows Hello for Business, replacing user passwords with strong device-bound user credentials protected by a user’s gesture (a PIN, a biometric gesture like fingerprint, or facial recognition). To view these settings, type in the search icon “Windows Hello”. This will display the Windows Hello settings where these settings can be done.

Note: AD FS 2016 supports these new Windows 10 capabilities so that users can sign in to AD FS applications from the intranet or the extranet without needing a password.

Access Control Policy Templates in AD FS

Note: There are templates to make AD FS configuration and policies effortless without having to know claim language rules. With access control policies, administrators can use built in templates to apply common policies.

Permit intranet access only
Permit everyone and require MFA from Extranet
Permit everyone and require MFA from a specific group

The templates are easy to customize using a wizard-driven process to add exceptions or additional policy rules. They can be applied to one or many applications for consistent policy enforcement.

What Changed? Access control policy templates replace this old model where administrators have to configure Issuance Authorization Rules using claims language. The old PowerShell cmdlets of issuance authorization rules still apply but are mutually exclusive to the new mode.

ADFS Requirements: Every AD FS and Web Application Proxy has an SSL certificate to service Https to the federation service. Also, the Web Application Proxy can have an additional SSL certificate to service requests to published applications.

1. SSL Certificates: Below are the stated requirements for obtaining an SSL certificate.

It must be publicly trusted (well known CA) for live(production) systems
Server Authentication Enhanced Key Usage (EKU) value must be included in the certificate
Should contain the federation service name eg. Fs.contoso.com in the Subject Alternative Name (SAN).
For user authentication on 443, certificate should contain certauth.<federation service name>”, such as “certauth.fs.contoso.com” in the SAN
For device registration or for modern authentication to on premises resources using pre-Windows 10 clients, the SAN must contain “enterpriseregistration.<upn suffix>” for each UPN suffix in use in your organization.

Since I will not be using a proxy Server, I will ignore the steps needed to request for a license.
Note: If you were to deploy the Web Application proxy server, you will have to use the same certificate both on the Federation Server and Web Application proxy server

2. Service Communication Certificate:
Here use the same SSL certificate for your Federation Server. Not really required as stated in Microsoft documentation with Azure AD and O365. By default, AD FS configures the SSL certificate provided upon initial configuration as the service communication certificate.

3. Token Signing Certificate
This certificate is used to sign issued tokens to relying parties, so relying party applications must recognise the certificate and its associated key as known and trusted. When the token signing certificate changes, such as when it expires and you configure a new certificate, all relying parties must be updated.

Recommendation: Use the AD FS default, internally generated, self-signed token signing certificates. . If you are required to you a publicly signed SSL certificate for this this, see Microsoft documentation.

4. Token Encryption and Decryption Certificates: Nevertheless, These certificates are used by claim providers that encrypt tokens issued on AD FS.
Recommended: Also use the internally generated certificate for this purpose. I you are required to you a publicly signed SSL certificate for this, see Microsoft documentation.

Note: Certificates that are used for token-signing and token-decrypting/encrypting are critical to the stability of the Federation Service. Customers managing their own token-signing & token-decrypting/encrypting certificates should ensure that they are backed up and available independently during a recovery event.

5. User License: When using x509 user certificate authentication with AD FS, all user certificates must chain up to a root certification authority that is trusted by the AD FS and Web Application Proxy servers.

For the Hardware Requirements

Similarly, I will not be using an internal database for the AD FS configuration database and, therefore will not be using the SQL Server.

Note: The AD FS database size is tiny, and AD FS does not put a significant processing load on the database instance. Consequently, AD FS does, however, connect to the database multiple times during authentication, so the network connection should be robust.

Due to my environment size, I will be using more than the specified requirement by Microsoft, with a recommended requirement of 4GB of RAM and 100GB of Disk space. Will be using 4GB of Memory and 200 GB of disk space.

Active Directory Domain Services (AD DS) Requirements.
1. Domain Controller Requirement
Therefore I will be using Windows Server 2016 as it is required for Microsoft Passport for Work.

2. Domain functional level I am using is WS 2016: This is required for client certificate authentication if the certificate is explicitly mapped to a user’s account in AD DS.

Schema Requirements
Note: firstly, If it is a new AD FS2016 would require AD 2016 schema with a minimum version of 85. Secondly, if you would like to raise an existing AD FS (FBL) to the 2016 level, this would require AD 2016 schema with a minimum of version 85.

Service Account Requirements

1. Group-managed service accounts are supported as well as standard account type can be used as service accounts for AD FS. Moreover, The needed permission at runtime will automatically be added to the service account when you configure AD FS.
2. Nonetheless, The User Rights Assignment required for the AD service account is “Log on as a Service”.
3. The User Rights Assignments required for the ‘NT Service\adfssrv’ and ‘NT Service\drs’ are ‘Generate Security Audits’ and ‘Log on as a Service’.

Domain Requirements
AD FS servers must be domain joined.
All AD FS servers within a Farm must be deployed in a single domain.

Multi-Forest Requirements:
Since we do not have this environment, I will not discuss this further.

Configuration database requirements: However, Here are the advantages of using either the WID or SQL Server.
Windows Internal Database (WID):
1. The artifact resolution profile of SAML 2.0 is not supported in a WID farm.
2. Also, the Token reply detection is not supported in a WID farm. (This functionality is only used in scenarios where AD FS is acting as the federation provider and consuming security tokens from external claims providers.)

Note: All the disadvantages of WID discussed above are supported by SQL Server. See the table below for other details on AD FS servers are supported in a WID vs a SQL Server farm.

Browser Requirements: The following guidelines must be followed when AD FS authentication is performed over a web browser.

JavaScript must be enabled.
For SSO, the client browser must be configured to accept cookies
Server Name Indication (SNI) must be supported
What is SNI? Server Name Indication (SNI) is an extension to the Transport Layer Security (TLS) protocol by which a client indicates which hostname it is attempting to connect to at the start of the handshaking process. (src: wiki).
Furthermore, For user and device certificate authentication, the browser must in deed, support SSL client certificate authentication.
For seamless sign-on using Windows Integrated Authentication, the federation service name (such as https://fs.contoso.com) must be configured in the local intranet zone or trusted sites zone.

Network Requirements

Firewall: TCP port 443 should be enabled in bound and if client user certificate authentication (clientTLS authentication using X509 user certificates) is required and the certauth endpoint on port 443 is not enabled, AD FS 2016 requires that TCP port 49443 be enabled inbound on the firewall between the clients. Additionally, Since I am not using an Web Application Proxy, this is ignored.
DNS: All intranet clients within the organization must be able to resolve the AD FS service name to the AD FS server. Nevertheless, the Same principle applies (extranet/internet) out of the cooperate network.
Therefore, For Windows Integrated authentication, you must use a DNS A record (not CNAME) for the federation service name.
For user certificate authentication on port 443, “certauth.<federation service name>” must be configured in DNS to resolve to the federation server.
Similarly, For device registration or for modern authentication to on-premises resources using pre-Windows 10 clients, “enterpriseregistration.<upn suffix>”, for each UPN suffix in use in your organization must be configured to resolve to the federation server or web application proxy.

Consequently, we will not use a load balancer; this scenario requirement will not be considered and discussed.

Permission Requirement: Local administrative rights on the AD FS server to configure. Most times, in a domain-wide area, this permission is not sufficient, and therefore, a Domain administrator’s right must be assigned to create and add objects in AD.

In Windows Server, AD FS has a federation service role that acts as an
– Identity provider: Nonetheless, This means it authenticates users and provides security tokens to applications that trust AD FS or
– Federation consumer: Here, it consumes tokens from other identity providers and then provides security tokens to applications that trust AD FS.

Note: Moreover, The function of providing extranet access to applications and services that AD FS secures in Windows Server 2012 R2 is now performed by a new Remote Access role service called Web Application Proxy.

Furthermore, I hope you found this blog post helpful. However, Please let me know in the comment session if you have any questions.