“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.

About the Author

Thijs Lecomte

Thijs is a passionate Modern Workplace Consultant. Born and raised in Belgium, he currently works at The Collective Consulting as a Senior Microsoft 365 Consultant where he focuses on Client Management, Security and Automation. In January 2021, Thijs was recognized with the MVP Award in the ‘Enterprise Mobility’ category. During his free time Thijs is active on the Microsoft Tech Community to spread knowledge and help other people, sharing insights and tips on topics ranging from Microsoft Endpoint Manager to Azure Sentinel and Logic Apps.

Comments

  1. Roy

    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.

    1. Avatar photo
      Thijs Lecomte

      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.

  2. Matthew

    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’?

    1. Avatar photo
      Thijs Lecomte

      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

      1. Matthew

        Hi Thijs, thank you for your response, very helpful. Kind regards, Matthew.

      2. Michelle

        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?

        1. Avatar photo
          Thijs Lecomte

          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

  3. Monty

    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.

    1. Avatar photo
      Thijs Lecomte

      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

Leave a Reply