There are a lot of different ways to tailor the login experience of Microsoft ADFS. Out of the box when you create a trust, the log in experience for the application is if you are “in-network” (in other words not going through the proxy and using the Internet Explorer browser), you will be subject to the Windows Integrated login, where the application will use the credentials of the logged in user. In the event that fails, the user will be prompted with the ugly Windows Login box. Yes, we all know the one.
When you are outside the network, you get the Microsoft ADFS forms based authentication page, all with your company logo and customized verbiage.
You have in network users that have corporate issued laptops and desktops that belong to them, and in network users that share a single workstation under a shared department user account. You want the users with the issued computers to get the integrated sign in experience, but at the same time want the users on the shared computers to identify themselves using the Forms Based Authentication.
Right there it is NOT possible to use the ADFS management global authentication policy options that determine forms-based versus windows-integrated sign on experiences.
What to do?
There are a lot of thoughts on the situation, and this is the one that I implemented in my organization that made the most sense. Microsoft consulting at the time did not necessarily agree with this approach, and they preferred the global route, or by pointing workstations that need forms based to the external proxy. I did not agree with that approach, so here is what I did.
- Leave the default global settings alone. We don’t want to break anything that is working.
- Think of a name for a custom user agent. In this example, lets use “CUSTOM”
- For Windows domain joined computers, create a Group Policy that sets the following registry key:
- HIVE: HKEY_CURRENT_USER
Key path Software\Microsoft\Windows\CurrentVersion\Internet Settings\5.0\User Agent\Post Platform
- NAME: CUSTOM
- TYPE: REG_SZ
- VALUE: IEAK
- HIVE: HKEY_CURRENT_USER
- You see in the above step that the name matches what our custom user string is. NOTE: DO NOT USE the Internet Explorer group policy option to change the user agent string. You need to use the registry key, as the option will break or cause issues with versions of SharePoint.
- Apply the policy to the computers(or users) that you WANT to log in using integrated authentication. In other words, exclude the shared computers, or the shared login accounts from this policy.
- If you do not have domain joined computers, or are using alternate browsers i.e. chrome, you will need to append the custom user agent string to those browsers. For example, Chrome can be done via command line startup. chrome.exe –user-agent “CUSTOM”
- On the primary ADFS server, run the following powershell command: Set-AdfsProperties -WIASupportedUserAgents @(“MSAuthHost/1.0/In-Domain”,”MSIPC”,”Windows Rights Management Client”,”CUSTOM”)
- This command is telling ADFS that you want only browsers with the user agent CUSTOM using windows integrated authentication. All others will use forms based.
Problem solved, without the need to invest in more servers or changing DNS settings. Users with the issued computers will get the integrated sign in experience, and at the same time users on the shared computers will be able to identify themselves using the Forms Based Authentication, and not the ugly Windows Integrated dialog box.
To restore the default settings for Windows Integrated Authentication in ADFS, run the following command on the primary ADFS server: Set-AdfsProperties -WIASupportedUserAgents @(“MSAuthHost/1.0/In-Domain”,”MSIE 6.0″,”MSIE 7.0″,”MSIE 8.0″,”MSIE 9.0″,”MSIE 10.0″,”Trident/7.0″,”MSIPC”,”Windows Rights Management Client”)