“Isn’t PIM enough?”
In the on-premises world, most organizations separate regular ‘user’ accounts from Microsoft 365 administrator accounts. This means that an IT administrator has at least two different accounts: one that’s used for day-to-day office work (including signing into their personal workstation) and another for administrative tasks performed on servers or in Active Directory.
When these on-premises organizations eventually migrate to the cloud, I’ve observed many instances where admins will shift to one, combined account. Often when I’m discussing this subject with customers, I hear pushback around why separate accounts are still required, to the tune of “If Privileged Identity Management is in place, why do we need separate accounts? By default, the accounts don’t have any permissions, they only become active when a user activates the PIM role.” While this is certainly a valid statement, there are remaining security concerns which necessitate the operation of separate accounts, and the fact is many organizations without PIM aren’t separating user and administrator accounts like they should.
In this article, I explain the importance of using separate accounts, detail how to target different Conditional Access policies for admin and user accounts (thereby limiting the attack surface for a potential “Pass-the-PRT attack”), and highlight how this approach can increase your security posture and limit potential attack vectors against Microsoft 365 administrator accounts.
Phishing is the number one way for an attacker to breach a user account. Whether it’s a phishing attack through email or a potential malicious Teams message, phishing attacks are omnipresent.
However, you can drastically decrease the chances of a phishing attack just by operating a separate admin account. Since that account doesn’t need a license attached to the account and doesn’t have a mailbox or Teams, no phishing emails will be received by the account, therefore phishing emails can’t affect it.
If you still wish to receive emails which are meant for the admin account (such as Product Updates from Microsoft), you can configure an alternative email that will ensure emails are sent to your primary users’ inbox. As a best practice, use plus addressing for this email account to verify the source of the email.
By having two separate accounts, you can target different Conditional Access policies for your administrator accounts compared to your regular user accounts. While we can use Conditional Access to target administrator roles, this filter doesn’t provide us with enough granularity.
I like to implement a set of ‘basic admin Conditional Access policies’ which includes the following:
- Always prompt for Multifactor Authentication, with no exclusions.
- Disable Legacy Authentication. Microsoft will be turning off legacy authentication for Exchange Online starting October 2022, and it’s my recommendation to start implementing these controls beforehand to avoid a big bang.
- Only allow sign-ins from compliant devices (Intune devices which adhere to a compliance policy.)
- Only allow sign-ins from Windows & MacOS devices.
- Require a password change when the account has a risk associated with it.
While these policies are assignable to regular user accounts, they would cause a hindrance because the policies generate constant MFA prompts and only permit logins from a limited subset of devices. By having separate accounts, you can configure strict Conditional Access for your administrator accounts, without hindering regular user accounts.
The same approach is viable for other security policies such as the allowed authentication methods and password policies since these policies are scoped to user accounts. If you require additional controls for user accounts with an administrator role, you must use separate accounts. By using separate accounts, you ensure that specific security policies can be scoped to only the administrator accounts.
For example, let’s look at authentication methods. Within Azure AD, you can enable or disable certain authentication methods for users. The options range from security key (FIDO2) sign-in to passwordless authentication using SMS, but the latter is probably something you don’t want on your administrator accounts. By having separate accounts, you can have different policies for administrators without impacting regular user accounts.
While a Pass-the-hash attack is a well-known attack vector, a Pass-the-PRT attack might be new to you. PRT stands for Primary Refresh Token, and it provides Single Sign-On access from a device to Azure AD. The PRT contains your authentication token which is used to log into Azure AD. If you log in to your device with MFA, the PRT also contains a valid MFA claim. If somebody seizes your PRT, they can log into your Azure AD account without needing a password or MFA.
Researchers have created many proof-of-concepts recently to demonstrate the viability of such an attack, as referenced in this blog from Dr Nestori Syynimaa. Because a PRT already resides on a device when a user logs in, every device an administrator logs in to is vulnerable. If you are a regular office user, you might log in from many devices: mobile devices, a browser in an internet café, or the computer of a friend. Each time you login, your PRT becomes vulnerable for extraction.
It’s important to protect PRTs, especially those for administrator accounts, and you need to ensure the PRT for administrator accounts cannot be extracted by a malicious third party. By using controls such as Conditional Access and Credential Guard, you limit the attack surface and protect the PRT of your administrators.
If you’ve combined user and administrator accounts, the PRT can easily be used to pivot to administrator portals and attack your organization. By having separate accounts, however, you have additional defenses for your Microsoft 365 administrator accounts to harden cloud security for your organization.
As a best practice, administrator accounts should never be synchronized from an on-premises Active Directory infrastructure by using Azure AD Connect. Administrator accounts should be cloud-only (created in Azure Active Directory) to ensure these accounts don’t have an on-premises footprint and can’t be used to laterally move between the on-premises network and Azure AD – which is how attackers used this vector in the NOBELIUM attack.
With separate accounts you can still synchronize administrator’s user accounts, which means they can use the same passwords to log in to the on-premises domain and Microsoft 365. Just make sure you create the administrator account as cloud only.
If the on-premises domain is breached, an attacker can’t move laterally to a cloud administrator account. This can stop a potential attack dead in its tracks and provides an additional layer of protection.
While a lot of heated debate swirls around the need to separate administrator accounts – especially when controls such as Privileged Identity Management exist within an organization – I strongly believe in separating accounts used for day-to-day activity from permissioned administrator accounts, for the reasons I outlined in this article.
While this approach might seem a bit inconvenient for user-type activity and admin work, it will increase your security posture and limit potential attack vectors against administrator accounts, thereby preventing an even bigger inconvenience down the road.