Something that wasn’t immediately clear (from the UX) or easily obtainable (via Internet search) was information on what configuration, if any, is required in Active Directory Federation Services 2.0 (AD FS 2.0) in an environment where there is multiple Active Directory Domain Services (AD DS) forests and/or domains. And it wasn’t just me either, as I’ve been asked by both colleagues and customers. J
Put simply there’s no need for any configuration in the AD FS 2.0 Management user interface (UI). When you install AD FS an implicit, enabled Claims Provider (CP) Trust for the Active Directory domain in which the server(s) hosting the AD FS instance reside is created. Subsequent access to the federation server (FS) is governed by the ability to authenticate to the FS. That is, if you’ve been authenticated by any of the permissible systems on the other end of the CP trust you are subject to the applicable policy and rules of the relying party (RP) trust.
The FS is actually a .NET web service. Authentication to the FS (or STS) is therefore a feature of Internet Information Services (IIS) which means that if the trust direction is such that users can authenticate in the domain that hosts AD FS then users can authenticate to the FS.
Note. AD FS supports Integrated Windows authentication (IWA); Forms-based authentication (FBA); Transport layer security client authentication (certificates); and basic authentication. I’m specifically addressing the default behaviour for internal Internet Explorer clients. For more information on how to configure the different authentication types refer to the TechNet wiki article AD FS 2.0: How to Change the Local Authentication Type.
The only caveat to the statement that there’s no need for configuration in AD FS 2.0 is that you might, depending on the configuration of directory permissions and LDAP queries performed by AD FS for the purpose of claim values, need to permit access to certain LDAP attributes, in the adjacent domains, to the AD FS service account.
To put this into perspective, let’s look at a couple of examples.
Example 1: two single-domain forests
In this example there are two AD forests, each housing one domain. The OS level is pretty irrelevant to AD FS but I include it for completeness and to permit a forest trust (not strictly true, but I like to use Kerberos wherever possible).
AD FS is installed in infra.adatum.com and the majority of the user population resides in users.adatum.com. Service accounts are considered infrastructure therefore they reside in infra.adatum.com. Because the service account running the AD FS farm is a principal in infra.adatum.com a bidirectional trust is needed, as the service account performs attribute value lookups, using LDAP, in the users.adatum.com domain. If the service account belonged to the users.adatum.com domain a unidirectional trust between the domains (incoming in users.adatum.com, i.e. users.adatum.com users can authenticate in infra.adatum.com would suffice.)
Example 2: three AD DS forests
In this example there are three single-domain forests. AD FS is installed in the new corp.adatum.com forest and will originally be used for the purpose of internal claims-based authentication (AuthN), i.e. several ASP.NET applications have been migrated to use Windows Identity Framework (WIF) and require a CP to service authentication.
Bidirectional trusts are now mandatory as is the location of the service account. In this example the service account must exist in the corp.adatum.com domain which trusts, and is trusted by, each of the other domains.
Trust types
There’s no real dependency on trust type. Forest trusts or external trusts are valid. You just need to ensure that they’re bidirectional in most instances because of the need to do LDAP queries to build claim values.
Wrap-up
When considering internal authentication to the CP (STS) in almost all circumstances the default behaviour of Integrated Windows Authentication will be used.
In a forest with multiple domains there is nothing to configure or do because of the implicit bidirectional transitive trusts in place. Users will be able to authenticate to the AD FS web service and the AD FS service account will be able to read LDAP attribute values (unless you’ve hardened your AD DS ACLs).
In an environment that consists of more than one forest there is a requirement for AD DS trusts if you don’t want to implement multiple AD FS instances and federate them. In this case external or forests trusts will work. In most cases you will require bidirectional trusts. There are only a small number of cases whereby you can enable everything to work with a unidirectional trust.
There is no dependency on the AD DS domain or forest functional levels or schema. If you want proof of this look to the MSIT case study – Microsoft have 15 domains in 4 forests running, at some point in time, a rather mixed mode environment in terms of AD versions and have a very busy AD FS implementation –one instance, servicing everything.
