Creating an Office 365 Exchange Online transport rule to prepend a disclaimer for inbound external emails with a specific display name

I feel that every organization has at some point received phishing emails where the attacker impersonates a high level executive such as a CEO to email a CFO or someone in finance in the organization to try and have funds urgently transferred to an account. These phishing attempts can be very difficult to adequately protect because the attacker can easily create an email account from a legitimate service such as Gmail with the CEO’s name concatenated with perhaps a number at the end. The display name will only show the first and last name of the CEO and some users could potentially miss that the email address is not from within their organization. There are many products available that addresses this and one that I am familiar with is Office 365 Advanced Threat Protection which provides a feature named mailbox intelligence which has the following configurable actions:

Being able to purchase ATP would be dependent on the size of the organization and whether they’re able to afford the additional licenses but in the event that they are not able to, I would like to demonstrate a possible Exchange Online transport rule solution that can prepend a disclaimer for the incoming email. Note that this wouldn’t be very scalable as you would have to either configure separate rules for each user with a disclaimer identifying the user or have one rule configured for specific users but use a generic disclaimer.

Begin by navigating to mail flow > rules:

Create a new rule:

Provide a name for the rule and configure a condition specifying that The sender is located… with the setting Outside the organization:

Add another condition specifying A message header… with the setting matches these text patterns:

Add the full name of the user into the specify words or phrases window:

In the Do the following… field, you can select any of the actions you would like to execute when such a message with the matching display name but for this example we will use prepend a disclaimer:

You are free to use HTML to format the disclaimer and the following one I included is a yellow text box with the warning Caution: This is an external email from John Smith:

<table class=MsoNormalTable border=0 cellspacing=0 cellpadding=0

style='border-collapse:collapse;mso-yfti-tbllook:1184;mso-padding-alt:0in 0in 0in 0in'>

<tr style='mso-yfti-irow:0;mso-yfti-firstrow:yes;mso-yfti-lastrow:yes;

height:11.9pt'>

<td width=323 valign=top style='width:242.35pt;border:solid #2A3B48 1.0pt;

background:#F4DF11;padding:0in 5.4pt 0in 5.4pt;height:11.9pt'>

<p class=MsoNormal><b><span style='font-size:9.0pt;color:#993922'>CAUTION: </span></b><span

style='font-size:9.0pt'>This is an external email from John Smith <o:p></o:p></span></p>

</td>

</tr>

</table>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

Review and add any additional conditions such as The recipient is… with your own email to test the rule before adding it globally:

Proceed to test by sending an email from an external domain with the specified display name you created in the rule to verify that the emails are prepended with a disclaimer.

----------------------------------------------------------------------------------------------------------------------------

Other layers of protection you can add in addition to this are as follows:

Enabling Mail Tips for that warn users when they send an email with external recipients

This needs to be enabled at a global level so either everyone gets the mail tip or no one does so proper communication needs to be made to the organization.

Execute the following cmdlet to determine review the setting:

Get-OrganizationConfig | FL *mailtips*

Note that the screenshot below indicates it is currently set to False. To enable it, execute the cmdlet:

Set-OrganizationConfig -MailTipsExternalRecipientsTipsEnabled $true

Users will notice the following when they have an email with external recipients in the To field:

Prepending a disclaimer for all external emails

You can create a transport rule similar to the one described in this post but omit the condition for the header and tag all external emails entering the organization. If you choose to implement this then I would suggest changing the action for the rule that matches a display name so you don’t end up inserting two disclaimers.

Creating a new Exchange Online transport rule with the condition "has specific properties matching these text patterns" does not allow you to configure and add a user property

Problem

You would like to configure a new transport rule in Exchange Online with one of the following conditions:

• has specific properties including any of these words
• has specific properties matching these text patterns

You proceed by navigating to mail flow > rules:

Create a new rule:

Then add the condition The Sender > has specific properties matching these text patterns or has specific properties including any of these words:

… but you notice that the select user properties window is laid on top of the window where you are supposed to configure the User properties field:

You are unable to edit the User properties field unless you click on the Cancel button for the select user properties window:

Proceeding to configuring a user property and clicking OK will bring you back to the main configuration page for the rule without applying the changes you made:

Clicking on the Select properties and text patterns… link returns you to the previous issue where the select user properties window is presented:

… but clicking the + button will bring up the window User properties window behind it and seemingly stuck:

Using Chrome or Edge exhibits the same behavior and testing this on a on-premise Exchange Server 2016 (Version 15.1 Build 1591.10) yields the same result.

Solution

This issue threw me off for quite some time as I thought I was doing something wrong interactively so after not having any luck from searching through posts online, I opened a call with Office 365 support and the engineer eventually told me this was a bug and the solution was to use Internet Explorer. The Internet Explorer I had on my Windows 10 laptop is shown in the screenshot below and it indeed resolves the issue.

Adding Email Address / ProxyAddress to an O365 mailbox for a user account that is synced with an on-premise Active Directory

I’ve recently been asked a few times about a common issue that many on-premise Exchange administrators encounter when transitioning to Office 365 so I thought I’d write a quick blog post outlining how to modify or add email addresses to an Office 365 mailbox for a user account that is synced with an on-premise Active Directory.

Problem

You attempt to use the Exchange Admin Center to add an additional email address or modify the primary email address of an Office 365 mailbox but receive the following error:

The operation on mailbox "<username>" failed because it's out of the current user's write scope. The action 'Set-Mailbox', 'EmailAddresses', can't be performed on the object '<username>' because the object is being synchronized from your on-premises organization. This action should be performed on the object in your on-premises organization.

Attempting to use the Microsoft 365 admin center yields the same results:

The operation on mailbox "TestO365" failed because it's out of the current user's write scope. The action 'Set-Mailbox', 'EmailAddresses', can't be performed on the object 'TestO365' because the object is being synchronized from your on-premises organization. This action should be performed on the object in your on-premises organization.

Solution

The way to add or modify email addresses for Office 365 mailboxes for user accounts that are synced with an on-premise Active Directory is to modify the proxyAddress attribute for the user account:

Prepending the email address with SMTP: capitalized will configure the primary email address for the account:

Additional email address aliases can be configured with smtp: in lower case.

Once the changes have been made to the account from the on-premise Active Directory, proceed to forcing a synchronization on the server with AD Connect to synchronize the changes to the account in Azure AD.

Start-ADSyncSyncCycle -PolicyType Delta

Configuring Conditional Access Policy in Azure to prevent non Hybrid Azure AD Joined devices from accessing Exchange Online

The recent coronavirus pandemic has led many organizations to rush and provide remote access for their employees and with remote connectivity to corporate resources comes with increased security concerns. One of the common questions that I’ve been asked is whether there was a way to lock down Exchange Online so that only corporate assets could access the service. The short answer is yes, but it is important to note that Office 365 was designed to be accessed in many different ways such as an email client (e.g. Outlook), through the web browser (e.g. webmail), or mobile smartphone (e.g. iPhone and Android devices) and tablets. One of the clients I worked with was mainly concerned about Outlook access as once a user has authenticated with an Outlook client and the credentials are cached, the client would automatically connect to Exchange Online as long as the password hasn’t changed. Having gone through the process of setting up Azure’s Conditional Access Policy to achieve the desired access restriction, this post serves to demonstrate the configuration and the experience of a device that is not Hybrid Azure AD Joined.

Prerequisites

The Conditional Access Policy we’ll be configuring is dependent on the devices in domain as being Hybrid Azure AD Joined. I won’t go into the details of how to configure this but will reference the following two documents:

Tutorial: Configure hybrid Azure Active Directory join for managed domains
https://docs.microsoft.com/en-us/azure/active-directory/devices/hybrid-azuread-join-managed-domains

Tutorial: Configure hybrid Azure Active Directory join for federated domains
https://docs.microsoft.com/en-us/azure/active-directory/devices/hybrid-azuread-join-federated-domains

Creating a Conditional Access Policy

Navigate to Azure Active Directory > Security > Conditional Access and click on New policy to create a new Conditional Access Policy:

Configuring the Users or Groups to apply the policy

Fill in a name for the Conditional Access Policy, select Users and groups to configure who this policy will apply to. It would be best to validate the policy does what you intend it to do so either apply it to a single account or a group to test:

Configuring the cloud apps (Exchange Online) to apply the policy

Select Cloud apps or actions > Cloud Apps > Select apps and locate Office 365 Exchange Online:

Configuring the conditions to apply the policy

Select Conditions > Device platforms > Select device platforms and select Windows and macOS:

Note that we are restricting desktops and laptops from accessing Exchange Online and if you were to select Android, iOS and Windows Phone then your mobile devices would no longer be able to connect as they can be Azure AD registered but not Hybrid Azure AD Joined. See the following

What is a device identity?
https://docs.microsoft.com/en-us/azure/active-directory/devices/overview

Select Conditions > Client apps (Preview) > Select the client apps this policy will apply to and select:

• Mobile apps and desktop clients
• Modern authentication clients
• Exchange ActiveSync clients
• Other clients

Configuring the grant access controls to apply the policy

Select Access controls > Grant > Grant access and select Require Hybrid Azure AD joined device:

The Require all the selected controls and Require one of the selected controls configuration doesn’t matter as we are only configuring one control but if you chose to select more than one then you need to decide whether you want the grant access based on all of the requirements or any one of them.

With the policy configured, you can choose to choose Report-only, On, or Off:

Testing the policy with the “What If” feature

What I’ve noticed was that configure the policy to Report-only could be misleading if you’re trying to use the What If feature because it would not report that the configured policy is applied even if the conditions are met. The only way for the What If feature to report that the policy is applied is if I enable the policy.

Switching the policy to On and using the What If to test the policy will allow you to confirm whether the policy is applied as anticipated:

Attempting to access Exchange Online with Outlook 2019 on a PC that is not Hybrid Azure AD Joined

The following is what the experience would look like for a user attempting to use Outlook on a Windows 10 device that is not Hybrid Azure AD Joined.

s

The user wouldn’t be able to add the mailbox if they attempted to use Outlook 2013 to access Exchange Online:

Important Items to Note

• Configuring such a policy for Exchange Online will also block access to Teams
• This policy does not prevent users from accessing Exchange Online with their mobile or tablet devices and if this is a requirement then I would suggest using Intune

Deploying Azure Migrate appliance on VMware vSphere 6.7 fails with "Unable to process template"

Problem

You attempt to set up the Azure Migrate appliance to perform an assessment on a VMware vSphere 6.7 environment by downloading the OVA appliance from Azure:

MicrosoftAzureMigration.ova

… but notice that the process fails in the vSphere client with the error message:

Unable to process template.

Solution

One of the common causes of this issue is if you are using Internet Explorer as your browser and the following is a version that would display this error:

Internet Explorer 11
Version: 11.3383.14393.0

One of the quickest way to get around this is to use Google Chrome: