Recently I have been working to establish Azure AD Connect in Azure, using the GA version of Azure AD Connect. This should be a straight forward, but I encountered some glitches and errors…. This article might help others facing the same issues a faster way to success🙂 The following infrastructure was established:
- Site-2-Site VPN
- Separate subnet for Azure Services
- Azure added as a site in OnPrem AD Sites and Services
- Servers in Azure
- Active Directory Domain Controllers
- ADFS Servers
- WAP Servers
- AAD Server
Once all prereq was established, the installation and configurration of AAD Connect could be started. AAD Connect will install, when not using Express Mode, ADFS, ADFS Proxy and DirSync. Installation of AAD Connect was pretty straight forward and the configuration was nicely done, once all information was entered.
Required info was added, and the AAD Connect installation configured ADFS, ADFS Proxy and DirSync. Once installation was complete the DirSync service kicks off and started syncronizing useraccounts…
Error Message on Office 365 Logon:
“Sorry, but we’re having trouble signing you in and 80041034 error messages when a federated user tries to sign in to Office 365”
Bing or Google this error wasn’t giving me a solution to the problem so I went on digging into this. I read a bunch of articles and was about to go into completely removal of AAD Connect – Didn’t actually looking forward to this.
Relevant article at this stage:
Then I got into checking where the error occured, since ADFS actually is a 2-party infrastructure.
I asked my self the following questions:
- Is ADFS working ?
- If ADFS is working, does the connection to Office 365 work ?
First thing first – Validate ADFS functionality:
- Test ADFS logon only.
- Check the followin Url: https://”public name of ADFS”/adfs/ls/IdpInitiatedSignon.aspx
- Try logon with a account valid for ADFS logon.
- If logon is OK, then ADFS is OK.
Since ADFS SignOn worked OK – Over to next stage – Office 365 SignOn.
- Used “Microsoft Remote Connectivity Analyzer” – http://aka.ms/rca
- Test Office 365 Logon.
- Test failed with information about the token is missing information….
How is this possible, how can the token created by ADFS be missing information when ADFS logon works ?
– New Bing and Google sessions without any clear indication on how to recover from this error…
Getting back to ADFS again – something must be wrong, but WHAT ??
Found on article telling about “How to update or repair the settings of a federated domain in Office 365”
Down in this article I found a “Warning” – This might be interesting..
- Run the steps in the “How to update the federated domain configuration” section earlier in this article to make sure that the update-MSOLFederatedDomain cmdlet finished successfully.
- If the cmdlet did not finish successfully, do not continue with this procedure. Instead, see the “Known issues that you may encounter when you update or repair a federated domain” section later in this article to troubleshoot the issue.
- If the cmdlet finishes successfully, leave the Command Prompt window open for later use.
- Log on to the AD FS server. To do this, click Start, point to All Programs, point to Administrative Tools, and then click AD FS (2.0) Management.
- In the left navigation pane, click AD FS (2.0), click Trust Relationships, and then click Relying Party Trusts.
- In the rightmost pane, delete the Microsoft Office 365 Identity Platform entry.
- In the Windows PowerShell window that you opened in step 1, re-create the deleted trust object. To do this, run the following command, and then press Enter:
Update-MSOLFederatedDomain -DomainName <Federated Domain Name>
Update-MSOLFederatedDomain –DomainName:<Federated Domain Name> –supportmultipledomains
Using the –supportmultipledomains switch is required when multiple top-level domains are federated by using the same AD FS federation service.
After these routines was done – I managed to successfully Authenticate towards Office 365, using ADFS in Azure..