Most Microsoft-based Hybrid Identity implementations use Active Directory Federation Services (AD FS) Servers, Web Application Proxies and Azure AD Connect installations. In this series, labeled Hardening Hybrid Identity, we’re looking at hardening these implementations, using recommended practices.
For many organizations the Active Directory administrative tier model is a reality, or at least something they strive to embrace to increase their information security.
How do the Hybrid Identity systems fit into this model?
About the Active Directory administrative tier model
The Active Directory administrative tier model protects identity systems using a set of buffer zones between full control of the environment (Tier 0) and the high risk workstation assets that attackers frequently compromise. The administrative tier model is composed of three levels and only includes administrative accounts, not standard user accounts. The Tier model prevents escalation of privilege by restricting what administrators can control and where they can log on (because logging on to a computer grants control of those credentials and all assets managed by those credentials).
In the model, Active Directory Domain Controllers are placed in Tier 0.
As Tier 0 is the only tier intended to allow direct control of enterprise identities in the environment, Tier 0 includes accounts, groups, and other assets that have direct or indirect administrative control of the Active Directory forest, domains, or domain controllers, and all the assets in it.
Creating a Tier Strategy for Hybrid Identity components
Designing a tier strategy for Hybrid Identity components consists of four separate tasks:
- Designing AD FS Server placement
- Designing Web Application Proxy placement
- Designing Azure AD Connect Server placement
- Designing Azure AD Password Protection placement
Designing AD FS Server placement
AD FS Servers should be placed in Tier 0.
Communications between AD FS servers and between AD FS servers and Domain Controllers should be isolated in Tier 0, too. This traffic should not be permitted to cross less-secure networking zones.
In the RFCs, AD FS servers are referred to as Security Token Service (STS) servers. Functionally, they translate Kerberos tokens to claim tokens. Claim tokens are the equivalent of Kerberos tokens for their respective open protocols, like WS-Federation, SAML, OAuth2, Open ID Connect and SCIM.
The way an attacker may use claim tokens is to forge a claim token for an administrative user account and then reset its password using Azure AD Self-Service Password Reset.
When Microsoft SQL Server is used as the back-end for AD FS, the SQL server(s) hosting the database should also be placed in Tier 0. This might mean that the SQL Server (cluster) hosting the ADFSConfigurationVx and ADFSArtifactStore databases should be a separate SQL Server (cluster) than the one(s) hosting other non-Tier0 databases.
Designing Web Application Proxy placement
Web Application Proxies should be placed on the extranet.
They should not be joined to an Active Directory domain.
For their communications to AD FS servers, Web Application Proxies only use TCP443 (https), leveraging MS-ADFSPIP with short-lived certificates that are signed and distributed by the AD FS farm. However, this communications flow into Tier 0 cannot be intercepted or inspected, as it would break MS-ADFSPIP. Instead, intercept and inspect at the edge of the network.
Designing Azure AD Connect Server placement
Azure AD Connect servers should be placed in Tier 0.
Azure AD Connect uses an ADSync database per Azure AD Connect installation. This database contains information on all objects in scope for Azure AD Connect. It also contains information on its service accounts, used to write objects in Azure AD and to perform write-back operations into Active Directory.
An attacker can use the information in the ADSync database to create and alter objects in both Azure AD and Active Directory.
As Tier 0 dictates no Internet access, Azure AD Connect should be configured to use proxy servers to transit from Tier 0 into Tier 1 and, ideally, from Tier 1 to the Internet.
Designing Azure AD Password Protection placement
Azure AD Password Protection can be used to prevent weak passwords. It offers a hybrid model, where password changes are intercepted using a password filter driver on each Domain Controller and a proxy component to update the password filter driver.
The Azure AD Password Protection agent component is installed on each Domain Controller and therefore resides in Tier 0.
The Azure AD Password Protection proxy component should be placed in Tier 1. This component was designed to do so, as Microsoft specifically signs and encrypts each update that goes to the Domain Controllers.
Designing a networking infrastructure for Hybrid Identity components
Designing a networking infrastructure for Hybrid Identity components consists of four separate tasks:
- Designing AD FS Server networking
- Designing Web Application Proxy networking
- Designing Azure AD Connect Server networking
Designing AD FS Server networking
AD FS Servers should be placed as close as possible to Domain Controllers from a networking perspective. This prevents time-outs that may result in authentication failures for end-users.
AD FS servers should reside on the internal network. They can be place on the same network segment as the Domain Controllers, or on a network segment close to it, but separated by a (next-generation) firewall. As AD FS servers use SCHANNEL to communicate to Domain Controllers, this traffic can be inspected.
AD FS servers need to exchange federation metadata with federation partners, when the relying party trust (RPT) to these partners is configured through a Federation Metadata URL. AD FS servers also need to perform certificate revocation checks for the certificates of federation partners. The above traffic can be allowed through a proxy.
Designing Web Application Proxy networking
Web Application Proxies can be integrated with the networking infrastructure in two ways:
- Web Application Proxies can be placed on a perimeter network.
- Web Application Proxies can be domain-joined.
In the first scenario, the Web Application Proxy acts as an AD FS Proxy to publish the AD FS servers in the AD FS farm to the Internet. Publishing AD FS to the Internet is a requirement for federating with Azure AD and Office 365. In this scenario, the Web Application Proxy is capable of publishing application with pass-through authentication.
In the second scenario, the Web Application Proxy acts as both an AD FS Proxy and an App-publishing proxy. However, the web applications in this scenario need to be published requiring AD FS authentication to access the applications. To this purpose, the Web Application Proxy needs to be joined to the same Active Directory domain as the AD FS server(s).
The first scenario is the preferred scenario. In this scenario, Web Application Proxies only need TCP 443 access to the (load-balancer of the) internal AD FS Servers from the perimeter network. The AD FS Fam must be discoverable through HOSTS or DNS.
To the Internet, the (load-balancer of the) Web Applications Proxies need to be accessible on TCP 443. TCP 49443 may be required on Windows Server 2012 R2-based AD FS implementations and Windows Server 2016/2019-based AD FS implementation that do not have the certauth.adfsname.domain.tld DNS name registered in the AD FS Service Communications certificate.
Designing Azure AD Connect Server networking
Azure AD Connect servers should be placed as close as possible to Domain Controllers from a networking perspective. Azure AD Connect servers should reside on the internal network. They can be place on the same network segment as the Domain Controllers, or on a network segment close to it, but separated by a (next-generation) firewall. As Azure AD Connect servers use SCHANNEL to communicate to Domain Controllers, this traffic can be inspected.
The traffic from Azure AD Connect to its Azure-based endpoints cannot be inspected, as it uses mTLS. However, the traffic can be passed through a proxy server (multiple times).
In contrast to earlier versions of the Azure AD Connect Health agent, the current Azure AD Connect Health agent is capable of using a proxy server, if manual registration is performed through Windows PowerShell and the PowerShell session is configured to use a proxy.
Organizations may choose to domain-join or not to domain-join Azure AD Connect installations. non-Domain-joined Azure AD Connect installations cannot be used to manage AD FS. non-Domain-joined Azure AD Connect installations also require more administrative effort to maintain, activate, update, audit and monitor.
The Active Directory administrative tier model that dominates many of today’s Active Directory implementations, can be used to make the right design decisions for Hybrid Identity components, too.