For organizations that deploy AD FS for single sign-on with Office 365, it is as critical of a component as their on-premises Active Directory. While you may have your mailboxes residing in Exchange Online in the cloud, if your on-premises AD FS is not available, users cannot authenticate to access their mailbox.
There are a number of ways to create a highly available environment, starting with multiple servers in a single datacenter, then spreading them across multiple datacenters and then possibly even extending your AD FS farm into Azure IaaS.
Another option, with zero added infrastructure costs, is to use the “Password Sync” feature of DirSync / AADSync as a disaster recovery option should your AD FS become unavailable.
I won’t get into all the details around what Password Sync is or how it works. At a high level, understand that it’s not a sync of a plain text password but rather a sync of the password hash with additional security imposed on that hash. For additional information, check out “How Password Sync Works“.
Enabling Password Sync is very straight-forward, it essentially consists of checking a box in the DirSync / AADSync configuration and then forcing an initial sync. Important to note here is that forcing a “full sync” of DirSync does not initiate a sync of passwords, the password sync process runs out-of-band. To force a sync, checkout the DirSync FAQ on this topic.
We take you through 10 best practices, considerations, and suggestions that can enrich your Microsoft Teams deployment and ensure both end-user adoption and engagement.
So a disaster has occurred and AD FS is unavailable; perhaps the AD FS farm itself has critical issues or possibly the Internet connectivity to the AD FS farm is experiencing an extended outage. I’ll stress here that this is should be a “disaster” scenario, this is not something you’re doing when you need to update the firmware on your load balancer.
Microsoft has provided guidance on the process to temporarily failover to synchronized passwords from AD FS. This guidance seems to have a critical flaw though as the instructions are dependent upon AD FS being available. If our AD FS farm is up and available, we’re probably not going through this exercise.
The Microsoft guidance says to use the “Convert-MsolDomainToStandard” cmdlet but as you can see below, you’ll receive an error if AD FS is not accessible.
The command you’ll need to use if AD FS is unavailable is:
Set-MsolDomainAuthentication -DomainName lab1.iwitl.com –Authentication Managed
As you can see below, I started out with my “lab1.iwitl.com” domain being configured as a Federated domain and then was able to successfully change it to a Managed domain.
At this point my users are able to successfully authenticate to Office 365 using their on-premises password that we’ve been syncing in the background.
Once AD FS is available again, it’s a matter of running the command below to convert the domain back to a Federated domain:
Convert-MsolDomainToFederated –DomainName lab1.iwitl.com
You may also want to run “Get-MsolFederationProperty” to check the status of the token-signing certificate as well as the usual AD FS health checks.
The Microsoft guidance states that the switchover can take up to two hours for the domain to convert from Federated to Managed. My experience has been that it takes nowhere near this long however I am working in a lab environment with a limited user count. That said, keep this in mind when making the decision to implement this disaster recovery option.
After switching over to Password Sync, you may find that it works just fine for you. If so, you can check out the “How To Switch From Single Sign-On To Password Sync” article for this process.
You may also want to check out my “DirSync Password Sync: Did You Know?” article as part of your decision making process.
Did you find this article helpful?
Leave a comment below or follow me on Twitter (@JoePalarchio) for additional posts and information on Office 365.