Last Updated on June 19, 2023 by Michael Morten Sonne

Intoduction

Seperate accounts in Azure AD for Administrative use

Azure Active Directory (AD) is a cloud-based identity and access management service that provides secure access to your organization’s applications and resources. As an Azure AD administrator, you may need to delegate access to certain users or groups for managing specific resources within your organization. This is where Azure AD Privileged Identity Management (PIM) comes in handy.

Azure AD PIM is a feature that allows you to manage, control, and monitor access to privileged roles in Azure AD, Azure resources, and Microsoft 365 services. With PIM, you can grant just-in-time (JIT) access to users or groups, require approval workflows for access requests, and enable email notifications for access-related events.

Why have seperate accounts – Isn’t PIM enough?

Having separate accounts for administrative use in Azure AD is a security best practice. It helps to reduce the risk of unauthorized access to sensitive data and resources.

In the on-premises world, most organizations separate their regular ‘user’ accounts from etc. Azure AD 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, Azure AD 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 discussed 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 for this?

By default, the accounts don’t have any permissions yes, and 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!

Using a separate account for administrative tasks allows you to limit access to privileged accounts only to those who need it, and to closely monitor and audit administrative activity. If an administrative account is compromised, it can be more easily isolated and remediated without affecting the user’s day-to-day activities.

In addition, having separate accounts also helps to prevent accidental or unintended changes or deletions to data and resources. Administrative accounts typically have broad permissions and access, so having separate accounts ensures that these powerful capabilities are not used inadvertently.

Overall, using separate accounts for administrative tasks in Azure AD is an important security measure to protect against unauthorized access and data breaches.

In another article, I will 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 attemps

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.

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.

There is more details about how it works and so on here: Primary Refresh Token (PRT) and Azure Active Directory – Microsoft Entra | Microsoft Learn

But again, 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 some time ago.

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.

A new feature called “Conditional Access: Token protection (preview)” is on its way to help here – more about this in an other blog! 🤓

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 in Azure AD and Credential Guard in Windows, 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. So 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.

But again here, researchers have created proof-of-concepts recently to demonstrate the viability of an attack and getting the passwords out from Azure AD Connect the service is using,

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 in Azure AD. This can stop a potential attack dead in its tracks and provides an additional layer of protection 🔐😉

The recommended setup for alerts

It is generally recommended to set up Azure AD secondary/admin accounts without a mailbox to reduce the risk of these accounts being targeted for phishing attacks or other security threats. When an account is associated with a mailbox, it becomes a potential target for attackers who may try to gain access to sensitive information or credentials.

These accounts should be authorized by an RBAC concept and PIM (Privileged Identity Management) and should not have a mailbox (Exchange Online) license to minimize the attack surface.

However, there is a requirement that the notification e.g. Azure AD PIM or other alerts must be sent to the user 😉

What is “Plus Addressing”

Instead, you can use the new “+ mail” format to set the email address of the admin account to the user’s primary mailbox. This format allows you to create unique email addresses that can be associated with the same mailbox, allowing you to receive etc. Azure AD PIM and other alerts without compromising the security of your admin account. This way all PIM & other alerts get to the user! 👍😉

To use the “+ mail” format, you can simply add a plus sign (+) and any text you want after your email address username and before the “@” symbol. For example, if your primary email address is “[email protected]“, you can use “[email protected]” as the email address for your Azure AD admin account.

Using this format, any emails sent to “[email protected]” will be delivered to the same mailbox as “[email protected]“, allowing you to receive notifications and alerts without exposing your admin account to additional risks – that´s smart! 🤓

As plus addresses are not aliases that are configured on the mailbox, they don’t resolve to a user’s name in Outlook clients. This limitation results in plus addresses being easily identifiable in the To or CC fields of messages.

How does that work

If you create a mailbox for an account with an address that contains a + in Exchange Online, Exchange Online will try to resolve the full email address (for example, [email protected]) to a known mailbox. If the first resolution attempt fails, Exchange Online does a second attempt to resolve the email address without the plus sign and tag (for example, [email protected]).

If inbound internet email for your on-premises organization is routed through Exchange Online, your on-premises mailboxes can also use plus addresses if those mailbox addresses are known in Exchange Online. If the on-premises mailbox addresses are unknown to Exchange Online, plus addressing won’t work and message delivery will be affected.

Overall, setting up Azure AD secondary/admin accounts without a mailbox and using the “+ mail” format for email addresses can help improve the security of your Azure AD environment and reduce the risk of potential security threats.

Why can’t you use the user’s primary email address on multiple accounts

Thats because an email/proxy address can only be assigned to one user at a time in the tenant/Exchange. Plus addressing in Exchange has been enabled by default by Microsoft at the beginning of 2022. To learn more about plus addressing see: Secure access practices for administrators in Azure AD – Microsoft Entra | Microsoft Learn

However, you can disable plus addressing in Exchange Online when useing the new Exchange admin center and PowerShell.

But fir this usecase, is´s a nice and needed feature, so you are locky you doesnt need to turn if on!

Use the new Exchange admin center to disable or anable plus addressing

• In the new Exchange admin center at https://admin.exchange.microsoft.com, go to Settings > Mail flow.
• Select Turn off plus addressing for your organization, and then select Save.

Set-OrganizationConfig -DisablePlusAddressInRecipients <$true | $false>

Set-OrganizationConfig -DisablePlusAddressInRecipients $true

Set-OrganizationConfig -DisablePlusAddressInRecipients $false

Furthermore our IT employee Michael has another Azure AD Admin Account “[email protected]”.

This admin user “[email protected]” has no licenses assigned as described, so no mailbox is provided to the account. Also, in this example, the “Global Administrator” role was assigned to the user via Azure AD PIM.

Configuration the notification forwarding – Plus addresses

To forward the notification from our admin account “[email protected]” to our user primary mailbox “[email protected]“, we configure the admin account in Azure AD as above.

Open the user administration in Azure AD and edit the corresponding admin user. If you try to add the email address of your default user (“[email protected]“), you will get an error message (“Another object with the same value for property proxyAddress already exists.”).

At this point the email format plus addresses is used. Extend your email address to which the mails will be forwarded with for example “+ADM”.

Email for the Admin Account is then: [email protected]

The Azure AD PIM notification send to the + email address

Exchange Online resolves the email address [email protected] without the “+” and associated tag (“+ADM”) so that the notification is sent to [email protected]
If we then assign (or enable) the Azure AD PIM role Global Administrator of the admin account “[email protected]”, we will receive the notification in our user mailbox where the email is send to the +adm email address, but we still get it – thats smart! 😉

Now you get the alerts and all the other stuff needed – so now you can start to secure your admin accounts!

Thank you for taking the time to visit my blog. Kindly share it with others if you find it helpful for them! 😉🔐👍

Stay tuned for the new post about something cool! 🥳