Active Directory Federation Services (ADFS) is a Single Sign-On solution developed by Microsoft and provides users with authenticated access to applications that are not capable of using Integrated Windows Authentication (IWA) through Active Directory (AD). Take a look at this link to see various options that are possible for Integrating Azure Active Directory with on-Premise Active Directory. You can federate your on-premises environment with Azure Azure Active Directory (AD) and use this federation for authentication and authorization. This sign-in method ensures that all user authentication occurs on-premises. This method allows administrators to implement more rigorous levels of access control. Please see the following guide Azure Active Directory integration with on-Premise AD using PTA for more information and also this guide for reasons to deploy AAD, how to set up Azure AD Tenant, how to add or delete users, and set permissions in Azure Active Directory, why do I need to deploy Azure Active Directory and how to use the built-in AAD Connect troubleshooting tool.
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 the need to provide 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 and can be applied to one or many applications for consistent policy enforcement.
What Changed? What access control policy templates do is 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 it is mutually exclusive of the new mode.
ADFS Requirements: Every AD FS and Web Application Proxy has an SSL certificate to services Https to the federation service. Also the Web Application Proxy can have an additional SSL certificates 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: These certificates are used by claim providers that encrypt tokens issued on AD FS.
Recommended: Also use internally generated certificate for this purpose. I you are required to you a publicly signed SSL certificate for this 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 these certificates are backed up and are 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
I will not be using internal database for AD FS configuration database and therefore will not be using the SQL Server
Note: The AD FS database size is very small, and AD FS does not put a significant processing load on the database instance. AD FS does, however, connect to the database multiple times during an 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 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
There for 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 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 a service account for AD FS. The needed permission needed at runtime will be added to the service account automatically when you configure AD FS.
2. 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 kind of environment, I will not be discussing this further.
Configuration database requirements: 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 This functionality is only used only 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: When AD FS authentication is performed over a web browser, the following guidelines must be followed.
- 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). - 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 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. 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. Same principle applies (extranet/internet) out the cooperate network.
- 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.
- 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.
Since, we are not going to use a load balancer; this scenario requirement will not be considered and discussed.
Permission Requirement: Local administrative rights on the AD FS server in order to configure. Most times, in a domain wide area, this permission is not sufficient enough and therefore, a Domain administrator’s right must be assigned in order to create and add objects in AD.
In Windows Server, AD FS has a federation service role that acts as an
– Identity provider: 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 provides and then provides security tokens to applications that trust AD FS.
Note: The function of providing extranet access to applications and services that are secured by AD FS in Windows Server 2012 R2 is now performed by a new Remote Access role service called Web Application Proxy.
I hope you found this blog post helpful. If you have any questions, please let me know in the comment session.