MSEndpointMgr

2 for 1 – Mail enable unlicensed admin accounts

Are you looking to cut mailbox licensing costs for your Office 365 tenant? Well, look no further, and I will share a few ways for you to save money on Exchange Online licensing fees for your admin accounts that need to exchange e-mails.

So what do I mean by “admin accounts”?

In this case, the admin account (sometimes referred to as an ADM account) is a separate privileged account used by IT staff to perform their privileged duties. These account types are a standard security measure implemented in many companies, and in some cases, they need to be mail-enabled.

Some valid reasons for needing to mail enable an admins account is:

  • To receive Microsoft Notifications.
  • Third-party admin tools that don’t support alternative e-mail addresses.
  • OTP messages sent to the account.
  • Using the account UPN in places that require you to fill in an e-mail.

But mail enabling does not necessarily mean having to purchase a license for Exchange Online!

One way for you to avoid excessive licensing for Exchange Online is to redirected emails using Distribution Lists.

By redirection, I mean mail destined for your admin account goes to your regular non-privileged account instead.

Using Distribution Lists to redirect e-mail has several advantages:

  • Easy to set up with PowerShell or EAC.
  • Redirect without storing a copy.
  • Supports “send as” or “on behalf.”
  • Supports “Hide from Global Address List.”
  • Generates the least amount of system clutter.
  • No license consumption required!

You might be wondering why this single problem had med choose Distribution Lists over other tried-and-true solutions? I explain that and other solutions, at the end of this article. It’s up to you to decide if you think another solution is a better fit for your organization.

Now that most of the admin portals in Microsoft 365 and Azure no longer required admins to have an active license assigned. You cloud be looking into removing Exchange Online Licensing from your admin accounts and switching to Distribution List redirection or similar solutions to save money.


The solution

I have opted into using PowerShell for this solution, but you could use the Exchange Admin Center instead. This is, however, not explained in this blog post.

The following PowerShell code should get you off to a good start. Use it to build a neat solution in Azure Automation, and have it execute every time you add a new admin account. That is sure to impress the boss!

Automation is king – only your imagination will limit you…

The requirements

  • Azure Subscription (free is sufficient).
  • Exchange Online Administrator Privileges.
  • A basic understanding of PowerShell script variables.

The steps

  1. Log on to Azure Cloud Shell via https://shell.azure.com
  2. Run the command: Connect-exopssession
Azure Cloud Shell using Exchange Online Module

After completing the above steps, you can interact with Exchange Online PowerShell.

Before you go off and execute the script below, you first need to understand the variables that it uses.

$adminMail = "[email protected]" 
$userMail = "[email protected]" 

$name = ($adminMail -replace "@","_").Replace(".","-") 

New-DistributionGroup -Name "Redirect for $name" -Alias "$name`_admin" -PrimarySMTPAddress "$($adminMail)" -ManagedBy "$userMail" -CopyOwnerToMember -MemberDepartRestriction "Closed" -MemberJoinRestriction "Closed" 

Set-DistributionGroup "Redirect for $name" -HiddenFromAddressListsEnabled $true -GrantSendOnBehalfTo "$userMail" -RequireSenderAuthenticationEnabled $false  

You will need to modify the variables in the script above, according to your requirements.

  • $adminMail. This variable is the e-mail address you wish to assign to the Distribution Group. This should be the same as the UPN address of the admin account.
  • $userMail. This variable is the non-privileged account e-mail. This account must have an Exchange mailbox and should only belong to the same person owning the admin account if you like staying compliant.
  • $name. This variable is my way of auto-generating a name for the Distribution List; you can modify it if you like, but you must understand the impact yourself.

Troubleshooting

  • No e-mail coming through from the Internet.
    • Unfortunately, it can take a while for your newly created Distribution Lists cleared for unauthenticated external e-mail. So, give it some time.
  • Admin e-mail address already in use in the organization?
    • If you previously had this e-mail address receiving e-mail, you will need to track down the location of the e-mail attribute and remove it from whatever crevice it resides in – e-mail addresses are unique throughout Exchange Online.
    • Remember to back up any existing mail data if you already had a license assigned to the admin account.
  • Unable to remove the Exchange Online license from the admin account.

Other solutions – pros/cons

As with all things Microsoft, there are several ways to achieve a solution to a problem, so in the spirit of sharing my thoughts, here are some other possible solutions.

Please keep in mind that you might be required to adhere to specific compliance requirements, such as accountability, traceability, retention, backup licensing, exit strategies, and separation of privileges.

Security compliance is why I ended up choosing Distribution Lists. Also because they have the smallest footprint vs. usability.

Pros:

  • Requires no license.
  • Easy to implement.

Cons:

  • Can’t use “Send As” and “On behalf of”.
  • Clutter in the rules list. Can you imagine having 99 admin accounts and this problem?
  • You are limited to 300 rules in Exchange Online.

A classic solution to saving on Exchange Online licensing, but it did not support my requirements of not being able to store email – it came close though!

Pros:

  • Requires no license.
  • Can store a hierarchy of mail items in folders.
  • Easy to configure and maintain with PowerShell.
  • The first 2 cons are also a pro depending on how you view it.
  • Can have a very small visual footprint in the admin interface.

Cons:

  • Requires a user account to be present and disabled for mailbox login in the Azure AD users list. This could very well be the admin account, as it will still be able to log into the portal (Thanks to John Walmsley on FB for pointing this out).
  • The admin UPN can only be added as a secondary Alias. And as such, it consumes yet another address. Unless you are simply using the admin account as a shared mailbox.
  • Runs as a separate mailbox in Outlook, unless automapping is disabled and email is forwarded.
  • Your mobile access to these emails will be limited to Outlook for iOS/Android.

Not much to say here. Except that it’s not possible to assign an Alias to a regular user if the alias exists as a “UserPrincipalName” (UPN) on an existing account. Also if you have a Hybrid Exchange environment, you might be tempted to manipulate the user’s proxyAddress attribute directly. This will not work!

Pushed as the ultimate replacement for Distribution Lists, this was the first thing that came to mind but was ditched due to the cons listed below.

Pros:

  • Requires no license.
  • Have all the same features as Distribution Lists.
  • Modern.
  • Has a Calendar.
  • Has a File area.
  • …a ton of things!

Cons:

  • It has way too many features and will appear in several places that I don’t want it to appear.
  • Can ONLY be configured as intended via PowerShell.
  • The admin UPN can only be added as a secondary Alias. As such, it consumes yet another address.
  • Mobile access to these e-mails will be limited to Outlook for iOS/Android. So you might need forwarding enabled.

Final words

In a perfect world of E5 licensing, you could use Azure PIM to consolidate users. And I often recommend this, unless you have strict requirements to separate all administrative access as some services will not yet integrate neatly with your Azure Identity and Conditional Access. So a classic separation of accounts with privileged access can still be required.

As always, I hope you find inspiration in this article. And I welcome any feedback in the comments or on twitter @michael_mardahl.

(7685)

Michael Mardahl

Michael Mardahl is a seasoned IT pro with over 25 years of experience under his belt. He's a Microsoft Certified Cloud Architect at APENTO in Denmark, where he helps customers move from traditional infrastructure to the cloud while keeping security top of mind. When he's not working, Michael's either spending time with his family and friends or passionately blogging about Microsoft cloud technology. His expertise in this area has even earned him the prestigious title of Microsoft Most Valuable Professional (MVP) in both the Enterprise Mobility and Security categories. In short, Michael is the IT equivalent of a rockstar, but don't expect him to act like one - he's way too down-to-earth for that.

7 comments

  • Hi Michael
    Not sure if this thread still alive.
    I have a Global Admin with no license, but running the New-DistributionGroup produces the below error.
    Do I need to prepare something to the existing Global admin before creating the DG?

    An Azure Active Directory call was made to keep object in sync between Azure Active Directory and Exchange Online. However, it failed. Detailed error
    message:
    The value specified for property EmailAddresses is incorrect. Reason: ObjectConflict with:User_xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx DualWrite (Graph)

    Thanks
    Michael K.

    • Seems to me you have a conflict – I can’t comment on the specifics of it as I have not run into it.

  • I understand that with that, I can send (from a internal monitoring system for instance) a mail to [email protected] (the smtp of the distribution list) and it will arrive in the mailbox of [email protected] (the smtp of the u-Account). So far so good, but if I have a mail enabled security-group in ActiveDirectory (ex. vCenterAdmins) and the admin account (with [email protected] but now without smtp address attributes) is member of this group, will it still work when I sent alerts to the security groups smtp address?
    For instance an alert from vCenter is sent to the mail enabled securitygroups smtp address “[email protected]” – that is the only configured address for vCenter alerts. The mail enabled securitygroup vCenterAdmins acts as a distribution list. All members of this distribution list would – if mail enabled – get the mail to their smtp address. But the admin account does not seem to be “mail enabled” in your case and therefor as a member of a mail enabled security group will not get an eMail at all. It seems with the explained solution you cannot sent a eMail to the user object of the Admin account, but you sent instead a eMail to his corresponding UPN, which seems for me not the same – or am I wrong?

    • My suggestion is simply for this use case:

      1 person has two user accounts, a regular account that has a mailbox, and a special admin account that has no e-mail account.
      To save some money on the e-mai licenses, you simply redirect any e-mail destined for the admin account, to the regular user account.

      In the case of your venter admins mail enabled security group, you could add the normal user account to the venter admins mail enabled security group.
      But since you are most likely also assigning permissions with that, it it not going to be a great solution.

      Now, I have to comment on your choice of using a mail-enabled security group.
      1 – you can’t use solutions like I have proposed, so you will need to just pay for the mail license.
      2 – RBAC best practise dictates that you should separate security assignments and mail distribution whenever possible.

      So I suggest you stick with a regular security group for assigning permissions, and create a separate distribution list for e-mails to your venter admin accounts.
      This is the way – the other way is a shortcut and it offers less flexibility as a trade.off for less management overhead.

  • Hi,
    Well, as pointed on other forums, if there is no one in TenantAdmins that has a mailbox, no alerts are being triggered at all – there is simply nothing in logs/tracking.

    So at the moment, the only way is to manually add the address you want (the one with mailbox) on each alert you want to receive.

    For PIM reports, alternate email address does work.

    • Hi Andrew,

      Thanks for the info.
      I have heard of someone assigning a license to the admin, then setting up an email forward, and then converting to a shared mailbox, might do the trick, it seems a bit hacky though.
      I would suggest adding an exchange online kiosk license then to your break the glass account, to get the system to generate the alerts on the cheap.

Sponsors

Subscribe

Do you want to be notified of new posts on our site?

Please enter your email address below:

Categories

MSEndpointMgr.com use cookies to ensure that we give you the best experience on our website.