One of the longstanding best practices for Active Directory Domain Services and privileged accounts is to never assign your regular login account Domain Admin or any other privileged group permissions. This makes a lot of sense because if you use a privileged account to log into your regular desktop every day for non-administrative activities, you are just one accidental malicious link click away from being compromised, potentially granting an attacker elevated permissions to the network. I remember the days when I would log into my desktop with my regular tluk account and use my a-tluk, admin-tluk, tluk-admin, or any other standard that defines an administrator account to access servers or run applications as a Domain Admin.
With the above in mind, fast forward to today, where many organizations have adopted the cloud and are using services such as Azure. One of the most common penetration testing recommendations I’ve seen over the past few years is to ensure that your privileged accounts, such as a Global Admin (note that this shouldn’t be an on-premises synced account according to Microsoft’s recommendations), shouldn’t have a mailbox. This typically wasn’t a challenge during the on-premises days. However, when you mix in PIM (Privileged Identity Management), which is also recommended to be leveraged so that even privileged accounts require manual activation to gain elevated permissions, it immediately becomes a problem. PIM approval request emails are sent to Global Administrators, creating a predicament where Global Administrators receive emails but these accounts do not have mailboxes.
Many of my former colleagues have reached out to me about this issue, and the first thought that typically comes to mind is to assign an Office license to the administrator account and then forward the emails to a regular account. However, this solution isn’t very practical because it requires consuming an Office 365 extra license just to forward emails. Another idea, which won’t work, is to try converting the account’s mailbox to a Shared Mailbox, but this wouldn’t be effective either, as Shared Mailboxes have accounts disabled. Lastly, attempting to configure the admin account with the same email address as an existing mailbox is not feasible because Entra ID does not allow duplicate proxy address / email addresses for different accounts.
Note the error message when trying to use the same email address for another account:
Failed to update user
Update would cause the user to have a proxy address already present on user “Terence Luk”. Click on the notification to see the conflicting user.
The solution to this is actually quite simple and that is to use Plus Addressing. This method isn’t specifically designed for administrative accounts as many use it to generate unique email addresses that all deliver to the same mailbox. Plus Addressing was made available for Exchange Online back in 2020 as announced in this article: https://techcommunity.microsoft.com/blog/exchange/plus-addressing-now-available-in-exchange-online/1824651
So what is Plus Addressing? Plus addressing is a feature that allows users to create unique email addresses by adding a “+” sign followed by additional text to their existing email address. Here is how Plus Addressing works:
-
Validation – When an email with plus addressing is received by Exchange Online, it will check if the base address (before the
+) is a valid mailbox (e.g.user+newsletter@domain.comwould be checked asÂuser@domain.com) -
Routing – If the base email address is valid, the email is delivered to the base address (e.g.,
user@domain.com), ignoring theÂ+tag. -
Processing – The full address (including theÂ
+tag) is preserved in the message headers so the To address will retain the the full plus addressing email and in turn with enable users to see the intended email address and, if desired, filter or sort emails based on the tag.
In the context for regular users, this technique is useful for sorting and organizing incoming emails or for providing a unique email address while ensuring all communications go to the same inbox. What a regular user can do is sign up for newsletters with tluk+newsletters@terenceluk.com, ask friends to email them at tluk+friends@terenceluk.com, and ask family to email them at tluk+family@terenceluk.com while having all of these emails delivered to tluk@terenceluk.com mailbox with the To field populated with the plus email address thus allowing them to use inbox rules to move them into different folders.
In the context of Entra ID accounts, if my regular non privileged account email address is tluk@terenceluk.com, I can use plus addressing to create variations such as tluk+a-tluk@terenceluk.com. Emails sent to tluk+a-tluk@terenceluk.com will still be delivered to my main inbox at tluk@terenceluk.com.
Now proceeding to apply this to my Entra ID Global Admin account, I can have all PIM requests, Azure administrator notifications, and any other emails that get sent to my Global Admin account by configuring it as such:
With this type of separation, notifications coming in for the Global Administrator will get delivered to the corresponding regular user’s account but since they are logged in with their non-privileged account, they would get authenticated to log in as their privileged account (or required to PIM) before they can perform a privileged activity or receive any Azure notifications bound for Global Administrators.
Hope this helps anyone who might be looking for a way to separate their privileged and non-privileged accounts while still being able to receive administrator account notifications.
