Active Directory Federation Services (AD FS) 2.0 and multiple AD DS forests

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.

Advertisements

About Paul Williams

IT consultant working for Microsoft specialising in Identity Management and Directory Services.
This entry was posted in AD FS and tagged , , , , , . Bookmark the permalink.

10 Responses to Active Directory Federation Services (AD FS) 2.0 and multiple AD DS forests

  1. Thanks for great article. Do you know any resources covering AD FS 2.0 deployment trusting multiple different Active Directory Windows Server 2008?

    Regards,

    -T.s

    • I’m afraid I can’t think of anything that specifically addresses your ask. For the most part “it just works”. A couple of issues/constraints are covered above -two way trusts will be required in most topologies and in high-secure environments you might need to actually grant permissions as the defaults might have been taken away. The AD topology is reasonably irrelevant to the FS. You present a set of credentials (usually a service ticket, in some cases you’ll be doing an NTLM handshake) and then the FS starts doing its bit. The AD topology is all the “stuff” that happens before the FS starts doing its business.

      You might find more information in the old ADFS 1.x documentation. In ADFS 1.x there was a design topology called the Federated Web SSO with Forest Trust design. This is documented here: http://technet.microsoft.com/en-us/library/cc787592(WS.10).aspx.

      There are going to be some differences but hopefully there’ll be some worthwhile information in there. Just remember that the NT token-based web agent is a thing of the past (and is only in Windows Server 2012 for backward compatibility with ADFS 1.x implementations).

  2. Vijay says:

    Paul,
    Awesome write up. I have a quick question about this topic in general. Our environment is like this: ADFS is hosted on our company’s servers. We are using forms authentication in ADFS. As we keep getting new clients, their active directory domains will be added as trusted claims provider in our ADFS server. We will be using the clients active directory domains as an identity provider only. We are going to bypass the home realm discovery page and go to the FormsLogin.aspx page of OUR ADFS server so that all our clients see a single login page and are not redirected to some other login page.
    If we require that our clients install ADFS on their servers, is my scenario easy doable? I hope I am explaining myself clearly.

    • Avinash says:

      Due to some urgent requirement, I am planning to Deploy ADFS. I have a very basic question. Does ADFS requires creation of Active Directory Trust?

      • That depends on what you want to do. If you have multiple AD DS forests and you want users from these forests to access a claims-based application using SAML tokens issued by AD FS then yes, AD DS trusts will facilitate this. You can deploy one FS and as long as the direction of the trusts supports users authenticating to the FS and the FS account querying the home AD DS domain then this will work without any other configuration.

    • I’m not totally sure I follow. If you want to use the AD DS credentials of each of these clients then you simply create trusts as described in the post above. You cannot create CP trusts to other domains. The implicit CP trust will suffice as long as the AD DS trusts are in place.

      If each of your clients implement their own FS then these can be added as CP trusts and your FS as an RP trust on their side. In this case their forms based logon page will be used from the Internet. They can reconfigure their FS to use FBA over IWA too. You do then introduce the home realm discovery (HRD) issue. To get around this you’ll need to utilise the WHR query string/parameter in the URLs.

      If you want your clients to use your FBA page then there needs to be AD DS trust.

  3. Hi Paul,

    I actually configured a scenario like in Example 1 where ADFS 2.0 service account is declared in infra.adatum.com domain and there is only an unidirectional trust between infra and users domains : infra domain trusts users domain. Yet, the configuration works : users accounts from users domain manage to authenticate through ADFS. So I think that the bi-directional trust is not a prerequisite…
    Have you also tested this configuration ?

    • Hi Fabrice,

      A unidirectional trust works assuming the service account can read the AD that the users reside in, which generally means the service account exists in the user domain:

      “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.”

      In my case my original lab was what prompted the post in the first place, i.e. where does the service account reside in a multi-domain environment.

      If your users are authenticating to your FS over a one-way trust then two things spring to mind:

      1. It’s actually a two-way trust; or
      2. Anonymous LDAP reads are enabled

      The FS queries the domain that the user exists in to get UPN, group membership, etc. This query cannot happen with a one-way trust and the default settings.

  4. HI Paul,
    I am trying to setup ADFS that needs to validate users from two different ADs. ADFS is connected to AD One, and I had set up a two way realm trust relationship between the two ADs (AD one and AD two). I created a claim aware asp.net application, but ADFS is not allowing users from AD two to log in, whereas it allows users from AD one. Could you please throw light on what is missing…

    • Sounds like the AD FS service account cannot lookup the required claims in the second domain. Look to the event log and also see if you can bind to the second domain and issue a similar query using the service account and LDP.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s