Tag Archives: Security

DKIM record in WordPress DNS

So, today I found out that outbound mail from my jaapwesselius.com did not have a DKIM signature (after mail was blocked by prodigy.net). I have my jaapwesselius.com running on WordPress.com. To do this, WordPress requires to have DNS hosted with them. No problem, but adding a DKIM record in WordPress DNS is not possible, it fails with a TXT records may not exceed 255 characters error message as shown below:

The solution is relatively simple. You can add a CNAME record for the original DKIM record. For example, have safemail._domainkey.jaapwesselius.com point to something like safemailhop.exchangelabs.nl (I own that domain too, and DNS is hosted at my provider Argeweb).

CNAME: safemail._domainkey.jaapwesselius.com safemailhop.exchangelabs.nl

Create a new TXT record safemailhop.exchangelabs.nl and add the original DKIM record (from my jaapwesselius.com domain) to it et voila, that’s it.

Check with https://mxtoolbox.com/dkim.aspx reveals that it works:

And some header information:

Note. Yes I know, p=NONE in the DMARC record could (should/must) be changed to quarantine or even REJECT, but I’m still in development 😊

Basic Authentication in Office 365 Part II

Update. Microsoft has changed their plans due to the Covid-19 crisis going on at the moment. Support for Basic Authentication in Exchange Online has been postponed to the second half of 2021 according to their blogpost on Basic Authentication and Exchange Online – April 2020 Update.

There are a few things to be aware of. For new tenants, Basic Authentication is already turned off, for older tenants it is still turned on. However, if Basic Authentication has not been used in a tenant it will be turned off as well. This will start upcoming October.

In my previous blogpost I explained more about basic and modern authentication, how they work and how to identify which method your outlook client is using. In this blogpost I will explain more about monitoring basic authentication to find out which clients are currently still using basic authentication in your Office 365 environment. I will continue with how to disable basic authentication and how to test what might happen.

Monitoring Basic Authentication

In my previous blogpost I explained a bit more about basic authentication and how to identify it, and the working of modern authentication.

The next step is to identify how many users and application are actually using basic authentication in your Office 365 environment. After all, these are the users that are impacted when Microsoft stops basic authentication.

To identify this, logon to the Azure Active Directory Portal (https://aad.portal.azure.com) and select sign-ins (under Monitoring). There you will see an overview of all sign-ins in Azure AD, successful and failed, for all clients, all services and all locations. An example is shown in the following screenshot (click to enlarge):

This shows all logins in Azure AD, for all aplications and services, failed and successful. You can use the Add Filters button to narrow down the information, in this blogpost to show only information regarding Basic Authentication.

To do this, click Add Filter | Select Client App | Click Apply

Click on “Client App: None Selected” and select all options except Browser and Mobile Apps and Desktop Clients as shown in the following screenshot (click to enlarge):

Modern Authentication Clients

Note. Updated the screenshot on April 6, 2020. Microsoft made a nice GUI enhancement here to easily identify different clients (modern vs legacy).

Now an overview will be shown of all basic authentication attempts in your environment. When you select one entry it will show additional details, including the client application, the username and the the user agent (which identifies the client app) as shown in the following screenshot (click to enlarge):

Another interesting thing is that you can identify where all failed basic authentication attempts are coming from. Add a filter Status | Failure and you will see only failed attempts. Some are legitimate (typo when entering password) but most of them are just brute force attacks. The following screenshot shows attempts coming from Russia, Thailand and New Caledonia, located where we don’t have offices. You can also see that the attempt is coming from a script (User agent CBAInPROD) and that it’s using IMAP4 (which is disabled for all mailboxes). This is one reason why you want to disable basic authentication in your tenant. Click to enlarge:

This is an easy way to identify mobile clients that use ActiveSync as a protocol and thus are using basic authentication. Apple iOS native mail client support OAuth2 since iOS11, so all recent iPhones are using modern authentication. For the Android native mail client things are different. The native Gmail client support OAuth2 but cannot be used of course with Office 365. Most other mail clients do not support OAuth2 yet, so these are using basic authentication and will run into issues when Microsoft stops basic authentication. In other words, these clients will stop working. Change the Client App filter to Exchange ActiveSync only and remove the Status | Failure filter. It will show a list of mobile users that use basic authentication as shown in the following screenshot (username is removed for privacy reasons) (click to enlarge):

Note. Outlook for iOS and Outlook for Android are using OAth2 so these will continue to work.

So, using the filtering options on the sign-in page in the Azure AD portal you can identify which clients are still using basic authentication when accessing Office 365 services (and thus which clients are impacted when basic authentication is stopped).

Disabling basic authentication

It is possible to disable basic authentication in your Office 365 by creating an Authentication Policy and apply this policy to users. Once applied they can no longer use basic authentication to logon to any Office 365 service. To create a new Authentication Policy use the following command in Exchange Online PowerShell:

[PS] C:\> New-AuthenticationPolicy -Name “Block Basic Authentication”

To add a user to the policy and effectively block basic authentication for this user you can use the following command in Exchange Online PowerShell:

[PS] C:\> Set-User -Identity j.wesselius@exchangelabs.nl -AuthenticationPolicy “Block Basic Authentication”

It will take up to 24 hours before this policy is effective. To take the policy effect (almost immediately, or at least within 30 minutes) you can use the following command:

[PS] C:\> Set-User -Identity j.wesselius@exchangelabs.nl -AuthenticationPolicy “Block Basic Authentication” -STSRefreshTokensValidFrom $([System.DateTime]::UtcNow)

To remove a user from an authentication policy you can use $Null for the authentication policy:

[PS] C:\> Set-User -Identity j.wesselius@exchangelabs.nl -AuthenticationPolicy $Null

When you have a number of users added to this authentication policy you can start testing with various clients and create a table with clients and scenarios, like the table below:

Client Results
Office 2010 Stops working (keeps asking for password)
Office 2013/2016 Continues to work (was already using Modern Authentication)
Outlook 2010 on-premises mailbox, cross-premises free/busy Continues to work, but need further investigation (note 1)
Outlook 2013/2016 on-premises mailbox, cross-premises free/busy Continues to work
iPhone 8, iOS13, native mailclient Continues to work
iPhone 8, iOS13, Outlook for iOS Continues to work
Samsung A10, Android 9, native Email client Stops working
Samsung A10, Android 9, AquaMail (by MobiSystems, supports OAuth) Continues to work (note 2)
Samsung A10, Android 9, Outlook for Android Continues to work
Exchange Online PowerShell New-PSSession Stops working (note 3)
Exchange Online PowerShell module Continues to work
Exchange PowerShell V2 Continues to work
POP3 Clients TBD
IMAP4 Clients TBD

Note 1. In this scenario an Outlook client is using an on-premises mailbox but tries to retrieve free/busy information from a mailbox that’s in Exchange Online. Both accounts have basic authentication disabled in Azure AD.

Note 2. The native mailclient in Android 9 (on my Samsung A10) only supports basic authentication. This is not a device limitation but an application limitation. AquaMail (from MobiSystems) for example does support OAuth and keeps working when basic authentication is disabled. AquaMail however is not a free application but a subscription based application.

Note 3. It is possible to connect to Exchange Online as shown in line 9 of the table using the following method:

$ExCred = Get-Credential TenantAdminAccount
$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://ps.outlook.com/powershell/ -Credential $ExCred -Authentication Basic -AllowRedirection
Import-PSSession $Session

This is using basic authentication and will stop working. However, you should not use this way of working anyway because it does not support MFA, which is a recommended best practice for admin accounts! For more information please check Multi Factor Authentication MFA in Office 365 for admin accounts.


In the previous two blogposts I tried to explain a bit more about basic and modern authentication, and what might happen when Microsoft ends support for basic authentication in Exchange Online next October.

For sure, things will break when connecting to Exchange Online. The most obvious is Outlook 2010 which won’t connect anymore. Native mobile clients that do not support oAuth2 (common in Android mail apps, but also older iPhones) stop working too. If you don’t act now you will be in a lot of trouble when Microsoft makes the change.

For now, start testing using the options I explained in this second blogpost. Create your own list of apps and services that use basic authentication and start testing with an authentication policy that blocks basic authentication. That’s the only way to prepare for this major (mega major) upcoming change. But in the end, we will all benefit from a security point of view.

More information

Sender Domain Validation check in Exchange Online

In my previous blog External Senders with matching display names I explained a Transport Rule that checked for matching display names in order to prevent phishing and possible CFO Fraud.

Another interesting solution with Transport Rules is displaying a warning message when the sender’s domain could not be validated. For example, when a message from a sender who’s SPF record is missing or not valid, it would show something like “The sender of this message could not be validated and may not be the actual sender” as shown in the following screenshot.

In this example the SPF record of the exchangefun.nl domain was missing, hence the validation error.

  • The Transport Rule to achieve this is built on two conditions:
  • The sender is located outside the organization.

The Authentication-Results headers contains one or more of the following entries:

  • dkim=fail
  • spf=TempError
  • spf=PermError
  • spf=SoftFail
  • spf=Fail
  • spf=None

For the email mentioned below, the Authentication-Results header shows the following:

Authentication-Results: spf=none (sender IP is
smtp.mailfrom=exchangefun.nl; wesselius.info; dkim=pass (signature was verified) header.d=Exchangefun.nl;wesselius.info; dmarc=permerror action=none header.from=exchangefun.nl;compauth=pass reason=105

Obviously, it fails on the spf=none entry.

To create a Transport Rule to do this, open the Exchange Online Admin Center and navigate to Rules under Mail Flow and click Add New Rule (the + icon). Use the More Options to add additional conditions to the Transport Rule.

The first condition is The sender is located and select outside the organization. The second condition is A message header includes and enter Authentication-Results for the name of the header and the DKIM and SPF entries mentioned earlier in the text of the message header. It should show something like this:

Click on Add Action and select Prepend a disclaimer. Enter a warning message like:

Warning: The sender of this message could not be validated and may not be the actual sender.

The text can be plain text or HTML formatted as shown in the following screenshot:

When you click Save the Transport Rule is saved in Exchange Online. It could take up to an hour to become effective. And when you receive a message where the domain validation failed a disclaimer is prepended to the email message:

Now you can look in the message header itself to figure out why validation failed. Hopefully this will give a heads-up to users there’s something wrong with the message (but it still can be legitimate message of course).

A special and warm thanks to my fellow MVP Michel de Rooij for his inspiration to write this blog 😉


External Senders with matching Display Names

One of my clients is experiencing phishing from where the external senders use a display name of one of the board members. An IT admin looks at the complete email address, but regular users are tempted to only look at the display name and will respond to the message. This way CEO/CFO fraud easily happens.

To avoid this, we can create a Transport Rule in Exchange Online that identifies external email with display names of internal recipients. So, when someone on the internet with a name like my name, a disclaimer is prepended to the message. This way recipients always know it is not an internal message and it will look something like this:

To create a transport rule there are two conditions:

  • Sender is located outside the organization.
  • From message header matches one or more internal display names.

If these conditions are met, a warning message is prepended to the email message.

Open the Exchange Admin Console and navigate to Rules under Mail flow. Create a new rule (use the More Options to add additional conditions. Select the external sender option and select the message headers matches option. Enter the ‘From’ header enter the display names as shown in the following screenshot:

In the Do the following… dropdown box select prepend the disclaimer option and enter a warning message, something like:

This message was sent from outside the company by someone with a display name matching a user in your organization. Please do not click links or open attachments unless you recognize the source of this email and know the content is safe.

You can use plain text or HTML formatting like I did:

When you click save the transport rule is saved, but it can take an hour before it becomes effective. When a new message arrives from someone with a similar display name a warning message is added to the email message.

Hopefully this will alert users that the email is not an internal message but comes from the Internet (but it can still be a valid message of course)

on-Premises Azure Active Directory Password Protection

Last year I wrote a blogpost on password in Azure Active Directory (Choose a password that’s harder for people to guess – https://jaapwesselius.com/2018/10/15/choose-a-password-thats-harder-for-people-to-guess/) in which I mentioned the banned password lists and the Azure AD Password Protect feature. Back then this was only for Azure AD, but right now it is also available for on-premises Domain Controller as well (for some time already). It is possible for on-premises Domain Controllers to use the password protect functionality in Azure AD and thus block the possibility to use weak passwords in your on-premises environment. Let’s see how it works.

The password protection feature on-premises uses a Password Protection Agent that’s running on the on-premises Domain Controllers. When a user initiates a password change, the new password is validated by the Azure AD Password Protection agent, which request a password policy from the Azure AD Password Protection proxy service. This Password Protection service requests a password policy from Azure AD. The new password is never sent to Azure AD. This is shown in the following picture (borrowed from the Microsoft website):


After receiving the password policy, the agent returns pass or fail for the new password. In case of fail the user must try it again.

Installation of the password protect consists of two steps:

  • The Azure AD Password Protection Proxy service using the AzureADPasswordProtectionProxySetup.exe software installer. This is installed on a domain joined computer that has access to the Internet and proxies the password policy request to Azure Active Directory.
  • The DC Agent service for password protection by using the AzureADPasswordProtectionDCAgentSetup.msi package. This runs on the Domain Controllers and send the password policy requests to the server running the proxy service.

Both can be downloaded from the Microsoft download center on https://www.microsoft.com/en-us/download/details.aspx?id=57071

Password Protection Proxy Installation

The first step is to install the password protection service. This server should be able to access Azure AD and since the Domain Controller does not have an internet connection this should be installed on a separate server. In my lab environment I have installed the password protection service on the Azure AD Connect server.

Installation of the password protection proxy is straightforward; you can use the GUI or the command line setup with the /quit switch for unattended install (and Server Core). After installation use PowerShell to register the proxy in Azure AD by using the following commands:

[PS] C:\> Import-Module AzureADPasswordProtection
[PS] C:\> Register-AzureADPasswordProtectionProxy -AccountUpn 'administrator@tenant.onmicrosoft.com'

This command can work when you have MFA enabled for admin accounts, if you don’t require MFA on your admin accounts (which is a bad practice IMHO) you can use the following command:

[PS] C:\> $globalAdminCredentials = Get-Credential
[PS] C:\> Register-AzureADPasswordProtectionProxy -AzureCredential $globalAdminCredentials

The last step is to register the forest in Azure Active Directory. This is very similar to the registration process of the proxy service. You can use the following PowerShell commands to register the forest:


[PS] C:\> Register-AzureADPasswordProtectionForest -AccountUpn ‘yourglobaladmin@yourtenant.onmicrosoft.com’

Again, when MFA is not enabled you can use the following command to register your forest in Azure AD:

[PS] C:\> $globalAdminCredentials = Get-Credential 'yourglobaladmin@yourtenant.onmicrosoft.com'
[PS] C:\> Register-AzureADPasswordProtectionForest -AzureCredential $globalAdminCredentials

Note. A multi-forest scenario is supported for the Password Protection service, you can install multiple forest using these commands. Multiple domains against one tenant is supported, one domain against multiple tenants is a not-supported scenario.

Some remarks:

  • The server where the password proxy agent server is installed should have .NET Framework 4.7 or higher installed.
  • For high availability it is recommended to install the password protection agents on multiple servers
  • The password protection proxy supports an in-place upgrade, so a newer version can be installed without uninstalling the previous version.

So how does this work, and how does the password protection service find the proxy server (or servers)?

When the Password Protection Proxy is installed it is registered in Active Directory with a well-know GUID. The Password Protection Agent checks Active Directory for this well-know GUID and finds the server where the Password Protection Agent is installed.

You can use the following PowerShell commands to find the Password Protection Proxy:

$SCP = "serviceConnectionPoint"
$Keywords = "{ebefb703-6113-413d-9167-9f8dd4d24468}*"
Get-ADObject -SearchScope Subtree -Filter {objectClass -eq $SCP -and keywords -like $Keywords }

It returns the server, and you can use ADSIEdit to inspect the computer:

Azure AD Password Protection Proxy SCP

This is much like how domain-joined Outlook clients find the Autodiscover SCP in Active Directory.

Installing the DC agent service

When the proxy service is installed and registered the Domain Controller agent service can be installed. It is just an MSI package that can be installed (using the GUI, accept license agreement and click install) or you can install it on the command line using the following command (use elevated privileges):

C:\> msiexec.exe /i AzureADPasswordProtectionDCAgentSetup.msi /quiet /qn

Note. Installation of the DC agent requires a restart, but you can use the /norestart switch to reboot at a more convenient time.

After rebooting the Domain Controller the password protection service is ready for use.

Some remarks:

  • Azure AD Password protection service requires an Azure AD Premium P1 or P2 license.
  • Domain Controllers should be Windows 2012 or higher.
  • Domain Controllers should have .NET Framework 4.5 or higher installed.
  • You never know which Domain Controller is going to process a password change. Therefore, the Password Protection service need to be installed on all Domain Controllers. For a straightforward environment this should not be a problem, but for large enterprises with lots of DC’s it can be an issue (I deliberately do not that about security officers at this point :-))
  • Both the proxy service and the DC agent support an in-place upgrade, so a newer version can be installed without uninstalling the old version.

Testing the Azure AD Password Protection service

So, after installing the Password Protection Proxy and the DC agent it’s time to test which is relatively simple. Logon to a domain-joined workstation, use CTRL-ALT-DELETE to change the password. When using a simple password like “Summer2019” or something it fails with the following error message.

Unable to update the password

From this moment on it is no longer possible to use weak passwords, locally enforced by Azure Active Directory and again a step closer to a safer environment.