WARNING
This post may/may not include actual sound parenting advice. Don’t get triggered.
You’re the proud parent of a bustling little rascal who is growing faster than you can stand it. This kid is now becoming an adult and it’s time to start earning that keep. You’ve been paying for this man-child’s upbringing with food (storage), your sanity (server overhead), and travel to and fro from every single soccer game, violin practice, and friend’s house (network) and you just can’t take it any longer. You’ve decided to kick this adult out of your basement, cancel his Xbox Live Subscription, and make him wash his own clothes. But you can’t exactly do that because you have a big heart and other gushy stuff.
So what do you do?
Well, you hear that all of your parenting comrades have had the same complaints with their man-children but they’ve found a way to manage their complacent, apathetic offspring. You’re excited as Susan tells you about a nanny service that will take care of all of those tedious tasks that have plagued you for years. It will cost you twice as much but offer half the headache. You’re jubilant as you sign up to start the process of integrating the nanny into the daily life of your kid. Welcome to Exchange Hybrid.
\\\He Has Potential
Although this is a horrible analogy and I’m actually ashamed for even writing it, let’s just pretend I’m one of your clients (probably named Karen) and you have to be nice and courteous no matter how ridiculous I am. Mmkay? First, you have to set up the Hybrid between your on prem Exchange Environment (your lazy son) and Exchange Online (your lazy–but much cooler–son). There are many ways to go about this and even more variables in your own environment that can make a world of difference in how you configure this. But in this post, I’d like to cover one vulnerable area you may encounter with an Exchange Hybrid setup and help out my fellow parents IT professionals: blocking direct delivery to onmicrosoft.com (and mail.onmicrosoft.com).
\\\The Scenario
Your current environment has a third party Mail Security Product like Proofpoint, Mimecast, or Cisco. Your mailflow looks like this:
Cool. It all works great because your third party mail security product is a great mom who is also a blackbelt and former green beret who can take down all of the bad actors before they ever corrupt your little ray of sunshine. But now, you’re moving your kid out. To ease them into it, you can’t do it all at once or the poor thing will implode. You want to keep things mostly the same, but add in the new home for your son.
Everything looks good in this scenario because your assassin of a mom-friend mentioned above is still taking down the baddies for cloud and on prem mailboxes. You didn’t have to change your MX record, Autodiscover config, or much else and your offering the same protection for both. Sounds like magic and we like magic.
\\\Too Easy…I knew it!
What aren’t you telling me?
Wait…kids poop?
I did not know that going into this, but that changes everything.
Surprise! While your primary SMTP domain is still protected by your third party mail sec—okay, if I have to type that out one more time I’m going to slap pet a kitten. Let’s call it TPMSP, or Teresa for short. So much better. Let’s try this again.
While our primary SMTP domain is protected by Teresa, we get a couple more domains with Exchange Online and our hybrid configuration: <domain>.onmicrosoft.com and <domain>.mail.onmicrosoft.com. These 2 domains are maintained by MS and are not routable to Teresa. Teresa cannot protect you. The horror! What this means is that each mailbox has your primary SMTP domain as well as 2 more aliases that bad actors can use to go around your email protection. If a nefarious hooligan wants to be a bad influence on your little Timmy, they can send emails to either onmicrosoft.com domains and never run into Teresa. This makes mama mad.
Before you go looking for the receipt to return your new baby, there is a way to take care of this and allow Teresa to shelter your little dumplin’ with her protection once again.
\\\So Easy…I knew it!
You may think, I’ll do what I’ve always done and go play with those Transport Rules. Sadly, this doesn’t work. Transport Rules are processed after the onresolveMessage event where the recipient email address is resolved to the primarySMTPAddress.
To take care of business, all we need to do is a create an inbound partner connector in Exchange Online that will reject messages that are directly delivered to your onmicrosoft.com domains, unless they come from your internal Exchange servers. We can accomplish this by requiring that the certificate used for the autenthication has your domain name. Since we all love the shell of power, I’ll show you how to do it with the GUI and with PS.
\\\Over-Easy…I Like It!
Navigate to the Exchange Admin Center and go to your connectors. How you get to the “connectors” section is subject to change as MS loves to introduce a “new and improved” layout and user experience whether you like it or not. Currently, the Connectors tab is under Mail Flow. Click the + icon and choose From Partner Organization and To Office 365. Click Next.
On the next screen, give it a different name than I did and click Next.
Choose “Use the sender’s domain” to identify the partner organization and click Next.
Hit that + icon and type * for the sender domain and click “OK.” Now that we’ve added the domain, click Next.
On the Security Restrictions screen, go ahead and check that box to require the subject name in the cert and type in *.yourdomain.com. But you do know to use your actual domain here, right? Just checking…
Review all of your hard, laborous work and then click Save when you’re ready.
Give it a whirl and send an email from something other than your internal Exchange server to your .onmicrosoft.com domains and see what happens. This makes mama happy.
\\\easy p-sheasy
And of course, we can do da ting with PowerShell too. Thankfully, this one is really straightforward. Connect to Exchange Online via PowerShell and then run:
New-InboundConnector -Name 'Block the Baddies' -ConnectorType Partner -SenderDomains * -TlsSenderCertificateName '*.yourdomain.com' -RestrictDomainsToCertificate $true -RequireTls $trueYour son is now ready to face the world and embrace his responsibility as a mature citizen of Earth. You think your son is in a good position with your good looks and intellect, but just in case, he’s still protected by the ever-watching, ninja protector Teresa.