ADFS Trials and Tribulations

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.

Original Post:

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:

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:

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

 

The New User Script to Rule Them All

I have gone through many versions of this user creation script as time has gone by, and so far this particular one is really hitting the mark.  It doesn’t do everything, but it takes care of 98% of everything so that I don’t need to rely on my help desk always setting things up appropriately (yay for scripting making everything consistent!!).  Anywho, this version of the script will do the following with PowerShell: Create the AD account with all the properties I need and a random password, set the account to require password change, populate proxy address attribute on the account, create the user accounts “home” folder (doc redirect), share and set both ntfs and share permissions on the folder, create a DFS link for the “home” folder,  and add the account to necessary groups.

Phew that’s a mouthful.  Before I drop the code, there is one disclaimer.  The script will prompt for credentials at the beginning.  These credentials MUST be able to create/edit AD accounts, have administrator access to file server, and be delegated in DFS.  Also, PS-Remoting must be available on the File Server/Server that hosts ADFS as I invoke commands remotely, and these two servers need to be in your local machines WinRM Trusted Hosts list.

You can add more to the multi-array and reference it as needed (for example group names), this is just a more basic example of how to get things done.

Enjoy!