The Unfixable Outlook Prompts with AD FS Fixed

Microsoft AD FS is a standards-based service that allows the secure sharing of identity information between trusted business partners (known as a federation) across an extranet. It works great with Microsoft operating systems but there are a few configuration requirements to make it actually single sign on. This blog is about when the requirements look right, but users still get the annoying windows credential prompt.

Background

Microsoft AD FS is a great tool to federate with Office 365 since the service has been built into Windows Server since 2008 R2 and requires little more than a few lines of PowerShell to federate.

Prior to the pilot phase, Microsoft Active Directory Federation Services 2016 was installed in a four server high availability configuration. Two frontend Web Application Proxies and two Backend Federation servers with an F5 load balancing each service. During build the service name was added to the intranet zone in Internet Explorer to verify that SSO worked.

I had a customer having issues with their AD FS/Office 365 authentications for most of their Office 365 pilot users. There were getting the prompt for a windows authentication.

AD FS Configuration

I was not sure who did the AD FS configuration by the time I got the call, but the customer had already removed the F5 to rule the issue out. The DNS was pointing at the primary AD FS server and nothing had changed. One of the users didn’t have any issues but the person right next to him had an issue.

First thing I looked at was Internet Explorer’s setting to make sure the AD FS service name was in the local intranet zone, which it was (adfs.b-carter.com).

Next was to look at the WIASupportedUserAgents configuration on the AD FS server.

Get-ADFSProperties | Select -ExpandProperty 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
MS_WorkFoldersClient
=~Windows\s*NT.*Edge

Everything looks great for a default configuration.
Users were running a mixture of Windows 7 and Windows 10, all using Internet Explorer so I was still stumped.

Troubleshooting

Since the AD FS configuration looked fine, it was back to a user’s computer which was having issues. The computer I looked at was Windows 7 with the latest patches and adfs.b-carter.com in the intranet zone already.

We added Chrome and Firefox to the allowed browser agents by running:

Set-AdfsProperties -WIASupportedUserAgents ((Get-AdfsProperties | Select -ExpandProperty WIASupportedUserAgents) + "Mozilla/5.0 (Windows NT")

Chrome still did not work which isn’t surprising since it uses IE’s configuration when running.

We conifgured Firefox to pass NTLM authentication by going to:

about:config
network.automatic-ntlm-auth.trusted-uris
Entering: https://adfs.b-carter.com

Returning to AD FS, users was able to SSO into O365 and AD FS with Firefox. That narrowed it down to a bad IE configuration.

Checking the Group Policy Objects there wasn’t one that added adfs.b-carter.com to the local intranet zone. After talking it through I did eventually find out there was an old GPO added that allowed many Microsoft domains for O365.

Sure enough, there was a Group Policy Object that had adfs.b-carter.com as a registry key which was no longer linked to any OUs. At one time it was linked, but I didn’t know when and where it was linked so I assume all machines have the configuration. They used a Group Policy Preference to add the adfs.b-carter.com domain to the registry so that users could still add other domains to their local intranet zone as needed. Using GPP’s doesn’t lock down the zone and is a nice way to add the domains wanted while still being flexible to unknown other domains.

The only problem is that it was not configured correctly and my assumption was that this is causing the headaches.

The GPO in question looked this this

Wrong-GRO

To the eye it looks correct since it will show up in IE looking like adfs.b-carter.com and you can call the job complete. Unfortunately, that GPO is configured wrong.

When adding a subdomain to the ZoneMap you have to be very careful and get the registry setting correct. Looking at the registry with the current configuration, it was now very obvious that the key was added wrong and was the culprit.

Registry key’s for the Intranet Zone is located at:

HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap\Domains

Wrong-ZoneMap

Notice how the entire domain is listed in Key, it should only have the domain and a subkey with the adfs name.

Once that key was deleted from the registry and the domain was typed correctly into IE, all was working as expected with AD FS and O365 authentications.

Correct-ZoneMap

Manually typing the domain in Internet Explorer will create the key properly and should be used as a reference when creating a GPO/GPP with registry keys.

Solution

Since it was determined that a bad registry key was causing the issue it was now time to fix it. It was decided to use a User Group Policy Object/Preference to fix the keys.

Step 1 - Remove the bad key from all computers

New -> Registry Item

Remove-RegKey

  • Action: Delete
  • Hive: HKEY_CURRENT_USER
  • Key Path: Software\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap\Domains\adfs.b-carter.com
  • Value name: Blank

Step 2 - Add the correct key to all computers

New -> Registry Item

Add-RegKey

  • Action: Update
  • Hive: HKEY_CURRENT_USER
  • Key Path: Software\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap\Domains\b-carter.com\adfs
  • Value Name: *
  • Value Type: REG_DWORD
  • Value data: 00000001
  • Base: Hexadecimal

Alternatively a login script with a .reg key could do the same thing, but we didn’t want to add any scripts into the environment.

This fixed the issue for all users and the Office 365 rollout was able to finally move forward.