My colleague David Ross has written a previous blog about configuring proxy server settings to allow Azure AD Sync (the previous name of Azure AD Connect) to use a proxy server.
Starting with version 184.108.40.206, Azure AD Connect has completely changed the configuration steps required to allow the Azure AD Connect configuration wizard and Sync. Engine to use a proxy.
I ran into a specific proxy failure scenario that I thought I’d share to provide further help.
My Azure AD Connect (v.220.127.116.11) installation reached the following failure at the end of the initial installation wizard:
The trace log just stated the following:
Apply Configuration Page: Failed to configure directory extension (True). Details: System.Management.Automation.CmdletInvocationException: user_realm_discovery_failed: User realm discovery failed —> Microsoft.IdentityManagement.PowerShell.ObjectModel.SynchronizationConfigurationValidationException: user_realm_discovery_failed: User realm discovery failed
In this environment, I had the following environmental components:
- The AAD Connect software was going to operate under a service account
- All Internet connectivity was through a proxy server which required authentication
- Windows Server 2012 R2 platform
- Two factor authentication was enabled for O365 Admin accounts
Previously, in order to get authentication working for O365, I set the proxy server settings in Internet Explorer. I tested browsing and it appeared fine. I also had to add the following URLs to the Internet Explorer’s ‘Trusted Sites’ to allow the new forms based authentication (which allowed the second factor to be entered) to work properly with the Azure AD connect wizard:
So even though my Internet proxy appeared to be working under my admin. account, and Office 365 was authenticating properly during the O365 ‘User Sign-In’ screen, I was still receiving a ‘User Realm Discovery’ error message at the end of the installation.
This is when I turned to online help and I found this Microsoft article on the way Azure AD Connect now handles proxy authentication. It can be found here and is by and large an excellent guide.
Following Microsoft’s guidance, I ran the following proxy connectivity command and verified my proxy server was not blocking my access:
Invoke-WebRequest -Uri https://adminwebservice.microsoftonline.com/ProvisioningService.svc
So that appeared to be fine and not causing my issue. Reading further, the guidance in the article had previously stated at the start that my ‘machine.config’ file had to be properly configured. When I re-read that, I wondered aloud “what file?”. Digging deeper into the guidance, I ran into this step.
It appears that Azure AD connect now uses Modern Authentication to connect to Office 365 during the final part of the configuration wizard, and that the ‘web.config’ file has to be modified with your proxy server settings for it to complete properly.
Since the environment here requires a proxy which requires authentication, I added the following to the end of the file:
All new required text are within the ‘<system.net>‘ flags. NOTE: The guidance from Microsoft states that the new code has to be ‘at the end of the file’, but be sure to place it BEFORE the text: ‘</configuration>’:
I saved the file, and then clicked ‘Retry’ button on my original ‘user realm discovery failure’ message (thankfully not having to attempt a completely new install of Azure AD connect) and the problem was resolved.
Hope this helps!