Category Archives: Office365

Implementing Exchange Online Protection for on-premises Exchange Part I

With the ongoing growing number of (successful) phishing attacks entering the organization via email, there’s an increasing demand for a rock-solid message hygiene solution. In my opinion there are very little on-premises solutions that do a great job, and very little cloud solutions. Google has a great message hygiene solution, but Microsoft’s Exchange Online Protection (EOP) is getting better and better each year. Not surprisingly since both Google and Microsoft can invest a tremendous amount of R&D money in their message hygiene solution.

A lot of my on-premises customers are currently looking at Exchange Online Protection (EOP) and are thinking about implementing EOP on a short term. In this blogpost I will focus on implementing EOP when using on-premises Exchange server (2010 or higher). An existing implementation can look something like this:

Exchange OnPremises

There’s an Exchange mailbox server on-premises, and in the organization’s DMZ there’s a mail relay server. In my environment this is an Exchange Edge Transport server, but this can be any SMTP server of course. MX records are pointing to the Edge Transport Server in the DMZ, the Internet Send Connector is using the Edge Transport Server as the source transport server. Between the Mailbox server and the Edge Transport server there’s an Edge Synchronization running to keep the Edge Transport server up-to-date with internal information.

The MX record here is pointing to smtphost.exchange2019.nl (you can guess the version I’m using 😊) and this is also the outbound server. The SPF record is pretty simple in this scenario since there’s only one egress point for my email, so the record is V=spf1 ip4:176.62.196.247 -all.

At this point there’s no DKIM signing or verification (not available in on-premises Exchange) and there’s also no DMARC record.

Exchange Online Protection

Exchange Online Protection is Microsoft message hygiene solution. Before EOP it was called Forefront Online Protection for Exchange (FOPE). The original version was created by FrontBridge, which was acquired by Microsoft in 2005.

You can get a separate EOP subscription, but EOP is automatically part of any Exchange Online subscription, so you must do the math to figure out the best value for money.

EOP can be used for inbound mail and for outbound mail. To implement EOP for inbound mail it’s just a matter of changing the MX records so that they point to EOP instead of your on-premises mail servers. For outbound mail you have to change the Internet Send Connector to use EOP as a smart host. All outbound email will then be forwarded to EOP and delivered to the intended recipients by EOP.

In my lab environment I have been working with Edge Transport servers since the beginning. From a message hygiene perspective, they do a great job when it comes to connection filtering, but other than that message hygiene is so-so.
The desired configuration with Exchange Online Protection is as follows:

Exchange 2019 EOP

After signing-up for Exchange Online Protection you must configure it. The first step is to configure a new domain in the Microsoft 365 Admin Center. When the domain is added and validated it will automatically appear in Exchange Online Protection as an Accepted Domain.

When you click on the domain in the Admin Center it will open another window with the appropriate DNS settings for this domain as shown in the following screenshot (click to enlarge):

eop_domain

Directory Synchronization

It is a Microsoft recommendation to implement directory synchronization using Azure AD Connect when implementing Exchange Online Protection. If you do, all mailboxes in the on-premises Exchange environment are known in EOP as contacts and can be individually managed in EOP.

Inbound mail flow

Before the MX record can be changed to EOP, a Send Connector should be created from EOP to the on-premises Exchange server. This connection is encrypted using TLS, so a 3rd party certificate is recommended.

To create Send Connector from EOP to your on-premises Exchange environment, open the Exchange Admin Center (in Office 365), select mail flow and click connectors. If this is a new EOP environment, you should see nothing.

Click the + icon to add a new connector and in the additional window select Office 365 in the From: dropdown box and select Your organization’s email server in the To: dropdown box as shown in the following screenshot (click to enlarge):

add-eop-send-connector

Click Next to continue. In the new Connector windows, give the new connector a name like “EOP to your organization” and click Next to continue. In the following window you have to select when to use this connector. Leave the default radio button on “For email messages sent to all accepted domains in your organization” and click Next to continue. In the next window, specify the name of the host where EOP should deliver all messages to. In my environment this is my Edge Transport server so I enter the FQDN smtphost.exchange2019.nl as shown in the following screenshot (click to enlarge):

EOP-Route

Click Next to continue. The following window is about TLS. The default is to enforce TLS and use certificates from a valid third-party CA. Accept the defaults and click Next to continue. The connector is now fully configured, review all settings and click Next to create the connector.

When the connector is created it should be validated. This is to ensure the connector is working as expected and you should do this before making the MX change. Use the + icon to add an email address in the on-premises Exchange environment and click Validate. If the connector is configured correctly, the validation should be successful and the email address you’ve entered will have received a validation message (click to enlarge)

EOP-Validate

The connector is now ready for use. After changing the MX record in public DNS to the FQDN as found in the Office 365 Admin Center (which is something like yourdomain-com.mail.protection.outlook.com) inbound mail will now be protected by Exchange Online Protection.

When sending an email from Gmail to my Exchange environment and checking the header of the received message it is clearly visible that mail flow is now via Exchange Online Protection (click to enlarge):

eop-headers

Summary

In this blogpost I’ve shown you how to implement Exchange Online Protection as a message hygiene solution in front of your on-premises Exchange environment. The process will be similar if you are using a different mail solution but want to implement EOP before your solution.
In part II I will explain the steps when you want to implement EOP for outbound messaging.

Connecting to remote server outlook.office365.com failed

In a previous blog I explained how to enable MFA for Admin accounts. This is a great security solution, but unfortunately it breaks Remote PowerShell for Exchange Online.
When you try to connect to Exchange Online using the following commands:

$Cred= Get-Credential
$Session= New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://outlook.office365.com/PowerShell-LiveID -Credential $Cred -Authentication Basic -AllowRedirection

It fails with the following error message:

New-PSSession : [outlook.office365.com] Connecting to remote server outlook.office365.com failed with the following error message : Access is denied. For more information, see the about_Remote_Troubleshooting Help topic.
At line:1 char:11
+ $Session= New-PSSession -ConfigurationName Microsoft.Exchange -Connec …
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : OpenError: (System.Manageme….RemoteRunspace:RemoteRunspace) [New-PSSession], PSRemotingTransportException
+ FullyQualifiedErrorId : AccessDenied,PSSessionOpenFailed

As shown in the following screenshot:

connecting-failed

To overcome this issue, Microsoft has a special Exchange Online PowerShell module that supports Multi Factor Authentication. You can download this from the Exchange Admin Center in Exchange Online by selecting hybrid in the navigation pane as shown in the following screenshot:

MFA-Portal

Click Configure followed by Open to download and start the setup application. Click Install to continue. The Exchange Online PowerShell module will be automatically installed in seconds and when finished it will automatically open a PowerShell window as shown in the following screenshot:

EXO-PSSession

You can now use the Get-EXOPSSession -UserPrincipalName admin@tenant.onmicrosoft.com command to logon to Remote PowerShell. A separate windows will be opened requesting your tenant credentials, followed by the MFA option you’ve configured.

If all is entered correctly the Remote PowerShell for Exchange Online is opened with MFA enabled.

 

Choose a password that’s harder for people to guess

When you’ve implemented Self Service Password Reset and a cloud user (i.e. an account that only lives in the Microsoft cloud, not an on-premises Active Directory account) wants to change his password, there’s a chance the user will see the following error message:
“Choose a password that’s harder for people to guess”

pass1word-guess
The odd thing is, when the user changes his password in the SSPR it even says the user is using a strong password as shown in the following screenshot:

pass1word

Note. I tried this with several combinations, like Pass1word, P@ssW0rd and Spring2018.

A similar error message can be “Unfortunately, your password contains a word, phrase or pattern that makes it easily guessable. Please try again with a different password.” as shown in the following screenshot:

guessable

The ‘problem’ here is that the user is hitting the ‘banned password list’ in Azure Active Directory. This banned password list is a list of over 1,000 passwords that can easily be guessed, and as such vulnerable for password spray attacks. These passwords are simple words like spring, summer, autumn, winter, football, company name, qwerty, 123456, welcome, zaq1zaq1 etc etc etc. There’s a list of most common passwords on WikiPedia. Of course there are several variations of passwords, password, Pass1word, Pass!word, Passw0rd, you name it, but Microsoft is using normalization techniques to filter out all replaced characters and thus block these passwords.

Banned passwords are part of the Azure AD Password Protection feature, a feature that’s still in preview at the time of writing (October 2018). When you logon to the Azure Portal (https://portal.azure.com) and navigate to Azure Active Directory | Authentication Methods (in the security section) you’ll see the Azure AD Password Protection feature:

password_protection

The banned password list is enforced by default, there’s no way to disable it. If you have an Azure AD Premium license, you can also use a custom banned password list and maintain you own list of words or phrases that you don’t want to be used as a password.

Summary

If your users run into the Choose a password that’s harder for people to guess error message when changing their password in Azure AD or Office 365, they are hitting the banned password list as part of the Azure AD Password protect feature. A feature that’s enforced by default, and implemented by Microsoft as a means to improve security.
This feature is available for cloud users only by default, but if you have implemented self service password reset (SSPR) with password writeback it also works. The nice thing is, it can also be extended to on-premises Active Directory for password changes on-premises. Nice topic for an upcoming blog.

Improved Secure Score in Office 365 tenant

In a previous blogpost I explained about the Microsoft Secure Score and how this indicates the level of security in your Office 365 tenant.

My initial score was only 70, which is pretty low. By implementing Self Service Password Reset and MFA for Admin Acccounts the Secure Score was increased to 122. It could have been a couple of point higher when enabling MFA for all users, but not all users have licenses in Office 365.

I’m curious to see what improvements I can make in the Exchange Online part and how this will influence the Secure Score. Stay tuned 🙂

secure-score-122

Azure AD and Office 365 Password writeback

My previous blogpost was about the Self Service Password Reset (SSPR). A nice feature for cloud identities, but this doesn’t work if you have synchronized identities or federated identities. These are managed in your on-premises Active Directory, so for SSPR to work you need to implement a password writeback solution.

Luckily this feature is available, but the standard Office 365 licenses do not include password writeback functionality. You this you need an Azure AD Premium P1 or Azure AD Premium P2 license. Enterprise Mobility + Security (EMS) E3 does include Azure AD Premium P1, EMS E5 does include Azure AD Premium P2.

To implement password writeback, you need to have SSPR up-and-running. To configure password writeback you have to run the Azure AD Connect wizard.

Note. Make sure you always have the latest version of Azure AD Connect running. Even better, use the auto update feature of Azure AD Connect to make sure you’re up-to-date. At the time of writing the latest version of Azure AD Connect was 1.1.882.0 (as of Sept. 8, 2018).

Start the Azure AD Connect wizard and select the Customize Synchronization Options. Follow the wizard until you reach the Optional Features. Check the Password Writeback option as shown in the screenshot below and click Next to continue.

optional_features

Follow the wizard until the configuration is complete and click Exit to finish the wizard and store the new configuration.
The service account that’s used by Azure AD Connect needs the appropriate permissions in your on-premises Active Directory to store the new password that has been set in Azure AD.
To find out which service account is used by Azure AD Connect, start Azure AD Connect and select View Current Configuration and check the account as shown in the following screenshot:

View_Current_Configuration

The following permissions need to be granted to the service account on either the domain object, or on an OU if you want to scope the permissions:

  • Reset password
  • Change password
  • Write permissions on lockoutTime
  • Write permissions on pwdLastSet

Open Active Directory and Computers, enable Advanced Features, select the properties of the domain, click on Security, click on Advanced and click Add.

Select the service account that was retrieved earlier under Principal and in the applies to dropdown box select Descendent User Objects. Check the following options:

  • Reset password
  • Change password
  • Write lockoutTime (scroll down)
  • Write pwdLastSet (scroll down)

Click on OK to apply the changes to Active Directory and close any following pop-up boxes.

Permission_Entry

To test the password write back option, follow the same procedure as in the SSPR blogpost. After you have changed your password, it is written back to your on-premises Active Directory and the following event is written to the eventlog of the Azure AD Connect server.

EventID_31001

Summary

In this blogpost I’ve shown you how to implement password writeback in your synchronized Azure AD environment. One prerequisite is that you need to have Self Service Password Reset implemented, and you need to have an Azure AD Premium P1 or Azure AD Premium P2.