Category Archives: Office365

Prepopulate mobile phone for multi-factor authentication

I am working with a customer where we want to enable multi-factor authentication for their users as a measure to secure their environment. But when you enable MFA and a user logs on for the first time, the user has to enter his mobile phone number, even if the mobile phone number is populated in on-premises Active Directory and synchronized to Azure Active Directory (which is default).

additional security verification

When you check the user account in the Azure AD portal, you can see that the mobile phone number is synchronized, but the authentication phone number is empty.

authentication contact info

This is not a desired solution, if a user can set a new mobile phone during logon, a malicious user can do this as well. A typical user will logon shortly after the MFA is set, but especially when doing bulk changes this might not be the case. And when a user account that is MFA enabled, but hasn’t set the authentication phone property is compromised you’re screwed.

Out of the box there’s no easy way to prepopulate the authentication phone number. The authentication phone number is not store in on-premises Active Directory, it’s an Azure AD property. The property to control the strong authentication is called StrongAuthenticationMethods and you can set this using PowerShell. When you set this, the authentication phone number is still prepopulated, but when the mobile phone number is synchronized, this is used in the first place.

To set this StrongAuthenticationMethods property you can use the following PowerShell commands:

Connect MsolService 
$UserPrincipalName = ""
$SMS = New-Object -TypeName Microsoft.Online.Administration.StrongAuthenticationMethod
$SMS.IsDefault = $true
$SMS.MethodType = "OneWaySMS"
$Phone = New-Object -TypeName Microsoft.Online.Administration.StrongAuthenticationMethod
$Phone.IsDefault = $false
$Phone.MethodType = "TwoWayVoiceMobile"
$PrePopulate = @($SMS, $Phone)
Set-MsolUser -UserPrincipalName $UserPrincipalName -StrongAuthenticationMethods $PrePopulate

Now when the user logs on for the first time with MFA enabled, he’s presented the enter code dialog box, without having to enter a mobile number first.

we texted your phone

If you do this, and the mobile phone number is not set in on-premises Active Directory, MFA will still try to use the mobile phone number, but nothing will happen as shown in the following screenshot:

we are having trouble verifying your account

Since there’s no mobile phone number to use, and no option to add this anymore directly by the user you’re stuck here (until the mobile phone number is added to on-premises Active Directory of course).

Note. If you want to enable MFA using PowerShell, you can use the following commands (and maybe combine them with the commands mentioned earlier):

$Strong = New-Object -TypeName Microsoft.Online.Administration.StrongAuthenticationRequirement
$Strong.RelyingParty = "*"
$Strong.State = "Enabled"
$MFA = @($Strong)
Set-MsolUser -UserPrincipalName -StrongAuthenticationRequirements $MFA

More information

Implement Azure AD two-factor authentication for users

Recently one of my customers had a user’s account compromised. Because the user had a weak password (name of the local soccer team followed by a sequential number) his account was compromised using a password spray attack.

One way (of many) to avoid this is to use multi-factor authentication (MFA). Besides a regular username and password, MFA uses another authentication option, like a text message, an app on your mobile device or an ‘app password’ when the other two options cannot be used for some reason.

Note. MFA is available in three versions. There’s an MFA for admin accounts (MFA for admin accounts), there’s a full version as part of the Azure AD Premium subscription and there’s a lightweight version part of all Office 365 business subscriptions called the Multi-Factor Authentication for Office 365. This version can only be used with Office 365 services and is the one I used for this blog.

MFA Requirements

Before you start with implementing MFA in your environment, make sure your Office 365 tenant and your devices meet the following criteria.

Office 2016 clients support MFA natively using Active Directory Authentication Library (ADAL), the same is true for browsers. Not all Office 365 tenants have ADAL functionality enabled by default, especially the older tenants have not. To check if your tenants support this, open the Exchange Management Shell for Exchange Online and enter the following command:

Get-OrganizationConfig | Format-Table name, *OAuth*

If it returns False as shown in the screenshot below (I have an older tenant) you can use the following command to enable it on an organization level:

Set-OrganizationConfig -OAuth2ClientProfileEnabled:$true


The same should is true for Skype for Business Online clients. To check the ADAL support in your tenant, open a Skype for Business Online PowerShell command and execute the following command:

Get-CsOAuthConfiguration | select *client*

If it’s not enabled (as shown in the following screenshot) you can use the following command to enable it:

Set-CsOAuthConfiguration -ClientAdalAuthOverride Allowed


For older apps, or apps that do not support MFA through ADAL, you can use an AppPassword. This is a special password, especially for the device you work on. You can only use the AppPassword on this specific device, and not on any other device. For other devices you need to have an additional AppPassword. An AppPassword is created the first time you use MFA on a device which will be shown later in this blog.

For mobile device I strongly recommend installing the Microsoft Authenticator to help you make authentication life a bit easier. The MFA information is stored on this specific device and is only available on this specific machine. The Microsoft Authenticator is available via the App Store on your device.

Enable MFA

To enable MFA for cloud accounts, open the Microsoft Online Portal ( and logon using the tenant admin account. Select Active Users, but before you select any user click on the More drop-down box and select Multifactor Authentication Setup as shown in the following screenshot:

Enable Azure MFA

In the next window, select the user you want MFA to enable for and click enable in the right pane. In the confirmation box click enable multi-factor auth.

In the same Window you can also change the service settings as shown below:

service settings

In the service settings, you can change variables like whether or not to have users create AppPasswords, what authentication options can be used and the timeframe to remember MFA authentications:

allow users to create app passwords

Make sure the Allow users to create app passwords to sign in to non-browser apps radio button is checked. At the same time have a look at the Allow users to remember multi-factor authentication on devices they trust option. Using this option, you can set the number of days before the user has to use MFA again for authentication. In the mean time the device is trusted and MFA is not needed.

Using MFA on your clients

After enabling MFA and you logon to for example OWA an additional pop-up is presented where additional information is requested. The mobile phone number is already in Active Directory and thus prepopulated, and a text message is sent to this number.

30 days OWA

After entering the validation code you are officially logged on. The last step is that an AppPassword is presented, you can use this AppPassword on this device for application that do not support the Microsoft MFA (through ADAL).

When Outlook 2016 is started an additional pop-up is shown where the validation code has to be entered. Since the MFA is remembered for 30 days you won’t see this again the upcoming 4 weeks (and two days 😊).

The same is true for OneDrive for Business and Skype for Business clients, they need to authenticate as well. My work laptop is Azure AD joined, and the advantage here is that I only need to logon once, and need to enter the SMS authentication only once since both tokens are stored on the device.

When enabling MFA as shown below it is enforced on mobile device as well. I have an iPhone with iOS 12.2 and this supports MFA natively. The next time the device needs to authenticate (can take some time after enabling MFA) a validation code is sent to the device. This can be a bit challenging since you need to enter this code on the device itself. The Microsoft Authenticator (or any authenticator) can help you here, especially if you have multiple profiles with multiple (MFA enabled) mailboxes.

The next 30 days (or whatever timeframe you’ve entered) you won’t get the MFA validation challenge, unless you change the password, then the MFA is triggered, and you need to authenticate again. Remember that the token is stored on the local device, so if you want to check your email on another device you have a authenticate using MFA on that device as well. And this is what will frustrate the bad guys in Nigeria (screenshot below shows where out attacker was hiding) since they don’t have access to your device, so even with a weak password (still not recommended!) you should be much safer.



You can use Multi Factor Authentication as an additional measure against hackers that want to use user credentials to access your environment. Since an additional authentication method is needed, it is much more difficult to get access to your environment for the bad guys. Since they don’t have access to the mobile device it’s hardly impossible to misuse the mailbox.

The next logical step would be to implement a password less authentication, but that’s for a future blog 😊

More information

Configuring message hygiene in Exchange Online Protection

In the previous three blogs I explained how to implement Exchange Online Protection for inbound and outbound mail flow, and how to configure SPF, DKIM and DMARC when using Exchange Online Protection. In this blog post I’ll go more into detail on the message hygiene processing itself.

For a correct understanding of Exchange Online Protection, it is good to have an overview of its internals. This is shown in the following figure, where the various steps in message hygiene processing are clearly visible:


By default, EOP does a great job for message hygiene, but it is possible to configure it for specific needs. It is possible to manually configure Connection Filtering (blacklisting and whitelisting), Anti-Mailware, Transport Rules and Content Filtering. I will discuss these in the following sections.

Connection Filtering

The first step in any message hygiene solution is connection filtering. Non-trustworthy mail servers are denied access based on their IP address, connection filtering filters out the majority of all malicious email.

It can happen that you want to allow a particular mail server to deliver mail to your environment, even when its IP address is lists on block lists or denied access for some other reason. To allow this, you can add the IP address to the IP allow list. Vice versa, if there’s a mail server that sends malicious email that’s not blocked by the connection filter, you can add this IP address manually to the IP block list.

To do this, logon to the Exchange Admin Center, select protection and click on the connection filter tab. Click the pencil icon to edit the default connection filter policy. Use the + icon to add IP addresses to the IP allow list or the IP block list. You can add individual IP addresses with a /32 mask, or you can add ranges with a /24 mask or smaller. A total of 1273 entries can be added, one entry can be either an IP address or a range of addresses.

If you add an IP address to both lists, the allow list takes precedence.


Optionally you can select Enable safe lists. Microsoft subscribes to safe lists on the internet, publishing lists of IP addresses that are treated as safe. Using the safe lists you make sure that trusted senders are not treated as malicious senders, so it’s recommended to use the safe lists option.


The anti-malware policy in Exchange Online Protection is enabled by default, it can be viewed and edited by an Exchange administrator, but it cannot be deleted.

In the anti-malware policy, you can define the attachment filtering, detection response, internal and external notification, administrator notifications and you can customize notifications.

To access the default anti-malware policy, logon to the Exchange Admin Center, select protection in the navigation menu and click on the malware tab. Use the pencil icon to view or edit the default anti-malware policy, use the + icon to add a new malware policy. When you open a malware policy, click on settings and edit the settings according to your needs. This is shown in the following screenshot (click to enlarge):


Click Save to store the new settings in Exchange Online Protection and activate them.

Mail flow rules

Mail flow rules, sometimes referred to as Transport Rules are rules in Exchange Online Protection that can take action on a message, based on certain criteria. Mail flow rules in Exchange Online Protection are similar to Transport Rules in Exchange server on-premises, and also similar to rules that you created in Outlook or OWA. Major difference is that Mail Flow rules work on messages in transit, while rules in Outlook only work on messages already delivered to the Mailbox.

Using Mail flow rules it is possible to apply disclaimers, to bypass spam filtering (useful for an abuse mailbox for example), modify messages, check for sensitive information etc. as shown in the following screenshot (click to enlarge):


To add a disclaimer to outbound messages select Apply disclaimers… and follow the wizard. Give the disclaimer an easy name like Disclaimer (Outbound Only), select the sender is located and select Inside the organization and click on Enter Text to add the disclaimer text.

I’ve used the following text in the disclaimer:

This e-mail may contain confidential and privileged material. You are requested not to disclose, copy or distribute any information thereof. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. We accept no liability for damage related to data and/or documents which are communicated by electronic mail.

To prevent a ton of identical disclaimers to email messages that are sent back and forth I’ve included an exception to the disclaimer. Wen the mail flow rule detects the string “This e-mail may contain confidential and privileged material” the disclaimer won’t be added again.

This is shown in the following screenshot (click to enlarge):


Click Save to store the mail flow rule. Send an email from an Exchange mailbox to an external recipient and you’ll see the disclaimer is added as shown in the following screenshot (click to enlarge):


Note. The remaining signature text in the screenshot above is set by Outlook on the Web directly from the Mailbox.

There are multiple options for using mail flow rules in Exchange Online Protection, but most of them are company specific, and targeted towards compliance management.

Spam Filtering

Like any other message hygiene solution, Exchange Online Protection filters out spam messages. Using machine learning in Office 365 and the billions of messages that are processed each day it does a pretty good job.

By default, email messages that are identified are sent to the user’s junk mail folder. It does this based on an X-header that is added by Exchange Online Protection called X-Forefront-Antispam-Report. When this X-header contains the value SFV:SPM it is identified as spam.


The Exchange server then knows it’s a spam message and will store the message in the user’s junk mail folder. However, this works fine in a hybrid environment since both parties trust each other, when using EOP in front of an Exchange on-premises environment this is not the case. To achieve the same results, two transport rules need to be created on the Exchange on-premises environment to process these messages accordingly.

To create these transport rules in your on-premises Exchange environment run the following three commands in Exchange Management Shell:

New-TransportRule EOPJunkContentFilteredMail -HeaderContainsMessageHeader "X-Forefront-Antispam-Report" -HeaderContainsWords "SFV:SPM" -SetSCL 6
New-TransportRule EOPJunkMailBeforeReachingContentFilter -HeaderContainsMessageHeader "X-Forefront-Antispam-Report" -HeaderContainsWords "SFV:SKS" -SetSCL 6
New-TransportRule EOPJunkMailInSenderBlockList -HeaderContainsMessageHeader "X-Forefront-Antispam-Report" -HeaderContainsWords "SFV:SKB" -SetSCL 6

When the transport rules are created, spam messages will be delivered into the junk mail folder.

How to test spam processing? Just like an Eicar ‘virus’ that you can use to test your anti-virus solution there’s a test spam message called GTube. GTube is a text string you can add to your email message, and mail servers will detect this string and mark it as spam. The GTube string is:


After adding this string to an email message from Gmail to Exchange, EOP will mark it as spam, very useful.

So, Exchange Online Protection and Exchange will store spam messages in the user junk mail folder. It is also possible to store these messages in quarantine.
To enable the Quarantine option, logon to the Exchange Online Protection Admin Center, select protection in the navigation menu and click the spam filter tab. Use the pencil icon to open the default spam filter policy. In the spam and bulk action options select Quarantine message under the spam and high confidence spam drop-down box as shown in the following screenshot (click to enlarge):


This is an organization wide quarantine environment that’s available only to the tenant administrator. Logon to the Office 365 portal and select Security and Compliance under Admin centers. It is also possible to navigate directly to the Security and Compliance admin center via You’ll find the Quarantine under Threat Management and Review. By default, quarantined message will be kept for 15 days before they are deleted. This can be extended under the spam and bulk actions of the spam filter policy.


It is also possible to create a mailbox-based quarantine. Select the protection navigation option and click the spam filter tab. In the action pane on the right, scroll down and click the Configure end-user spam notifications option. In the pop-up box, check the enable end-user spam notifications checkbox, change the number of days (default is 3) a notification should be sent and the (default) language as shown in the following screenshot (click to enlarge):


When a user has messages in his quarantine a notification message is delivered to the mailbox with the quarantined messages. The messages can be released to the inbox and can be reported as not junk mail to Exchange Online Protection as shown in the following screenshot (click to enlarge):


This way the users themselves can determine which messages are delivered to their inbox and which are not.

Blocked and Allowed Senders

It is possible to block or allow senders, this can be achieved on individual email addresses or on SMTP domains. To block or allow senders, in the Exchange Online Protection Admin Center select protection in the navigation menu and click the spam filter tab. Use the pencil icon to open the default spam filter policy and select block lists or allow lists. Here you can enter the email addresses or domains that should be blocked or allowed.


Exchange Online Protection is Microsoft’s cloud solution for message hygiene. It is automatically used in combination with any Office 365 subscription, but it can also be used in combination with an on-premises Exchange implementation or any other messaging environment.

In the first two blogs I showed you how to enable inbound and outbound message flow, in the third blog I showed you how to configure SPF, DKIM and DMARC to setup a secure message flow solution. When implemented correctly, the recipient’s mail server can validate the email messages and can identify which messages are spoofed and which are not (on behalf of your domain).

In this last blog post I showed you how to configure the message hygiene solution, how to fine-tune connection filtering, anti-malware settings, implement mail flow rules and how to configure quarantine on an individual user level.

SPF, DKIM and DMARC in Exchange Online Protection

In the previous two blog posts I’ve explained how to implement Exchange Online Protection as a message hygiene solution for your on-premises Exchange environment, both for inbound as well as outbound mail flow.

In this blog post I’ll go more into detail when configuring Exchange Online Protection


When Exchange Online Protection is fully up-and-running you can continue configuring SPF, DKIM and DMARC for message authentication purposes. This will make sure your email domain is much harder to spoof and receiving email systems know that the source of your email is a trusted source.


SPF has been around for years, and in my previous blog post I already mentioned the SPF record needed for use with Exchange Online Protection. If you want to read more about implementing SPF, please check my SenderID, SPF, DKIM and DMARC in Exchange 2016 – Part I blog post.

When only using Exchange Online Protection your SPF record will look like v=spf1 -all.


The good thing about Exchange Online Protection is that it supports DKIM signing and verification out of the box. The only thing you have to do is enable it in the Exchange Admin Center!

Logon to the Exchange (Online Protection) Admin Center, select protection in the navigation menu and click DKIM in the toolbar. When you click enable, an error message (in yellow) is shown that you need to create the appropriate DNS records first (click to enlarge).


The error message reads (for search engine purposes):
CNAME record does not exist for this config. Please publish the following two CNAME records first.

The description isn’t that clear when you’re not a DKIM guru, but you need to create the following CNAME records: CNAME CNAME

When the DNS records are created you can use the MXToolbox to check if they are valid:MXToolbox-DKIM

If an email is sent from the on-premises Exchange server via Exchange Online Protection to for example Gmail, you can check the headers. If configured correctly you can see the SPF check passes, you can see the DKIM signature created by EOP and you can see the authentication results as well. It should read spf=pass and dkim=pass under Authentication Results as shown in the following screenshot (click to enlarge):


For more information regarding DKIM and Exchange, please check my SenderID, SPF, DKIM and DMARC in Exchange 2016 – Part II blogpost.


When DKIM and SPF are configured correctly you can create a DMARC record in public DNS. A DMARC policy will tell a receiving mail server what to do with email that does not comply with other settings. For example, if email is coming from a mail server that’s not listed in the SPF record it might well be spoofed. If the DKIM signature is missing it might be spoofed, if the DKIM signature is not valid, the message might be tempered with. If this is the case, you can define a policy that will reject such a message. The DNS record will be like this:


The RUA is an email address where DMARC reports are sent to, so it’s a good thing to have such a mailbox on your Exchange server.

When sending an email from the Exchange server via EOP to Gmail when SPF, DKIM and DMARC are configured, you can see information like the following screenshot in the email headers (click to enlarge):


Everything is configured correctly now and spoofing is much harder to achieve for malicious users.

For more information regarding DMARC and Exchange, please check my SenderID, SPF, DKIM and DMARC in Exchange 2016 – Part III blog post.


In this blogpost I showed you how to configure SPF, DKIM and DMARC in Exchange Online Protection to prevent spoofing by malicious users.
In my next blog I’ll go more into detail about configuring the message hygiene options themselves in Exchange Online Protection.

Implementing Exchange Online Protection for on-premises Exchange Part II

In my previous blogpost I’ve explained how to implement Exchange Online Protection (EOP) for inbound messaging. In this blogpost I’ll explain what it takes to use EOP for outbound messaging.

As explained, the desired configuration should like this this:

Exchange 2019 EOP

Directory synchronization is in place (not explained in previous blog post), Send Connector from EOP to Exchange on-premises is created, MX record has changed to EOP and messages are delivered through EOP to the mailboxes on-premises.

Outbound mail flow

For outbound mail flow, two connectors need to be created:

  • One Send Connector on the on-premises Exchange server that will send all outbound messages to EOP. This send connector will most likely replace the existing Internet Send Connector that typically uses DNS to send external email to recipients.
  • One Receive Connector on EOP that accepts messages only from the Send Connector that was created on-premises.

For security purposes, TLS is enforced by default so a valid 3rd party certificate is required.

To create the Receive Connector in EOP, open the Exchange (Online Protection) Admin Center, select mail flow and click Connectors. Click the + icon just like when creating the connector in the previous blog post, but right now select Your organization’s email server in the From: dropdown box and Office 365 in the To: dropdown box as shown in the following screenshot (click to enlarge):


Click Next and follow the wizard. There are two ways for Exchange Online Protection to identify your outbound on-premises Exchange server. This can be either by its certificate or by its IP address. In the example below, I’ve selected the certificate and its FQDN for identification, but you can also enter and IP address (click to enlarge):


Click Next to continue and follow the wizard. Check the configuration and click Save to have the Receive Connector created in Exchange Online Protection.

The on-premises outbound connector was already in place (through the Edge subscription) and this connector need to be changed from DNS delivery to smarthost delivery. Logon to the on-premises Exchange Admin Center, select mail flow and click connectors. Open the outbound connector, click delivery and select the route mail through smart host radio button. In the smart hosts box, use the + icon to add your domain specific EOP FQDN, which is something like as shown in the following screenshot (click to enlarge):


When Edge synchronization has synchronized all information to the Edge Transport server it is possible to test the new configuration. When sending an email from Exchange on-premises to my Gmail account and check the header information after receiving, it is clearly visible that mail flows via the Edge Transport server through Exchange Online Protection to Gmail (click to enlarge):


Note. Do not forget to update your SPF record! If your SPF record is not updated, organizations that do check for SPF (like Gmail) will detect an incorrect IP address or FQDN and possibly reject the message. You can find the correct SPF record in your Office 365 Admin Center (under Setup | Domains) and will look like “v=spf1 -all


In the previous two blogposts I showed you how to implement Exchange Online Protection as a message hygiene solution in front of your on-premises Exchange solution. It can be configured for use with an Edge Transport server, but it can also be configured directly from the Mailbox server, or when using a 3rd party SMTP solution in your organization’s perimeter network.

In the next blog I’ll explain more about configuring and customizing Exchange Online Protection.