We’ve come across some specific behaviours of AD FS Home Realm Discovery and Non-Claims Aware Relying Party Trusts we wanted to share as it’s something you might come up against in your deployments.
What are the Symptoms of the Issue?
If you create a Non-Claims Aware Relying Party Trust using PowerShell you will find that end users are not offered Home Realm Discovery. If you do want to federate authentication this will cause you an issue.
If you create a Non-Claims Aware Relying Party Trust using the AD FS Management Console, full Home Realm Discovery is offered to the end user. If your users are authenticating against local Active Directory this might cause some confusion and add an additional step to the authentication flow.
Let’s first cover off a couple of key concepts around this and then look in more detail about what is going on and why.
What is Home Realm Discovery?
By default, an AD FS server will have one Claims Provider Trust for the local Active Directory but, if you have federation partners or a central broker service, you will have added additional Claims Provider Trusts in AD FS. These are then available as alternate identity providers for user authentication.
Home Realm Discovery (HRD) is an AD FS feature where the end user gets to choose which Authentication Provider they want to authenticate against from the available Claims Provider Trusts e.g. users from a partner organization would choose their companies authentication server from the list. The user would then be directed to the relevant Identity Provider to authenticate.
A users Home Realm Discovery choice is then cached via a cookie so that they don’t have to go through the HRD selection each time they come to AD FS to authenticate.
What is a Non-Claims Aware Relying Party Trust?
A Non-Claims Aware relying party trust is a specific type of AD FS Relying Party used by Web Application Proxy to publish a web application that uses Windows Integrated Authentication.
After the user has authenticated with AD FS and obtained their Web Application Proxy authentication token, Web Application Proxy then carries out authentication delegation to the published server using Kerberos Constrained Delegation.
Please see the following article for more details on setting on and configuring a Non-Claims Aware relying party trust and the associated Kerberos Constrained Delegation requirements - http://technet.microsoft.com/en-us/library/dn280943.aspx
Selective Home Realm Discovery
For a standard Relying Party Trust AD FS provides a way to limit the Claims Provider Trusts that are used for that specific relying party. This can be very useful where you have multiple Claims Provider Trusts but have applications that will only be used and accessed by specific partners.
This can be set using PowerShell using the ClaimsProviderName property of a Relying Party Trust. Please see the ‘Configure an identity provider list per relying party’ section of the following article for details on how to configure this - http://technet.microsoft.com/en-us/library/dn280950.aspx
So, what’s the problem?
It’s not so much that there is a problem more that there are some specific design behaviours you need to be aware to give you the Home Realm Discovery behaviour that meets your needs.
- It is not possible to control the Claims Trust Providers for a Non-Claims Aware relying party trust
The first part of the issue to be aware of is that a Non-Claims Aware relying party trust does not provide the ability to control the Claims Provider Trusts used for the relying party as you can for a standard claims based Relying Party Trust. This is intentional and by design in AD FS Server 2012 R2.
- If you create a Non-Claims Aware relying party trust through PowerShell is will be restricted to the Active Directory Claims Provider Trust
For a Non-Claims aware application, as Web Application Proxy will be carrying out Kerberos Constrained Delegation (KCD) to the published server, this requires the user account to be available as a user identity in the local Active Directory. As such, the expectation was that the users would be authenticating against the local Active Directory.
This leads us on to the second part of the problem which is that if you create a Non-Claims Aware relying party trust via PowerShell then the relying party will get automatically restricted to the local Active Directory claims trust provider.
This means that Home Realm Discovery (HRD) will not be offered to users.
As there is only one Claims Provider Trust configured on the relying party, HRD will be skipped and the user taken to authenticate against the local Active Directory.
There are scenarios where you may be federating authentication from ADFS to a Centralised Authentication Broker or where you are federating out to a partner organization and using Shadow Accounts for the Kerberos Constrained Delegation. In these case you would want to authenticate against other Claims Provider Trusts and have these available as part of Home Realm Discovery.
- If you create a Non-Claims Aware relying party trust through the AD FS Management Console it will not be restricted by Claims Provider Trust
Conversely, if you create a Non-Claims Aware relying party through the AD FS Management console it will not have any Claims Provider Trust restrictions placed on it.
This means Home Realm Discovery will be offered to users with all available Claims Provider Trusts offered in the HRD list.
This is good if you do want to federate authentication but perhaps not so good if you are just authenticating users against local Active Directory and would like to eliminate the Home Realm Discovery steps for your Non-Claims Aware applications.
Note – it is not possible to have a subset of Claims Trust Providers displayed in the Home Realm Discovery for a Non-Claims Aware application
The good thing is that you have choices here and you can use either PowerShell or the AD FS Management Console to create a Non-Claims Aware relying party trust based on your needs.
This is something we’ve discussed with the AD FS Product Group and this is an area they will look at as part of their Server vNext development work.
Summary
If you are publishing Non-Claims Aware applications through Web Application Proxy you may find that the Home Realm Discovery behaviour of AD FS doesn’t meet your requirements.
There are some specific behaviours around the Claims Provider Trust restrictions and Home Realm Discovery to be aware of to ensure you get the behaviour you are looking for.
Use PowerShell to create the relying party if:-
- Your users will all authenticate against the local Active Directory
- You want to skip Home Realm Discovery for the relying party
Use the ADFS Management Console to create the relying party if:-
- You are federating authentication to other Identity Providers
- You want users to have Home Realm Discovery
Hopefully this will help save you some time and confusion around Claims Provider Trust restrictions and Home Realm Discovery behavior for Non-Claims Aware relying party trusts to help with your deployments.
Ian Parramore, Senior Escalation Engineer, Web Application Proxy support team