Fotolia
Switch authentication modes during a disaster recovery
Converting authentication modes is a rare thing admins need to address, but it must be fixed right away when it happens -- and Microsoft's documentation on it is incorrect.
Office 365 is often far simpler to manage than an on-premises infrastructure, and it has more capabilities than other cloud-based productivity services. But it can be complicated at times, and identity and login can require a lot of infrastructure for the most advanced scenarios.
The most complex on-premises deployments often use Active Directory Federation Services (AD FS) in combination with DirSync or Azure AD Sync Services. When AD FS is deployed for Office 365 and configured, end users need the on-premises AD FS infrastructure to access cloud services. At a minimum, this often requires two AD FS servers, and, to publish AD FS to the Internet, two Web Application Proxy servers.
Both services often require load balancing and multi-site availability. It isn't uncommon for an organization to use geo-load balancers to ensure availability of the AD FS service or place AD FS services in Azure IaaS.
Small organizations or organizations with simple requirements don't usually need AD FS and can instead switch on the Password hash sync functionality in DirSync and Azure AD Sync Services. This copies the hash of the AD password to Azure AD and Office 365, allowing end users to log in using the same password. Password changes are near instant as the process to push password changes to the cloud isn't based on the same three hour schedule DirSync uses.
AD FS is a critical component of Office 365, so it's important for admins to understand how a failure will affect their organization's authentication modes and the process to recover in the event of a failure. Organizations using AD FS may opt to leave DirSync Password hash sync enabled in the background as a backup to use in the event of a major disaster, allowing a quick switch from AD FS and potentially avoiding the need for multi-site resilience.
Microsoft supports this as a disaster recovery option and we'll see how this works in the real world. This is a rare thing admins need to address, but it should immediately be fixed when it does. Microsoft's documentation on this kind of thing happening isn't quite correct, so this should be an admin's definitive guide on it, including how to cover massive gaps.
When disaster strikes
Having Password hash sync enabled when admins install DirSync or Azure AD Sync will ensure that the hashes or passwords are copied to Office 365 in advance of any disaster. This makes no difference to the day-to-day usage because AD FS will continue to process logins if a domain is federated. The copied passwords won't be used.
However, when there's a major outage and AD or AD FS is unavailable, admins will want to provide access to the services Office 365 offers to facilitate communication while the systems are restored.
Typically, if admins currently use AD FS, they use it for a reason; a switch to Password hash sync will only be a temporary answer for your organization's authentication modes until the infrastructure is brought online. In the event of a disaster, admins need to install the correct tools to access Office 365 and Azure AD and then switch each Federated Domain to a managed domain.
Convert to use Password Sync
We'll begin by attempting to access Office 365 when AD FS is unavailable. Once redirected to the AD FS server (usually sts.yourdomain.com), you see the page cannot be displayed (Figure 1).
Upon further investigation, we find out there's been a major outage. It's time to start recovering services. Assuming we have no access to the infrastructure, our first step is to download the components necessary to manage Azure AD using PowerShell, the Online Services Sign-In Assistant and the Azure AD Module for PowerShell.
Download the sign-in assistant from the Microsoft Download Center. To download the Azure AD Module for PowerShell, access the Office 365 portal with an administrative account that doesn't use a Federated Domain; if admins don't have one, they need one.
After login, navigate to Users Active Users. Within single sign-on, choose Manage and then download the Azure AD Module for PowerShell (Figure 2).
After downloading these, first install the Sign-In Assistant and then install the Azure AD Module for PowerShell.
We'll then use the Azure AD Module for PowerShell to switch our Federated Domain to a Managed Domain. A managed domain is one where Office 365 and Azure AD manages passwords. Know that Microsoft's guidance on dealing with this scenario is flawed. This TechNet article provides commands that expect the AD FS server to be online during the switch. Following Microsoft's instructions results in failure (Figure 3).
Instead, we'll use the Set-MSOLDomainAuthentication cmdlet to switch authentication modes without the requirement for the AD FS server to be online:
| Connect-MSOLService Set-MSOLDomainAuthentication -DomainName <domain.com> -Authentication Managed |
Admins will then see a set of commands (Figure 4).
After making the switch, wait a couple of minutes for the changes to propagate before attempting to access Office 365 again. Admins should be redirected to a standard managed Office 365 login page (and be able to log in using the same username and password used with AD FS) (Figure 5).
Clients who make major use of single sign-on, such as those using a browser or Modern Authentication, will be most affected. Most current Outlook and Lync clients will see little to no change.
Recover and switch back to AD FS
After the AD FS services have been either restored or reinstalled, we must switch back to Federated login. From the recovered AD FS primary server, execute the following commands to switch back to Federated login. This should result in a clean update with no errors (Figure 6).
| Connect-MSOLService Convert-MSOLDomainToFederated -DomainName stevieg.org -SupportMultipleDomains |
About the author:
Steve Goodman is an Exchange MVP and works as a technical architect for one of the U.K.'s leading Microsoft Gold partners. Goodman has worked extensively with Microsoft Exchange since version 5.5 and with Office 365 since its origins in Exchange Labs and Live@EDU.
