Tag Archives: TLS

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.

Exchange 2010 and TLS 1.2

In a previous blogpost I discussed an issue I had with Outlook 2010 and TLS 1.2. At the same time this reminded me that Microsoft will remove support for TLS 1.0 and TLS 1.1 in Office 365 on October 31, 2018 as communicated in https://support.microsoft.com/en-us/help/4057306/preparing-for-tls-1-2-in-office-365. This means that when you have communication issues with Office 365 because of an older and weaker protocol, you won’t get any support. Time to do some research….

Existing Exchange 2010 environment

As you may have seen on this side, I still am a big fan of Exchange 2010 and also have an pure Exchange 2010 hybrid environment up-and-running and it looks like this:

Inframan-hybrid

MX records is pointing to my Exchange 2010 Edge Transport Server (running on Windows 2008 R2), webmail and Autodiscover are routed via an F5 LTM load balancer to an Exchange 2010 CAS/HUB/Mailbox server (also running on Windows 2008 R2), and hybrid is configured directly on Exchange 2010 (for hybrid mail flow I’m using a separate FQDN, o365mail.inframan.nl) without any Exchange 2013 or Exchange 2016 server.

So, how do you test which TLS version is used by your Exchange 2010 server? In Exchange 2010 this should be done using the protocol logfiles. Message headers in Exchange 2010 do not contain enough information for showing this TLS information. So, you must enable protocol logging for the appropriate Receive Connectors and Send Connectors. In my environment this means the Default Receive Connector on the Exchange 2010 Edge Transport server (for O365 traffic from other tenants), the Default-First-Site-Name to Internet Send Connector, and both connectors between the Exchange 2010 server and Office 365 for hybrid. Analyzing the protocol logfiles can best be done in Excel (import as CSV files). When analyzing, look for a string like TLS protocol SP_PROT_TLS1_0_SERVER (when receiving) or TLS protocol SP_PROT-TLS1_0_CLIENT (when sending). When TLS 1.2 is used, look for a string like TLS protocol SP_PROT_TLS1_2_SERVER and TLS protocol SP_PROT-TLS1_2_CLIENT.

Continue reading Exchange 2010 and TLS 1.2

Exchange Resource Forest and Exchange Hybrid – Part III

In my previous two blogposts (part I and part II) I’ve explained more about the Exchange Resource Forest model and how to implement Azure AD Connect into such an environment. In this blogpost I’ll show you more about creating a hybrid environment with an Exchange Resource Forest model.

Exchange 2010 Hybrid

If you have been following my blog, or maybe my work as a consultant you most likely know I’m not a big fan of installing Exchange 2016 into an existing Exchange 2010 environment when creating a hybrid environment. It adds a lot of additional complexity since you are halfway a migration to Exchange 2016, you need network and client access changes and most likely hit users multiple times. Better is to create an Exchange 2010 hybrid scenario and when the migration to Exchange Online is done, upgrade the Exchange 2010 remains to Exchange 2016.

My Resource Forest environment is built on Exchange 2010 (that’s what most of my customers are still running) and I will create another Exchange 2010 hybrid environment, but this time built on the Exchange Resource Forest. The solution will look something like this:

image

The only more challenging part is the use of an Edge Transport server for inbound and outbound SMTP, but if your SSL certificates are ok, you’re good to go. In our example, the Edge Transport server is used for inbound and outbound SMTP, but the hybrid SMTP will be sent directly from Exchange Online to the Exchange 2010 multi-role server. Centralized Mail Transport will be used, so all mail will always go via the Edge Transport server, even outbound mail from Exchange Online.

Note. Before you continue, you have to make sure that your certificates are ok, that a valid 3rd party certificate is used and bound to IIS and SMTP, and that your load balancer is configured correctly. A common pitfall is that address translation occurs, and that all inbound connections originate from the IP address of the load balancer. In this case inbound SMTP ends up on the wrong connector, causing secure traffic between Exchange 2010 and Exchange Online to fail.

Logon to the Exchange 2010 server and download the Hybrid Configuration Wizard at https://aka.ms/TAPHCW and start the wizard by clicking the Install button.

Click the Next button a couple of times, the wizard will detect the optimal Exchange server to be used to create the hybrid configuration (this is the server where the hybrid configuration wizard is running, and is known as the ‘hybrid server’) and logon to the Office 365 tenant using a tenant administrator account as shown in the following figure:

image

Continue with the wizard, select Full Hybrid (or minimal hybrid if you need to), and create a federation trust (and enter this crazy TXT record in public DNS). When you reach the radio button for Configure my Client Access and Mailbox server window, you can select the enable centralized mail transport checkbox if you want to.

image

Select the Hub Transport server (or Mailbox server when running Exchange 2013 or Exchange 2016) that should be used for secure communication with Exchange Online. This server is configured in an Office 365 Send Connector and a Receive Connector from Office 365 is created on this server.

image

Select a proper certificate (which should already be present on the Exchange server of course), enter the Organization FQDN that’s used to access your on-premises environment (i.e. webmail.exchangefun.nl) and you’re ready to finalize the hybrid configuration wizard. The options you’ve selected in the wizard are now pushed to the Exchange server and Active Directory when you click the update button.

image

And after a minute or two the Hybrid Configuration Wizard should be finished, and of course no warning message should be shown:

image

We’ve now configured a hybrid configuration with an on-premises Exchange 2010 server that’s in a Resource Forest.

Move Mailbox

An easy way to test the new hybrid configuration is to test a mailbox move from Exchange 2010 on-premises to Exchange Online. To do so, logon to the Exchange (Online) Admin Center, go to Recipients | Migration and start a new migration batch. Select move to Exchange Online and select a user to move to Exchange Online as shown in the following figure:

image

Enter the on-premises administrator account to find a proper migration endpoint (through Autodiscover):

image

It will automatically detect and show the migration endpoint on the Exchange 2010 server:

image

Click Next to continue, enter a migration batch name, increase the bad item and large item limit if needed and follow the wizard. The migration batch is automatically started, but manually completed. I typically complete migration batches off business hours, but for a test or lab environment you can safely select to complete the batch automatically. When you click the new button a new migration batch is created, and the mailbox move is automatically initiated. When the mailbox is moved to Exchange Online you can logon to Office 365 and start testing.

image

The first test is to see if mail flows between Exchange 2010 on-premises to Exchange Online. In the previous figure the mailbox ‘Jaap Wesselius [Linked]’ is a mailbox that was not migrated, so this works fine. Checking the header of this message reveals the same:

image

The figure might be a bit blurry, but in the last column we can see that TLS 1.2 is used for communications between Exchange Online and Exchange 2010.

Sending from Gmail to the mailbox in Exchange Online reveals that Gmail sends the message to the Edge Transport server, which sends in to the Exchange 2010 server and to Exchange Online:

image

Inbound messaging is working as well. When mail is sent from Exchange Online to Gmail, we can see in the headers that mail goes from Exchange Online to the Exchange 2010 server, to the Edge Transport server and to Gmail.

image

Another important topic to test is free/busy information between Exchange 2010 and Exchange Online. When an on-premises mailbox wants to schedule a meeting with two migrated mailboxes in Exchange Online the following should be visible:

image

The Exchange 2010 server will contact Exchange Online using Exchange Web Services (EWS) to check the availability for the users Don and Duw.

Vice versa, when user Don wants to schedule a meeting the following should be visible:

image

The server in Exchange Online now contacts the Exchange 2010 server (via the load balancer) using EWS to check the availability of the on-premises mailboxes.

It happens a lot that availability information or free/busy information in the on-premises environment is not available. This can be an Autodiscover issue, a certificate issue or a pre-authentication issue in the load balancer. Enough stuff to troubleshoot in this case.

If free/busy is working properly, cross-premises Mail Tips are most likely working as well since this is also using EWS:

image

So, it looks like everything is working as expected.

Summary

In this blog post and the previous two blog posts I’ve explained more about the Exchange Resource Forest model, how linked mailboxes are related to their corresponding accounts, how to implement Azure AD Connect in a Resource Forest environment and how to setup a hybrid environment in this model.

This was built on top of Exchange 2010 but is very similar for Exchange 2013 or Exchange 2016. If all prerequisites are met it doesn’t make any difference if you’re running a single forest environment with Exchange installed or a Resource Forest model.

Since the Resource Forest is a fully supported scenario by Microsoft, the hybrid environment in a Resource Forest is fully supported as well.

In the next blog and final (part IV) of this series I’ll dive deeper into the provisioning part of linked mailboxes and Office 365.

Exchange 2016 CU9 and Exchange 2013 CU20 released

On March 20, 2018 Microsoft has released two new quarterly updates:

  • Exchange 2016 Cumulative Update 9 (CU9)
  • Exchange 2013 Cumulative Update 20 (CU20)

There aren’t too many new features in these CUs. The most important ‘feature’ is that TLS 1.2 is now fully supported (most likely you already have TLS 1.2 only on your load balancer). This is extremely supported since Microsoft will support TLS 1.2 ONLY in Office 365 in the last quarter of this year (see the An Update on Office 365 Requiring TLS 1.2 Microsoft blog as well).

Support for .NET Framework 4.7.1, or the ongoing story about the .NET Framework. The .NET Framework 4.7.1 is fully supported by Exchange 2016 CU9 and Exchange 2013 CU20. Why is this important? For the upcoming CUs in three months (somewhere in June 2018) the .NET Framework 4.7.1 is mandatory, so you need these to be installed in order to install these upcoming CUs.

Please note that .NET Framework 4.7 is NOT supported!

If you are currently running an older CU of Exchange, for example Exchange 2013 CU12, you have to make an intermediate upgrade to Exchange 2013 CU15. Then upgrade to .NET Framework 4.6.2 and then upgrade to Exchange 2013 CU20. If you are running Exchange 2016 CU3 or CU4, you can upgrade to .NET Framework 4.6.2 and then upgrade to Exchange 2016 CU9.

Schema changes

If you are coming from a recent Exchange 2013 CU, there are no schema changes since the schema version (rangeUpper = 15312) hasn’t changed since Exchange 2013 CU7. However, since there can be changes in (for example) RBAC, it’s always a good practice to run the Setup.exe /PrepareAD command. For Exchange 2016, the schema version (rangeUpper = 15332) hasn’t changed since Exchange 2016 CU7.

As always, check the new CUs in your lab environment before installing into your production environment. If you are running Exchange 2013 or Exchange 2016 in a DAG, use the PowerShell commands as explained in my earlier EXCHANGE 2013 CU17 AND EXCHANGE 2016 CU6 blog.

More information and downloads

Exchange 2010 hybrid, SMTP, SSL Certificates and Subject Alternative Names

On every Exchange server you need SSL certificates for authentication, validation and encryption purposes. For SMTP you can use the self-signed certificate. Exchange 2010 uses opportunistic TLS, so the self-signed certificate will do in this scenario. If you need to configure domain security (mutual TLS) on Exchange, you need a proper 3rd party SSL certificate for this.

SMTP communication between Office 365 and Exchange in a hybrid scenario is an example of mutual TLS or domain security. A proper 3rd party SSL certificate is needed on your Exchange server.

I was always under the impression that mutual TLS can only use the Common Name of the certificate, which in my scenario is CN=webmail.inframan.nl. After a previous blogpost there was an interesting discussion (see the comments of this particular blogpost) about this, so now it’s time to do some testing.

Originally I had a Digicert SSL certificate with Common Name CN=webmail.inframan.nl, and a Subject Alternative Name entry autodiscover.webmail.com. During the HCW I entered webmail.inframan.nl and selected the proper certificate.

It was time to renew my SSL certificate, so I added an additional SAN entry o365mail.inframan.nl.

image

Continue reading Exchange 2010 hybrid, SMTP, SSL Certificates and Subject Alternative Names