Thursday, 22 November 2018

Mitigating Azure MFA issues during outages for Azure MFA, Azure Conditional Access and Azure MFA Server

Microsoft suffered a very unfortunate Azure Multi Factor Authentication issue on November 19th which affected thousands of their customers for many hours. In a world where MFA is a must, even if most tenants still don't use this fantastic feature, and the service breaks, how do we mitigate the service issue that we experienced?

Well the first thing to understand is what version of Azure MFA are you using? There's effectively 3 versions in Office 365 which provide additional features and functionality via licensing: Azure MFA, Azure MFA Premium - although this cannot be purchased anymore as of October 2018, and Azure Conditional Access which allows MFA in it's workflows. On top of this there's also Azure MFA Server, an on-premises product to contend with as well - which was also affected by the outage.

So in a future scenario where we could have another Azure MFA outage, what steps as an Administrator can we take to gain access to our tenancy as well as mitigate user sign-in issues?

Let's take a look..

So from a user perspective, and we're just using the standard Azure MFA solution here, they won't be able to sign-in as MFA will be enforced. If you have legacy Azure MFA Premium licenses in play still or have Azure AD Premium licensing you'll find you can add trusted locations under 'service settings'.



So we now have two options, providing the service is still honouring trusted locations, which on the November 18th outage it was, we can setup some additional locations like the IP address of the user that's working from home. Or we can temporarily disable the user. Once the outage has recovered we can then go back and enable them once more. Remember to select 'restore multi-factor authentication on all remembered devices' so they won't have to re-register their device which can cause employee confusion.



If the users are logging into Office 365 and we have utilised Azure Conditional Access to create an MFA workflow, then the legacy Azure MFA page as shown above will show the users as disabled for MFA - but they will very much be enabled. To get this information on who is enabled you will have to dig through Azure AD Powershell.

In regards to getting the users access to their services again will require you to relax the MFA workflow in the Azure Conditional Access rule set, or disabling the rule altogether until the outage is over.

To relax the MFA requirement search under | Access Controls | Require multi-factor authentication



To disable the conditional access rule simply toggle it to OFF under | Enable policy



So your users sign-in issues are now resolved, what about your administrators? The answer here will lie somewhere above depending if you simply use the standard Azure MFA management page or if you manage an MFA workflow through Azure Conditional Access - however I would expect you to have a seperate conditional access rule for your Administrators, VIPs, Finance Teams etc.

If you are in the position where you cannot actually login to your tenant at all to make the above changes then you should have an account that allows Global Administrator access to your tenancy where it's details are unknown and locked into your BCS process. I recommend the standard *.onmicrosoft.com account here. If you are utilising Azure Conditional Access ensure you have setup an exclusion policy - which is actually Microsoft best practice for this very reason.



This is especially important if you have Customer Lockbox enabled - as Microsoft won't be easily able to help you gain access to your tenancy!

So finally that leaves Azure MFA Server. In the scenario encountered on November 19th how can we mitigate sign-in issues when Azure MFA Server is in use and users are enabled through it?

Simply open the Multi-Factor Authentication Server console, select Users | User and we can disable MFA altogether if we so wish until we want it enabled once more.


We also can utilise Trusted IPs and skip MFA requirements for them - just like in the Azure MFA service. We must however configure the IP addresses in the Multi-Factor Authentication Server console. Select | User Portal | Trusted IPs | and enter them here.



However there are other ways still. We could simply enable 'one time bypass' so MFA is still enabled but the user when they try and login to Office 365 during the outage will not get prompted for MFA.

Ensure you have an account that is a Portal Administrator


Once the admin is logged into the User Portal they can simply find the user and initiate 'one time bypass' and a time in seconds it will stay active before turning off the bypass. 300 seconds is the default. The next time the user logs in, MFA is not required, and then subsequently enforced once more.

So is there any other ways? Yes - and one from the outage that it is worth ensuring you keep enabled. Ensure under | User Portal | Settings | Use security questions for fallback | is checked. This will allow a standard security question response in the event of Azure MFA failure.




Take care,
@OliverMoazzezi

No comments: