Separation of Responsibilities and Administrator Mailboxes
In his article describing why separate Microsoft 365 administrator accounts are critical to security posture, Thijs Lecomte outlines reasons why the accounts used to perform Microsoft 365 administrative operations should not be used for day-to-day activities such as email and Teams. I have no argument with this stance. It’s logical and reasonable, even if administrators would prefer to use a single account for everything. Of course, that account would be highly-permissioned and a desirable target for compromise by attackers, which is why the case exists not to expose administrator mailboxes to email.
Why Administrator Accounts Sometimes Need Mailboxes
On the other hand, an argument can be made that administrator accounts should have controlled email access so that their mailboxes can receive essential operational information such as change control orders, notification of essential maintenance, and other topics (like the examples of Microsoft correspondence cited below). Different needs might exist for people with different administrative roles. For instance, an Exchange Online administrator account needs email access, as does one holding the Compliance administrator role. The same is probably not true for a Teams administrator.
If you decide to go along this path, you should still convince administrators that they should not sign into their administrator accounts unless they need to perform some action which requires administrator permission. For day-to-day work, they should use their personal account.
The question then arises how best to secure and access the administrator mailbox. The second question is easiest because the administrator’s personal account can be granted delegated access to the administrator mailbox. Using Outlook desktop, OWA, or Outlook mobile, they can then deal with any mail which arrives in that mailbox, including being able to respond from the administrator mailbox (using the SendAs permission).
The Power of Transport Rules
To secure administrator mailboxes, I suggest using two transport rules (mail flow rules) to block messages sent to these mailboxes:
Rule 1 applies to messages sent inside the organization. Because we want to encourage people not to send email to the administrator mailboxes, the rule generates an NDR to tell them when the rule blocks their messages. An exception allows administrators to send email to each other. Although I use the same distribution list for the exception, you could use a different list to gain some additional flexibility over who can send email to administrator accounts. Naturally, the distribution list for administrator mailboxes should be part of the distribution list used for exceptions.
Whenever possible, use distribution lists to control the accounts to which rules apply and those with exceptions. Using distribution lists makes it much easier to amend the scope of a rule because you don’t need to edit the rule to update the mailboxes it applies to. Figure 1 shows the rule being edited in the Exchange Online admin center.
You’ll note that a second exception exists for mail from an address starting with “recordreview.” This allows the administrator account to accept messages relating to disposition review processing from the Microsoft 365 Compliance center. It’s a bad idea to use an administrator account as a reviewer for items whose retention periods have expired and need to be examined before a final decision about their disposition is made, but I include this exception as an example of how you might need to include exceptions for internal senders that should go to the administrator account.
Any attempt to send email by a user who’s not in the exception list is blocked and the user receives a non-delivery notification to tell them why (Figure 2).
Rule 2 applies to messages sent by external people. These messages might be phishing attempts or contain malware, so we have zero interest in allowing them to get through. In addition, we don’t want an NDR going back to the sender as this will confirm the validity of the email address, so we simply drop these messages into the email void. Figure 3 shows this rule.
Exchange Online message trace is a good way to validate the effectiveness of the transport rules. Some simple PowerShell can search the message trace data for administrator accounts (based on distribution list membership) and report events for failed messages (Figure 4). Scanning the data, you’ll quickly realize if Exchange Online drops messages that should get through and be able to update the transport rule with exceptions to allow this email through.
Here’s the code I used to create the results shown in Figure 4.
$EndDate = Get-Date; $StartDate = (Get-Date).AddDays(-7)
[array]$AdminAddresses = (Get-DistributionGroupMember -Identity "Tenant Administrators DL").PrimarySmtpAddress
[array]$TraceData = Get-MessageTrace -RecipientAddress $AdminAddresses -StartDate $StartDate -EndDate $EndDate -Status Failed
If (!($TraceData)) {Write-Host "No failed messages to administrative accounts found"; break }
$Report = [System.Collections.Generic.List[Object]]::new()
ForEach ($T in $TraceData) {
$ReportLine = [PSCustomObject][Ordered]@{
TraceId = $T.MessageTraceId
Received = Get-Date($T.Received) -format g
Sender = $T.SenderAddress
Recipient = $T.RecipientAddress
MessageId = $T.MessageID
Subject = $T.Subject
FromIP = $T.FromIP
Status = $T.Status
}
$Report.Add($ReportLine)
} #End ForEach
$Report | Sort Recipient | Select Received, Sender, Recipient, Subject, Status | Out-GridView
The Microsoft Exceptions
Some exceptions are necessary to allow the delivery of messages from microsoft.com and protection.outlook.com. Among the reasons why email from Microsoft domains arrive in administrator mailboxes are:
- Subscriptions and license renewal/expiry and invoicing.
- Azure AD identity protection (like the weekly digest).
- Notifications of changes from the Microsoft 365 message center.
- Notifications of document sharing with external people.
- Notifications of malware intercepted by Microsoft 365 Defender for Office 365.
- Alerts generated by alert policies.
- Notifications for Yammer conversations.
Blocking all external email would stop these messages arriving, which is why we need exceptions for the two domains noted above. Your business might have other domains or email addresses which should be exceptions.
Think Before Implementation
I don’t pretend that this is a perfect solution for every organization. Some suggest that it’s enough to forward email from permissioned administrator mailboxes to non-permissioned mailboxes. This approach works, but it means that phishing and malware-infected email arrives into the non-permissioned mailboxes. I like that this junk gets dropped by the transport rules.
Before going along this path, consider aspects like how people work today, the protection for their accounts, what email traffic arrives in administrator mailboxes (and the domains where this email originates from), email clients used, and how such a change might impact administrators.
Because membership of a distribution list determines the mailboxes controlled by the transport rules, it’s easy to start by applying the control to a single administrator mailbox. Do this for a couple of weeks and observe what happens, and if all goes well, you can proceed to cover all administrator mailboxes, perhaps after making a tweak or two.
