This post began as the couple issues I ran into the first time I ran through an ADFS deployment with Azure AD Connect. As months have gone by and I have done this over and over, I have hit an impressive amount of weird issues. Thus I am going to turn this post into more of a living document, where I dump issues that I come across when deploying ADFS with Azure AD Connect. Follow this link for my Step-by-Step Guide.
The other day I was presented with a new challenge at work; to set up ADFS (Active Directory Federation Services) for syncing an on-premises AD for a new customer with their new Office 365 tenant from scratch. Now I have done pieces of this process in the past, but I always had my “Obi-Wan” right behind me to correct me when I steered in the wrong direction. “Old Ben” essentially told me it’s time to be a big boy and do it all so that’s what I did…but I hit a couple speed bumps along the way. Do note this was all done on Server 2012R2, so it all pertains ADFS 3.0.
Issue #1: Cannot Add Web Application Proxy (WAP) during Azure AD Connect setup
My first issue occurred when I was configuring access to my WAP DMZ box. I had all my PS-Remoting/WinRM and DNS set up appropriately yet for some reason I could not authenticate to my WAP. Spoiler alert: this was a face palm moment. All in all I could enter a PSSession without issue via PowerShell, but the Azure ADConnect wizard (found here) would not establish the connection. Naturally I was flipping out how this doesn’t make sense since I literally had a PSSession open to the dang box at the time. Long story short, I was trying to use the hostname of the box only instead of the FQDN that its record in DNS has (hostname.domain.com). Even though the WAP box was a workgroup machine in the DMZ, the internal A record in DNS I created gave it an FQDN as if it were on the domain. DUH!
Issue #2: ‘ma-run-data’ was not found. Line 1, position 2. Error
After that hour of frustration was over I moved through the wizard without any issues and it began installing all of the necessary requirements on both machines. This generated an error because the service account was using for it to interface was an Enterprise Admin and not a Domain Admin. No problem, I added the account to the Domain Admins group and hit retry to be met with another error (would you just work already!). It kept failing with the error ‘ma-run-data’ was not found. Line 1, position 2. A few Google searches later I found the solution was to run a Full Import on my AD Connector. After this was done wa-lah no more error and installation completed successfully (Uncle Google credit found here).
Issue #3: User accounts not exporting with status “Connectors without flow updates”
Alas, this was not the end of my problems. Now that I had everything installed and configured, I naturally wanted to Sync an account up to Office 365 and apply a license to test everything right? Of course it didn’t work, why would it. When under the Connectors section of my Synchronization Service the account that I was attempting to Sync up was showing under the “Connectors without flow updates” section. This was a new one for me so I decided to dig into the Event Viewer logs to see if there was anything a little more enlightening. I found the root cause of my issue there…four fresh errors. I am just going to list the numbers here: 106, 108, 6801, 6803. The answer to all four of my errors came from just one part of 108: Error validating credentials. AADSTS50054: Old password is used for authentication. This took me down the hunting trail, I knew that it wasn’t my service account so it must have been the auto-generated account on the Office 365 side. I changed the password, updated the connector via the AD Sync Service and BAM! Problem solved.
That sums it up for the issues I had with my first time setting up ADFS from scratch by my lonesome. I did have some help with using Postfix to route the SSL Cert emails, but you can see this post about that one.
Updates Since Then:
Issue #4: Your credentials are not authorized to access Windows Azure Active Directory.
When setting up a new ADFS instance recently on Server 2016 with Azure AD Connect I ran into the following error after hitting the install option:
An error occurred executing Configure AAD Sync task: Unexpected exception thrown. Action: PingProvisioningServiceEndPoint, Exception: An error occurred. Error Code: 6. Error Description: Your credentials are not authorized to access Windows Azure Active Directory. Please check your administrator credentials and try again.
I did some googling and found this post which told me to run the following command on the ADFS box and give it a shot:
netsh winhttp import proxy source=ie
Issue #5: Export Status = stopped-extension-dll-exception
Got everything up and running on a new deployment and I noticed my users weren’t exporting. Ran to the Synchronization Service and came across the weird status you see below:
Came across this msdn blog post which made me reset the auto-generated synchronization user account password and wha-lah we’re fixed. Seemed like a familiar issue…(Cough issue #3 cough).
Issue #6: Error when attempting to establish a trust relationship
This one popped up on me and I felt like the biggest dummy of all time. I was really scratching my head on this one for a long time, but then I stumbled upon this technet post which made me look at the time and date on my WAP. Yeah…they were a day apart. Fixed that stupid issue and we were off to the races. Pro-tip, always double check the little things you take for granted on non-domain joined machines! #pool.ntp.org