“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
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.
Security Policies
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.
Read More: Understanding How FIDO Makes Passwordless Authentication Possible
Pass-the-PRT Attacks
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.
Cloud Only
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.
Closing off
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.
Hi Thijs!
I tried to configure an alternative email or plus addressing for receive emails which are meant for the admin account but didnt’t work for me. Por example, when a user wish change/reset your password, a notification is send to admin. In my case, the admin account has not mailbox but it has configured an alternative email (primary users’ inbox smtp address). When I check de Message Trace, I saw the following error: “Error: 550 5.1.10 RESOLVER.ADR.RecipientNotFound; Recipient not found by SMTP address lookup
Can you help me?
Thanks!!
Hi Fernando
I have not run across this exact issue. Is it only for SSPR settings or are you having the issue for others as well?
Kind regards
Thijs
Hello
Great article and this is something we follow, having separate accounts for admin purposes.
Question on licensing the Admin accounts. MS docs read that all users participating in Conditional Access policies or PIM require a license. Would this also include admin accounts?
Thanks
Yes. If the accounts benefit from the CA policies (in other words, if CA policies process inbound connections to those accounts).
There has been a lot of discussion about this topic and no clear answer.
I have this tweet from Alex Simons (VP Identity at Microsoft) bookmarked.
https://twitter.com/Alex_A_Simons/status/1232741945190912000?t=jEPEWD2PUW0Bd-PGh1fIhA&s=19
While it’s not a legal statement, that is on what I state my recommended – uou don’t need AADP for admin accounts.
This is not an official statement however and you should check with your Microsoft account manager for an official answer.
I guess the idea of monty to combine PIM and the separate admin account is that Admins do not add their separate Admin Account via Win 10/11 Accounts Page and those accounts would IMHO be vulnerable to the Pass the PRT attack as well
Thanks for the article, this is a common topic of debate for me almost every time I design an identity and access management solution.
I am keen to know your opinion on Azure privileged roles in the same context. Say for example your Azure subscription owner, user access administrator, etc. or even any user with a privileged Azure role assignment.
Would you create that as a separate identity? and if so would you make that identity a cloud-only one or on-prem mastered ?
Hi Eiba
In general, I recommend every admin with at least write access to adhere to these principles.
For read, I would doubt it as some managers want read access but don’t necessarily want to hassle of an admin account. But from a pure security standpoint, a separate identity is required for each one.
Thanks for your reply, Thijs!
I share the same opinion too.
Thanks for the info. Good details around the PRT.
“ 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.”
PRT is only valid on an azure ad registered device isn’t it? So if you login to azure or any M365 services from a mobile device or a friends computer all you get is an access, refresh token from azure ad and not a PRT.
The PRT is active on a device which is registered with Azure AD, yes.
But you can use a PRT to craft an authentication (access) token and use that on other devices.
Fantastic article, thank you. Would like to clarify two points:
1. Where you mention plus addressing is this just a general consideration and unrelated to the alternative email suggestion?
2. Is it possible to ‘convert’ synced account (from AD) to ‘cloud only’?
Hi Matthew
Yes, plus addressing was just a general comment (it can be used independent of alternative email off course).
While you can convert synced accounts to cloud only, I wouldn’t recommend it in this case as the account still originates from the on-prem world.
For admin accounts, you want to avoid any connection to your on-prem environment.
So I would suggest to create the accounts as cloud only.
Kind regards
Thijs
Hi Thijs, thank you for your response, very helpful. Kind regards, Matthew.
If we converted synced accounts to cloud only what would the connection be to the on-prem world? If we converted the account (stop the sync which deletes the account and restore it) then rename the cloud account would there still be a connection?
This is an option. If you do, I would recommend the following:
– Reset the password of the account
– Verify the applications assigned to it.
After you have done that no connection should be active
Thjis – I totally agree with this article but PIM could be added here. PIM should be used for separate admin accounts as well. This would protect against PRT scenarios as you can require MFA on a PIM assignment activation.
Hi Monty
PIM is a really great and powerful product. But within the context of this blog (why you need separate admin accounts), it’s not really an argument.
Kind regards
Thijs