If you have an on-premises mail environment that you are protecting with Exchange Online Protection (EOP) then you’ll need to create some connectors in the cloud. This article is going to focus on EOP Outbound Connectors and how they deliver mail when configured with a smart host.
Keep in mind that with EOP connectors, the naming convention is EOP centric (from EOPs point of view). When we talk about incoming mail, we are referring to mail that has originated on the Internet and is destined to our on-premises mail servers. This Internet originating message will be directed to EOP first because this is where your MX record is pointing. Once EOP processes the message, it needs an Outbound Connector to deliver the message to your on-premises mail environment. Here’s what we’re looking at.
Because your MX record will be pointed towards EOP, the EOP Outbound Connector (type is on-premises) will need a smart host to be able to deliver mail to your on-premises mail environment. For the smart host, you can enter either an IP or a Fully Qualified Domain Name (FQDN).
Customers that use an FQDN as the smart host typically ask me the following question.
How does the lookup for the FQDN smart host work? Does the EOP Outbound Connector look up the MX record or the A record for the smart host FQDN?
The Outbound Connector respects RFC 5321 section 5 which clearly states the following must happen once the recipient domain is known.
Note: In our scenario we are using a smart host and not the recipient domain to determine routing, however this same MX/A logic still applies.
Because the EOP Outbound connector first does an MX lookup on the smart host FQDN, MX priorities are also respected just like you would expect. This in a nutshell is exactly what an EOP Outbound Connector does when it finds an FQDN entered for the smart host.
Configure custom mail flow by using connectorsCreate required connectors to set up basic email flow through EOP
I’m often asked how to prevent an End user Spam Notification (abbreviated as ESN from this point on) from being sent to a distribution list (abbreviated as DL from this point on). Before getting to the answer, let’s start off with some background information on ESNs to see why this question comes up in the first place.
If you are using the online quarantine in Exchange Online Protection (abbreviated as EOP from this point on), an ESN is one method you can use to give your end users the ability to release items from their quarantine on their own. At a minimum of once a day (can be configured to be longer), ESNs will be sent to users that have received mail in their online quarantine since the last time an ESN was sent. The ESN will contain links that can be used to release any of the messages from their quarantine to their inbox. Here’s an example of an ESN.
Problems can arise when an ESN is sent to a DL as this is typically not desired behavior. Let’s take a look at an example to see why this can be a problem.
We have a company that is using EOP Stand Alone (not Exchange Online) to protect their on-premises Exchange environment which hosts all of their mailboxes. This company is also not using Microsoft Azure Active Directory Sync (abbreviated as DirSync from this point on). A spam message destined to a DL in the company is received by EOP and quarantined in the cloud. In this scenario EOP does not know that the recipient email address is a DL, it just sees an email address.
When the ESN is generated, EOP sends it to the recipient address which happens to be a DL. The on-premises Exchange environment receives the ESN which is destined to a DL, expands the DL, and then delivers the ESN to everyone in the DL. Now let’s say one of users decides they would like to release a quarantined message, and so, they click the Release to Inbox link in the ESN. EOP will release the message from the quarantine and send it to the DL, delivering the message to all members of the DL. This action of a single user can cause a quarantined message to be released to many users.This is certainly not wanted behavior, or at least it usually is not.
There are a few different ways this can occur. The most common is when a DL exists on-premises and is not being synced to Office 365. This could happen if DirSync is either not being used, or has been configured not to sync certain objects, which could include DLs, to Office 365. In the end, if Office 365 does not know about a DL, it will not expand it in the cloud and you will see this behavior.
If the DL exists in Office 365, or is being synced with DirSync from on-premises to your Exchange Online Office 365 tenant, you will not have this issue because the DL will be expanded in the cloud so each member will get their own separate ESN.
Lucky for you preventing this behavior is quite easy. ESNs are always sent from quarantine@messaging.microsoft.com, so all we need to do is to stop this address from sending to our distribution lists. The steps I list here are applicable to Exchange Server 2010 and Exchange Server 2013.
You could easily write a loop in PowerShell which could set this attribute for all your distribution lists in one swoop, but I’ll leave that to you to script for your environment.
Last month I attended TechEd North America 2014 in Houston Texas. In addition to attending some incredible sessions, I also presented one on Exchange Online Protection. This article contains a summary of the sessions I found to be interesting and valuable to those who work with Exchange Online and Exchange Server. As an added bonus, I have also included sessions that any good geek like myself would enjoy.
Exchange / Email related
Protecting Your Organization with Microsoft Exchange Online Protection (EOP)This is the session that I presented this year at TechEd. It contains both 200 and 300 level content and applicable for both those of have worked with EOP and those who have not.
Building a Hybrid Microsoft Exchange Server 2013 Deployment in Less than 75 MinutesVery valuable session for those that need to learn about hybrid deployment and don’t have much time to learn.
Data Loss Prevention (DLP) in Microsoft Office 365Great information on how DLP works and how it integrates with Exchange Online Protection.
Encryption in Microsoft Office 365Office 365 Encryption is a policy based encryption for Exchange Online Protection.
Future Look at Microsoft Exchange ServerVery interesting session that touches on both Exchange Server and Office 365.
Microsoft Outlook Connectivity: Current and FutureThis session takes a close look at how Outlook connects to Exchange Server and what is planned for the future.
Power Shell
Windows PowerShell Unplugged with Jeffrey SnoverGreat speakers that do an exceptional session on PowerShell. They cover 100, 200, and 300 levels. Something for everyone!
Windows PowerShell Best Practices and Patterns: Time to Get SeriousGreat PowerShell session that gets quite technical.
Geeky sessions that Andrew liked
Pass-the-Hash: How Attackers Spread and How to Stop ThemEye opening session, extremely interesting and quite scary.
2014 Edition: How Many Coffees Can You Drink While Your PC Starts?Very interesting session if you are interested in troubleshooting slow Windows boot times.
Case of the Unexplained: Troubleshooting with Mark RussinovichMark has about 6 “Case of the Unexplained” sessions that he’s done over the years. They are extremely technical and incredibly fascinating. They usually revolve around troubleshooting strange Windows issues with Sysinternals tools.
What’s New in Windows Server 2012 R2 Hyper-VFascinating session if you use and are interested in Hyper-V. Server 2012 R2 brings some awesome features to Hyper-V.
Windows 8 Security InternalsExtremely fascinating talk about Windows 8 security. The session opens with examining user tokens and comparing regular tokens to elevated tokens.
Mark Russinovich and Mark Minasi on Cloud ComputingThis session is essentially an interview with Mark Russinovich on Microsoft Azure. Very interesting if you are interested in Azure.
TWC: Malware Hunting with Mark Russinovich and the Sysinternals ToolsAs I’m sure you can tell from this article, I find Mark Russinovich talks to be extremely interesting and this is no exception. It focusses on the Sysinternals tool suit and their use for examining Malware on an infected machine.
TWC: Live Demonstration: Hacker Tools You Should Know and Worry about in 2014Some very interesting tools that make malicious attacks quite easy. One of the demos shows how easy arp and dns poisoning attacks can be to implement.
For those that aren’t aware, all TechEd content is available on Channel 9 and free for anyone to watch. You can check out all of the content from TechEd events here.
I was recently involved in a case where a customer needed more information about the certificate that EOP presents. Being the nice guy that I am, I wanted to share it here!
As mentioned in this article, the CN of the certificate that EOP presents is mail.protection.outlook.com. The certificate also contains the following Subject Alternative Names (SAN).
Of course, these can also be seen in a network trace.
Finally, this is the certificate path.
The Baltimore CyberTrust Root certificate can be downloaded from https://cacert.omniroot.com/bc2025.crt.
Note As a best practice, we recommend that you don't hard-code trusted root lists for certificate validation. Instead, you should use policy-based root certificate validation that can be updated as industry standards or certificate authorities change.
Hello readers!
In this post I will be covering TLS and certificates and how they apply to EOP. Usually when organizations force TLS on mail to and from a partner they will not restrict the connection based on the certificate that the recipient server presents. Instead, they will ensure either the connecting IP or domain is correct, but after that the presented certificate isn’t restricted, or if it is the check is only to ensure it has been issued by a trusted CA and has not expired. Now, what if you have a security policy that requires checking the certificate that the partner server presents? With EOP in the middle, this certificate changes and if your partners are expecting to see your certificate when they send or receive mail from you they will need to update their configurations. Let’s take a look at this with an example.
In this example, Contoso wants to send an email message to Fabrikam. Contoso will verify that the certificate name presented by Fabrikam is mail.fabrikam.com. If the certificate is not correct, Contoso will drop the connection and will not send the message. Here's a visual.
When this connection is established, Contoso sends its certificate, mail.contoso.com to Fabrikam, and Fabrikam sends its certificate, mail.fabrikam.com, to Contoso. Contoso validates that the certificate presented by Fabrikam is mail.fabrikam.com and if instead a different certificate is presented, Contoso will drop the connection.
Now, let’s see what happens when Fabrikam implements Exchange Online Protection.
Now, the MX record for Fabrikam is pointing to EOP, so when Contoso wants to send an email to Fabrikam, Contoso will be communicating with the EOP servers. When the connection is established Contoso will present its own certificate, mail.contoso.com, but since Contoso is communicating with EOP, EOP will present its certificate which is mail.protection.outlook.com. If Contoso has restricted TLS communications to Fabrikam to only take place if the presented certificate is mail.fabrikam.com, Contoso will drop the connection and not send mail because the presented certificate was not mail.fabrikam.com. Contoso will need to update their configuration to accept the certificate mail.protection.outlook.com when sending mail to Fabrikam.
To increase the geek factor of this post, if you’re a curious individual like me, you won’t want to take someones word (even Andrew’s) that the certificate presented by EOP is mail.protection.outlook.com. You instead want to see it with your own eyes…. or maybe that’s just me. In any case, this can easily be seen by capturing network traffic that flows between your on-prem servers and EOP. Here, I have captured a network trace using Wireshark of traffic between my on-premises Exchange server and EOP. Here I can see the certificate in the flesh that is presented by EOP.
Keep in mind that the EOP certificate name is only needed if you or your partner have TLS setup to require a specific certificate name to be presented. If instead you have TLS setup to look for a certificate issued by a trusted CA or even any certificate, then the EOP certificate name will not be of interest to you.
One thing I’ll note because I’ve received a lot of questions about it. You are currently not able to import your on-premises certificate to EOP and in turn have EOP present that certificate to partners instead of mail.protection.outlook.com.
I find that most of the clients I deal with do not actually look at the presented certificate when TLS is established, however, some clients do and this article is meant for them.
Cheers!
Andrew
In my current role I work with customers who are implementing Exchange Online Protection. From working on the ground floor I have come to realise that there are a lot of intricacies with the product that can often only be discovered with experience. Our documentation on TechNet is quite good but can easily feel overwhelming when you are looking for something specific. Not everyone gets to work with someone from my group when they deploy EOP which is where the idea for this blog came from. We would like to share our knowledge and best practices with a broader audience.
Sit back, bookmark this page, and enjoy the knowledge!