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 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
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.
While “The Resolver” would be a great nickname for a councillor, that’s not quite what we are talking about here. When processing inbound messages, Exchange Online (not EOP Stand Alone) will always resolve the recipient to the primary SMTP address before evaluating transport rules. Why does this matter? If you are writing transport rules that trigger based on the recipient, you must specify the primary address and not the secondary. If the secondary address is specified in a transport rule it will never trigger.
The exception here is if the user object and mailbox exist on-premises and you are not using DirSync. In this scenario, resolving will not take place in the cloud because Exchange Online will not be aware of the primary and secondary aliases for the user.
At a high level, here’s what inbound mail flow looks like and where resolving takes place.
If you have Exchange Online licenses, EOP will resolve all recipients of inbound mail to your environment to the primary SMTP address. Even if you do not have mailboxes in the cloud but are using DirSync, the resolving will still take place prior to rule processing.
You can easily see resolving taking place when looking at an Exchange Online Message Trace. If a message has been received that is destined to a secondary address, you will see two entries in the Message Trace for this single message. The first entry will show that the recipient address has been resolved, and the second entry will show the processing for the message as it continued through EOP.
The following is a single incoming message that was destined to a secondary address which was resolved to the primary.
This section assumes you have a hybrid setup with Exchange Online Licenses, but with mailboxes stored on-premises in Exchange and DirSync is being used to sync user objects to the cloud. This is the type of scenario you may be in if you have just configured a hybrid environment.
For our on-premises users, all email aliases are stored in Active Directory so let’s begin our journey there. Find the ProxyAddresses AD attribute for a mail enabled user. You will see something like this.
The primary address is what you see beside the uppercase SMTP. All addresses beside lowercase smtp will be the secondary aliases.
Next, let’s see if the addresses have been properly synced to Exchange Online through DirSync. This can be done in one of two ways.
Happy resolving and directory syncing!
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!
Yesterday we released details on two very exciting items, the Office 365 for business public roadmap and the First Release Program. On a personal side, I am very excited about both of these items because first, I’m a big advocate of transparency and second, updates always excite me and I love being on the cutting edge.
In the past the Office 365 for business road map was not public facing and required an NDA for customers to see. Yesterday we launched the Office 365 for business public roadmap which will give everyone a 30 to 90 day glimpse into the future of what’s coming for Office 365 for business. This page contains information on Office 365 for business features in the following self-explanatory categories.
First Release will allow customers to opt-in to receive certain enhancements first at a minimum of two weeks before customers who are not in the program. These enhancements are not beta or a preview, but final code and you will get them first being in this program! Since software updates always excite me this program is right up my alley. You can find more information about our Standard Release and First Release programs on this Office 365 release programs page.
For complete details on these please see Jake Zborowski’s (group product manager for Office 365) blog post Improving visibility to service updates.
Office Blogs
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.