Customising the ADFS 3.0 / 4.0 Home Realm Discovery (HRD) screen
This is for ADFS 3.0 (Server 2012 R2) and ADFS 4.0 (Server 2016).
HRD is the process whereby a system can have multiple Identity Providers (IDP) and the user has to select one to authenticate. At this point, the user has not logged in and so there is no user context to guide this decision.
The “problem” is that companies often want to hide this page.
Note that this is not an ADFS specific issue.
All Identity Providers (IDP) e.g. Ping, OpenAM, Okta, Auth0 have similar issues because this is how federation works.
Each IDP will have their own HRD screen.
You can chain the HRD screens together e.g. select IDP B from IDP A’s HRD screen and then IDP C from IDP B’s HRD screen.
The root cause of the “problem” is that you have to select the IDP before you authenticate.
Branding
The look-and-feel can be customised.
More information here.
Names of the IDP’s
Anything other than the “Active Directory” entry is easy to change since it is configured when you add the IDP.
The name “Active Directory” is hard-coded in the JavaScript behind the HRD page. This can be changed.
Cookies
By default, ADFS remembers the HRD choice for 30 days.
This means that the user will only have to choose once.
For the next 30 days, they won’t see the HRD screen.
You can alter the 30 day period or remove the functionality altogether.
Testers will have to clear cookies if they want to see all options.
The command is:
Set-AdfsWebConfig -HRDCookieLifetime 90
This sets the lifetime to 90 days.
IDP customisation
There are three ways to customise this screen in terms of IDP requirements.
- Configure via email suffixes
If you want to federate with Fabrikam.com and all the Fabrikam users’ logon with the same domain e.g. joe@fabrikam.com then you can configure ADFS to enter an organisational account which automatically selects the domain.
This displays an “Other organisation” link.
If you click “Other organisation”, you’ll be asked to enter your organisational account.
Entering e.g. joe@fabrikam.com takes you to the Fabrikam IDP.
If you added contoso.com, joe@contoso.com takes you to the Contoso IDP.
The command is:
Set-AdfsClaimsProviderTrust -TargetName fabrikam -OrganizationalAccountSuffix @("fabrikam.com";"contoso.com")
2. Configure via Relying Party (RP)
A RP is an application e.g. Salesforce.
You can map a RP to an IDP.
e.g. all users of RP A will use the Fabrikam IDP to authenticate.
The command is:
Set-AdfsRelyingPartyTrust -TargetName "RP A" -ClaimsProviderName @("Fabrikam","Active Directory")
3. Configure via intranet user
This turns off HRD for intranet users e.g. internal company employees.
All intranet users will use the internal ADFS to authenticate.
The command is:
Set-AdfsProperties -IntranetUseLocalClaimsProvider $true
Other options
Assume you have an internal and external ADFS. There is an external application used by both customers and employees. This implies that navigating to the application invokes the HRD screen.
What options are there to remove this?
- Copying the internal users to the external AD
This just removes one IDP.
With other providers added, you have the same HRD problem.
Also, you lose SSO for internal users.
2. Only having one ADFS
The internal and external AD’s may be different versions.
With other providers added, you have the same HRD problem.
Combing internal and external uses is not best security practice.
3. Multiple ADFS farms
You have can have multiple ADFS farms in a single domain sharing the same AD instance.
You could group the external providers by function in terms of their login requirements and group similar IDP in one farm.
This would reduce the number of IDP that the user would see but it doesn’t scale.
With WAP and HA, this would result in a large number of servers.
4. Adding the IDP to the authenticate URL
For RP that use WS-Federation, you can add “wtrealm=IDP” to the URL.
This automatically redirects to the IDP.
For SAML, there is a parameter called relayState that does much the same thing but it is only applicable to the IDPInitiated flow.
There is no such parameter for OpenID Connect.
5. Customise the HRD JavaScript
This can’t be customised for the user context e.g. you don’t know who or where they are.
Here are some examples of what you can do:
