I don’t know why there aren’t any blog posts on ADFS across trusted forests on the Interwebs. I know people are aware of it (we use it at our firm for instance) but whenever it comes to cross forest lookups I only find mention of the new ADFS 4.0 feature of adding a new LDAP claims store as described here or here. That has its advantages in that you don’t need any trust between the forests but assuming you have trust in place there’s an easier method that works in older versions of ADFS too.
One comes across brief nod to this in posts that talk about the
AlternateLoginID feature such as this. But there the emphasis is on the
AlternateLoginID rather than cross lookup forests. Even on the help page for the Set-ADFSClaimsProviderTrust the -Lookupforests switch is mentioned as “specifies the forest DNS names that can be used to look up the
If you have multiple forests linked together in a trust (like my previous lab examples for instance) all you need to do then is specify the
AlternateLoginID to be something that is unique across both forests (UPN in my case) and give the names of the forests to
Here are my two claims provider trusts currently.
PS C:\> Get-AdfsClaimsProviderTrust | ft Name,Identifier
Active Directory AD AUTHORITY
Branch Office Users http://adfs.two.raxnet.com/adfs/services/trust
Branch Office is my trusted forest with its own ADFS server. I want to change things such as I can use the Active Directory claims provider itself to query the remote forest. All we need to do is run the following on the ADFS server:
Set-AdfsClaimsProviderTrust -TargetName "Active Directory" -AlternateLoginID userPrincipalName -LookupForests raxnet.com,two.raxnet.com
-LookupForests switch I specify all my forests (including the one where the ADFS server itself is). When running this cmdlet if you get an error about the LDAP Server being unavailable (I didn’t copy paste the error so I don’t have the exact text, sorry) and you see errors in the Event Logs along these lines “The Security System detected an authentication error for the server ldap/RELDC1.realm.county.contoso.com. The failure code from authentication protocol Kerberos was “The name or SID of the domain specified is inconsistent with the trust information for that domain. (0xc000019b)”” then check your name suffix routing. You might not expect anything wrong with your name suffix routing (I didn’t) but that is probably the culprit (if you Google for this error that’s all you come across anyways). In my case I had the UPN suffix raxnet.global in both domains and that was causing a conflict (expected) but because the UPN suffix matched one of the domains I think it was causing issues locating the DC of that domain and hence I was getting this error. I removed the conflicting UPN suffix and the cmdlet started working.
Above I am using the UPN as my
AlternateLoginID, but I can use any other attribute too as long as it is indexed and replicated to the Global Catalog (e.g. mail, employeeID).
Check out this blog post for a flowchart on the process followed when using
AlternateLoginID. One thing to bear in mind (quoting from that blog post): The AlternateLoginID lookup only occurs for the following scenarios:
- User signs in using AD FS form-based page (FBA)
- User on rich client application signs in against username & password endpoint
- User performs pre-authentication through Web Application Proxy (WAP)
- User updates the corporate account password with AD FS update password page
What this means is that if Windows Integrated Authentication fails for some reason and you get a prompt to enter the username password (not the Forms Based Page username password fields mind you) and you enter the
AlternateLoginID attribute & password correctly authentication will fail. But if you enter the
domain\sAmAccountname format and try to authenticate it will work. This is because when WIA fails and you type in the credentials manually it does not seem to be considered as WIA, nor is it FBA, and doesn’t fall under the 4 categories above and
AlternateLoginID does not get used.
Lastly, a cool side effect of using this way of cross-forest ADFS login is that the previous problem I mentioned of ADFS across forests not working with OWA & ECP goes away. :) I am not sure why, but now when I login to OWA from organization forest to resource forest, and then try to access ECP it works fine without any change to the claims.