When you sign up a new Office 365 tenant a Global Admin account is created for you. This Global Admin account, and any other admin accounts you create later on, are highly privileged, powerful accounts that need to be protected from compromise.
Protecting the accounts with a strong password that is safely stored in a database such as 1Password or LastPass is one step towards securing them. But you can protect them further by enabling multi-factor authentication (MFA), which is also sometimes referred to as two-step or two-factor authentication (2FA). Multi-factor authentication requires a person to know the account's username, password, and also enter a unique, one-time code in order to log on. That one-time code is provided via phone call, text message, or is generated by an app, and protects the account from unauthorized use if the username and password are exposed. Aside from the security benefits, enabling MFA is also one of the recommendations in the Office 365 Secure Score report, and you'll get a nice 50 point bump to show your boss.
In this example I'll be using MFA for Office 365 to enable multi-factor authentication. For environments with AD FS deployed, Azure subscriptions, or Azure AD Premium plans, there's some additional MFA capabilities that organizations can consider as well.
Planning to Enable MFA for Office 365 Admins
Before you turn on MFA for your Office 365 administrator accounts, there's a few points that you need to be aware of. The first is that not all of the PowerShell connections for managing Office 365 support MFA yet. Right now the following PowerShell connections do support MFA:
- Azure AD/MSOnline module (latest versions)
- Azure AD V2 module
- Exchange Online Remote PowerShell module
- Security and Compliance Center (when connected via the EXO Remote PowerShell module using Connect-IPPSession)
- SharePoint Online module
- Skype for Business Online
The following remote PowerShell connections do not support MFA:
- Exchange Online (the PowerShell remoting method, not the EXO Remote PowerShell module mentioned above)
- Azure RMS module (unless using an app password)
- Security and Compliance Center (the PowerShell remoting method)
All of the web-based portals for the various services support MFA of course.
The login process for MFA-enabled accounts is also often not suitable for automated processes, even when they're using PowerShell connections that do support MFA, because they can't interact with the MFA prompt and enter the one-time code that is required for login. App passwords, which are effectively an MFA-bypass, can solve the issue in some cases. But even when the app password is strong and securely stored, the use of app passwords undermines the security goal of requiring MFA in the first place.
Another solution is to use low-privilege accounts for automated processes. For example, if you have a scheduled task that runs a script to check Exchange Online mailboxes for compliance with your organization's requirements for auditing and litigation holds, that task can run using credentials for an account that has been granted the minimum requirement permissions in Exchange (using RBAC), instead of an excessively privileged Global Admin account.
In cases where a low-privilege account can't be used, you can maintain an admin account that doesn't have MFA-enabled, but keep the account disabled so that it can't be used to login. At the times when the account is required for a specific task, you can either:
- enable the account temporarily, and disable it again when not in use.
- use Azure Privileged Identity Management (requires Azure AD Premium P2) to enforce MFA when temporarily grant the required permissions, which is a topic for another blog post in future.
Preparing an Office 365 Tenant for Multi-Factor Authentication
You can enable MFA for a Global Admin account and use that account to login to the Office 365 admin portal, however there are some additional steps required to make sure that Exchange Online and Skype for Business Online are enabled for modern authentication for client connections.
For Exchange Online, connect to your tenant using PowerShell, and run the following command:
PS C:\> Set-OrganizationConfig -OAuth2ClientProfileEnabled $true
For Skype for Business Online, connect to your tenant using PowerShell, and run the following command:
PS C:\> Set-CsOAuthConfiguration -ClientAdalAuthOverride Allowed
Enabling Multi-Factor Authentication
To enable multi-factor authentication for your admin accounts, log in to the Office 365 admin portal and navigate to Users and then Active users. From the More menu, choose Setup Azure mult-factor auth.
Change the view to Global administrators to list the global admin accounts for your tenant. Check the box for the admin account that you are enabling MFA for, then click the Enable link.
There's some reading that Microsoft suggests for planning a deployment of MFA in your Office 365 tenant. Some of the guidance is aimed more at deploying MFA for your end users. It's a useful read if you're brand new to this topic. Otherwise, just continue enabling MFA for the account.
Completing the MFA Setup for an Account
After MFA has been enabled, the next time you log in to an Office 365 portal with the admin account you'll be prompted to set up the additional authentication mechanism.
The options include a phone call, text message, or application-generated code.
To keep things simple I've chosen the text message option, and filled in my mobile phone number.
A verification code is sent to the mobile device, and after you enter it to confirm you are the owner of the mobile phone number the the MFA setup process is complete.
At the final stage there is a randomly generated app password displayed. This password can be used to login to some services that do not support MFA (examples were provided above). For end users the app password can be used for legacy clients that don't support MFA. If you lose the app password or forget to record it, you can generate a new one in your Office 365 account settings and delete the old one (which can't be retrieved).