Best practices for Office 365 Admin accounts

Administering Office 365 requires special consideration in order to ensure that your service is both manageable and secure. Optimal configuration requires a balance between security, usability, and availability, so all of these need to be considered when planning a strategy. However, the following is a general set of guidelines that can be applied to most deployments, whether they are federated or cloud only.

See here for more info on enabling MFA: https://cloudrun.co.uk/office365/office-365-enable-azure-mfa-for-global-admins-and-all-users/

• Create a limited number of cloud onmicrosoft.com admin accounts, with MFA enabled. These can be used in case ADFS is down
• Create a single ‘break glass’ account, which is a synced AD account, no license and a Global Admin. Disable this account in AD. In case Azure MFA is ever down, enable the account and then you can get back in as an Admin without any MFA.
• In Azure Active Directory, create a new Conditional Access policy called: Require MFA for Admins (don’t use the baseline one). Apply this to all Admin type roles. Add an exception for your break glass account.
• Create secondary ‘Admin’ accounts for IT staff which are synced AD accounts, don’t assign normal user accounts admin roles. These can be used on a day to day basis for admin purposes, and you will have a full audit trail. Don’t create generic admin accounts.
• Set the password policy for cloud accounts so that it at least matches your on-premises password policy. Even if your domain is federated via ADFS, the password policy will apply to cloud only admin accounts. Note that you can only enforce password age and length, not complexity. If your on-premises policy is not particularly secure, set the policy to at least 10 characters long, and advise your admin users to use a mixture of capital and lower case letters, numbers and special characters. This won’t affect internal users, since the password policy is enforced by Active Directory.
• Don’t assign admin accounts a license. It is not generally required, and this will prevent a mailbox being created and the accounts appearing in the GAL, which could cause confusion. However, there are some instances where a license may be required for Exchange or Intune admin functions which can make this problematic, in which case assign a license only when required.
• Limited the number of Admin accounts, we generally recommend less than 5 in order to minimise attack surface.
• Use  the principle of ‘least privilege’, use roles other than global admin e.g. Exchange Online Administrator, or helpdesk administrator where possible.
• Review the Secure Score site periodically – https://securescore.office.com and try and get your score as high as possible.
• Have a separate admin account for scripting purposes, with no MFA but usually disabled. To do this set Sign In Status to Blocked, and only enable it when you need to run a script. Alternatively it is possible to use an MFA enabled account if you install the old PowerShell modules e.g. https://docs.microsoft.com/en-us/powershell/exchange/exchange-online/connect-to-exchange-online-powershell/mfa-connect-to-exchange-online-powershell?view=exchange-ps. There are limitations with this however, and you will have to enter 2FA credentials every time you run the script, credentials cannot be stored in a variable.

Note that these recommendations are line with NCSC/CESG guidelines:

Microsoft Office 365 Security Guidance: Administrator good practice https://www.gov.uk/government/publications/microsoft-office-365-security-guidance/microsoft-office-365-security-guidance-administrator-good-practice

Also see Security best practices for Office 365 https://support.office.com/en-gb/article/Security-best-practices-for-Office-365-9295e396-e53d-49b9-ae9b-0b5828cdedc3

Using this strategy has the following benefits:

• Avoids Admin users having to use 2FA to sign in to Office on their desktops, which can be especially annoying if you are using Shared Computer Activation. Although this could be avoided using a conditional access policy.
• It is more secure, the user is not signed in with a global admin account all the time.
• The admin accounts can be used to resolve any issues with ADFS, which can prevent internal users from signing in.
• Sometimes there may be no internal users who require admin access, if the tenant is managed by a third party. So using this strategy will work in any situation.

There are however drawbacks to this approach

1. In order to administer Office 365, IT staff will need to use InPrivate or incognito browser mode, and connect to Office 365 with their 2FA. This is an inconvenience.
2. The external accounts are available from the internet, which is not always the case with ADFS. This is mitigated through strong passwords and MFA.
3. You need to make sure that Admin accounts are disabled when users leave, this is often overlooked. This requires robust leavers process for IT staff.