We had been reluctant to advise customers to implement Active Directory Federation Services (ADFS) with Microsoft Office 365, due to the lack of a high-availability solution for ADFS.  With ADFS, users just have to log into their home domain.  When they attempt to log into Microsoft Office 365, the local AD is queried for a token to allow login.

It’s a great setup, since it provides “single sign-on” experience for end users (no extra user name and password combinations to remember) and allows IT Managers to continue use of Active Directory for security/policy enforcement.

The problem has been that if Microsoft Office 365 queries the ADFS server and fails to get a response, it stops and the user has no recourse for logging in.  While I’m convinced Microsoft will eventually address this shortcoming, what can be done in the mean time?  It’s true that a customer could set up redundant ADFS servers on its premises, but this seemed like an odd solution in the context of moving services to the cloud.

It turns out that it’s possible to implement ADFS in a Microsoft Azure (and, some report, an Amazon Web Services) environment.  Implementing ADFS in Azure means that you can create multiple layers of redundancy.  You can set up redundant ADFS servers, redundant racks, redundant data centers… you get the idea.  With Azure, the coordination of multiple servers (or racks or…) is handled higher up in the stack.  So you don’t have to perform a “warm standby” to keep ADFS running and users happy and productive.

If you want more information on how to set up ADFS in a redundant configuration, here is a link to the TechNet article.  This may be a good solution for you.