I’m going to continue my recent look at securing your Office 365/Azure AD directory with a quick dive into using Conditional Access rules to protect your directory’s most prized asset – accounts with admin roles.
These are roles that can be used to accomplish admin tasks within your organisation’s Office 365/Azure AD and Azure estate and they are important because they are essentially the keys to the kingdom. While you should be looking to secure all your accounts because all your users probably have access to sensitive information, systems or services; admin accounts are the accounts that give their user access to your entire estate in one or two leaps. An attacker doesn’t need to worry about compromising your board’s accounts one at a time to look at emails if they can compromise an admin account to download everyone’s emails to PST and add a few interesting rules to your Exchange Online transport rules while they’re there too.
I’m going to talk later in this post about the right way to protect admin accounts using MFA, but first of all I want to talk about the two most common issues with admin permissions.
Two of the most common weaknesses I still see in both AD and Azure AD management are assigning admin rights to a user’s daily driver account, and assigning overly permissive privileges.
Don’t assign admin rights to daily driver accounts
If your organisation is guilty of this then putting a stop to it right now is easily one of the simplest ways to improve security. When I talk about a “daily driver account”, I’m talking about a person’s everyday user account that they log on to when they start work, that they use for their normal Internet use, talking to others on Teams or Slack, send and receive email from. The issue comes when a user needs an admin privilege to get a job done. Perhaps he’s part of the helpdesk team and you assign him the rights to reset passwords and clear MFA registrations in Azure AD. Perhaps she’s your Office 365 app specialist and she needs SharePoint or Exchange administrator rights to get the job done.
That’s fine… but don’t assign admin rights to their standard account. If their account is compromised via a webpage or email, this makes it utterly trivial for an attacker to exploit any admin permissions assigned to that account. Instead, create a separate admin account for each IT staff member and assign the rights to that account only.
Over-permissioning accounts
Also a common error, and one that’s somewhat down to Microsoft in the O365/Azure AD world. Consider my helpdesk admin and my Exchange Online admin from the last section. Clearly they need some kind of admin access to do their role, but they don’t need to be Global Administrators to accomplish their task. This allows them more permissions than they need to carry out their job and this presents several threats
- It raises the impact risk of any mistake they make – I can’t accidentally delete the Azure AD directory if I don’t have permission to do so.
- It again means that any hacker that compromises their admin account has wider scope to cause harm than they might otherwise have had.
- From a data protection / governance angle, personal data should be stored in such a way that allows you account for how it is used, and stored with integrity and confidentiality in mind. It’s hard to do that if everyone on your network can use admin rights they don’t need to view or alter customer data.
Protecting Admin accounts with MFA
In my recent article on Passwordless authentication I mentioned protecting user accounts with some form of MFA. This should obviously apply to administrative accounts and roles just as much as it does to normal users.
You can, of course create a group for your admin users, then assign a Conditional Access rule to that group that requires MFA when you sign in. I’ve seen that applied in several places, similar to the example below.
This will work of course, and as I’ve said before, if you’ve done this then you’re ahead of the far too many people who haven’t done even this much. But this approach has two disadvantages.
- You must remember to put admin users into the correct group, and you must trust your admin users not to remove themselves from that group. Still nobody makes mistakes and nobody gets fed up of using MFA right?
- MFA against cloud apps will secure portals but it requires you to stay on top of the changes Microsoft make to these portals, and most importantly of all, does not do enough to protect against access via PowerShell or the Graph API.
There is a better way: Secure admin roles rather than admin people
Microsoft allow you to create Conditional Access rules that secure roles rather than people or portals.
Administrative roles in Office 365/Azure AD are what drive your admins use of the Azure and Office 365 portals. They are also what drive use of the technologies such as Graph API and PowerShell that are used to build the portals. This means that any attempt to use a protected role with any method will go through your Conditional Access rules. Keep in mind that while I’ve spoken about Conditional Access rules purely as a way to enforce MFA, you can actually make several requirements mandatory for accessing sensitive roles or data if you use MFA.
This means that you do not need to remember to add each new admin user to a group; or worry that Fred has granted himself global admin rights on his personal account again; or that you don’t even know what I’m talking about when I mentioned Graph API earlier, let alone how to secure it.
You do need to check that a new role hasn’t been added to the list in Azure/Office 365, but then this only becomes a real risk if you assign this role to your admin users.
Consider the example rule Conditional Access rule below, which demonstrates securing Directory Roles rather than groups or individuals.
Here we have chosen to secure Directory Roles rather than users. This means that any use who has that role assigned to them will be managed by this Conditional Access rule each time they sign in. It doesn’t matter how they connect, and it doesn’t matter if they’re using the role or not. If they have the role assigned to their account at all, they will need to meet the login standards required by the Conditional Access rules you set.
We are using the role to allow login on any device platform, but only from a trusted location. We are also requiring the user complete a MFA challenge, and to use a device that is Hybrid Azure AD joined and compliant with our Intune MDM policies.
At this point we’re saying you must be using MFA, be on-site (this could include connecting via a VPN remember), and have a device that can be checked and managed by Azure AD. This is about as safe as it gets. Combine this with passwordless login to ensure the MFA process is as secure as possible and your admins will be working securely and with as little friction as possible when using MFA.
You could expand this further with the correct Azure AD P2 licences, and block logins to these roles from high risk user or sign-in scenarios. In fact, if you have P2 licences, I strongly suggest you do exactly that.
And yes, it is possible to lock yourself out with these rules if you’re not careful. Which is while we’ll cover Break-glass accounts in another post, and why you should use the report function and test very carefully before enabling this feature.
