Tag Archives: authentication

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 (https://portal.office.com) 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

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 include:spf.protection.outlook.com -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:

Selector1._domainkey.domain.com CNAME selector1-domain-com._domainkey.tenant.onmicrosoft.com
Selector2._domainkey.domain.com CNAME selector2-domain-com._domainkey.tenant.onmicrosoft.com

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.

Azure AD Connect Pass-Through Authentication

At Ignite 2017 it was announced that Pass Through Authentication (PTA) has reached General Availability (GA) so it is a fully supported scenario now.

But what is PTA? If Office 365 there are Cloud Identities, Synced Identities and Federated Identities. The first two are authenticated in Azure Active Directory, the last one is authenticated against on-premises Domain Controllers. For this to happen you need an ADFS infrastructure, consisting of multiple internal ADFS servers and multiple WAP (Windows Application Proxy) servers in the DMZ acting as ADFS proxies. Oh, and all servers need to be load balanced as well to provide redundancy and scalability.

PTA on the other hand is built on top of Azure AD Connect, and as such an interesting extension of the Synced Identities. PTA installs an agent on the Azure AD Connect server (AuthN agent) which accepts authentication requests from Azure AD and sends these to on-premises Domain Controllers. The advantage of authentication against on-premises Domain Controllers is that no passwords (or password hashes to be more precise) are stored in Azure Active Directory.

My first thought was how an authentication mechanism based on an asynchronous replication tool (Azure AD Connect synchronizes accounts every 30 minutes, and passwords within 2 minutes) ever be a reliable and safe solution. The last thing you want to happen is that you cannot authenticate to any service in the Microsoft cloud, because your Azure AD Connect server is busy doing other stuff (like automatically updating its engine for example ).

My second thought was how secure this could be. There’s no inbound connection to the Azure AD Connect server, there’s only an outbound connection on ports 80 (only used for SSL certificate revocation lists) and 443. And the communication itself should be secured as well, so…. But now that PTA is generally available more information becomes available, and things become clearer.

Authentication flow

For authentication to happen PTA uses a ‘service bus’ in Azure. The service bus is a standard Azure solution where application can store system messages in the service bus and where other applications can use these system messages. Using a service bus, you can create an asynchronous but reliable communication mechanism.

When logging to an Office 365 service the credentials are requested by Azure Active Directory, nothing new here. The credentials are encrypted and stored in the service bus. The AuthN agent on the Azure AD Connect server has a persistent connection to Azure AD and to the service bus, and retrieves the encrypted credentials from the service bus, decrypts them and presents them to the on-premises Domain Controller. The Domain Controller response (success, failure, password expired or user locked out) is returned to the AuthN agent and stored it on the service bus. Azure AD picks up this response and the user can continue working (or not of course, depending on the Domain Controller response).


Continue reading Azure AD Connect Pass-Through Authentication