New hybrid Organization Config Transfer-feature (OCT) announced

Yesterday, Microsoft announced the Organization Config Transfer feature (OCT) in the Hybrid Configuration Wizard. The feature is expected to start showing up starting late June 2018. In an ongoing effort to improve the Wizard, I believe this is a step in the right direction. Ever since the HCW was first conceived, running the HCW resulted in a series of steps which you had to (manually) run through to ensure that the Exchange Online configuration matched the on-premises configuration.

For example, you had to recreate the retention policies and tags that existed in the on-premises organization if you wanted to continue to use them in Exchange Online (and not to lose them during a migration!). The same was true for other policies like the OWA Mailbox Policy or ActiveSync Policy.

With the OCT feature, the HCW will automatically take care of that and copy the settings of the following elements to Exchange online for you:

  • Retention Policy
  • Retention Policy Tags
  • OWA Mailbox Policy
  • Mobile Device Mailbox Policy
  • Active Sync Mailbox Policy

Note: in this version of the HCW, it will only copy “new” policies. These are policies that do not exist in Exchange Online. If a policy with the same name already exists in Exchange Online, or when you update the policy in the on-premises organization after it has been copied to Exchange Online, the OCT-feature will not “sync” the policy or updates thereof across. As per statement from Microsoft, this is something for the next version of the feature.

Some might say this is only a small addition to the HCW, and while it might not (yet) benefit existing Hybrid customers, it’s a welcome addition for any consultant working on getting customers across to Exchange Online as it makes life just a little easier!

I’m looking forward to what Microsoft has more for hybrid in the future. Remember BRK3155 at Ignite 2017? There was a ton of cool new stuff announced, but only little has been delivered so far… Let’s see what Microsoft might deliver for Ignite 2018 as, traditionally, there seems to be a sprint to get a lot of new features out of the door ahead of the annual conference of conferences.

Looking forward to seeing you there!

-Michael

Blog Office 365

How to leverage (multiple) migration endpoints to speed up migrations to Exchange Online

Last week, at Microsoft’s Tech Summit in Amsterdam, I gave a talk about running Exchange Hybrid connections over the long term. In that session, I talked about securing a hybrid deployment and – somewhat related – how to best and securely publish migration endpoints to the Internet.

Following that session, someone reached out to me asking me for more guidance on the topic. Except from what I have written about migration endpoints in the Office 365 for IT Pros e-book, I couldn’t find much else on the topic, so I figured I might elaborate on it a bit further. You can read more about it over on the blog of the ENow folks.

This being said, additional information beyond what’s described in this article can be found in the Office 365 for IT Pros e-book, which you can get here, if you’d like.

 

Blog Office 365

Messages more marked as spoofed (and moved to Junk e-mail) in Office 365? You’re not alone!

Update 21/03/2018: Microsoft have dialed back on how quickly messages are marked as spoofed and, thus, moved to the Junk E-Mail folder. However, the guidance is to still properly implement SPF/DKIM/DMARC to be future proof. After all, at some point in the (near) future, Microsoft plans to turn up the aggressiveness of the filtering again -rightfully so. However, let’s hope not before communicating more clearly about this!

Over the past few days, there has been an uptake in the number of people reporting an higher-than-usual amount of legitimate messages being moved to the Junk E-Mail folder. In addition, they are marked as being spoofed as well:

While (re)moving spoofed messages is not a bad thing, moving (seemingly) legitimate messages is!

So far, there has been no formal statement from Microsoft on the matter. However, a last-minute addition to the Office 365 roadmap states that new anti-spoofing features are rolling out, therefore possibly hinting what might be causing this particular behavior:

Image: ATP Roadmap – Source

Until Microsoft confirms, we can only speculate whether the new feature is, indeed, the culprit. Fellow-MVP Brian Reid, tweeted that changes were made to Exchange Online Protection (cfr. Roadmap item), and that those trigger a new filtering behaviour where unauthenticated messages are automatically marked and junked. In other words: all messages that have not (correctly) published any of the message authentication mechanisms (SPF/DKIM/DMARC), are at risk of being flagged as spoofed.

Some of my fellow MVPs have noticed the same, and have also reported on it. Amongst them is Paul Cunningham, who runs Practical365.com, where he published an article on the matter. On that same article, Terry Zink – the owner of the anti-spoofing feature in O365 – commented, stating the following:


Image: Terry Zink’s comment – Source

Especially the last sentence is interesting: “However, the long tail of smaller senders has proven problematic”. For now, we can only guess what “smaller sender” means. My best guess would be that if you’re only sending a few messages a day. If true, that would mean a large number of the small/medium organization could fall in that category and therefore be (negatively) affected by the changes.

I look forward to seeing a more elaborate statement from Microsoft on this, possibly further outlining what you can do to revert/alleviate the impact form legitimate messages being marked.  For now, it seems you have the following options:

  1. Ask your users to add the senders to their safe list. On a side-note, this means that other protection features are bypassed too; therefore allowing actually spoofed messages to land in your inbox, should you ever receive one from such source
  2. Request the sender to correctly implement SPF, DKIM, DMARC; if possible all of them [correctly].

As Terry mentions, a lot of signals are being collected to determine if a message is legitimate or not. However, I also see an increase of messages being marked and junked, despite SPF being implemented correctly. Perhaps the machine learning systems Microsoft is using, need a bit more tweaking…?

The fact that your messages might end up in someone’s Junk E-mail folder is entirely on you. If you haven’t implemented any of the aforementioned authentication mechanisms, you’re doing things wrong. Whilst I cannot argue that setting up SPF, DKIM and/or DMARC is the right thing to do, I also cannot ignore the fact that a lot of senders haven’t done so correctly/properly/at all (choose whatever applies).

As such, more legitimate emails are now being caught whereas they should not be. The behavioral change in EOP/ATP, which seems to be causing quite the stirr, should have been communicated more clearly by Microsoft. At the very least, they should have given administrators the opportunity to prepare for this change, communicate it to their users or – if not already – implement SPF/DKIM/DMARC.

In the end, all Microsoft is trying to do is improve security for Office 365 recipients (and beyond). There’s no doubt that the industry is moving towards a more restrictive way of filtering messages to counter the new methods attackers use, and perhaps Microsoft was the first to do so. Instead of fighting this change, I’m all for making sure that you’ve correctly setup message authentication; but I also believe Microsoft could have addressed this a little more gently.

If you need help implementing SPF, DKIM or DMARC, feel free to reach out. In the meantime, make sure to look at this article from Paul where he covers SPF, and how to set it up.

Blog Identity & Security Office 365

Summary of announcements for Hybrid Exchange @ Ignite

Today, Microsoft has made some quite big (and important!) announcements around the work they are doing to improve the experience for Hybrid Exchange customers. These announcements were all “dropped” during session BRK3155 (How to thrive as an organization in Exchange Online), and – for most – came quite unexpected. If there’s one piece of feedback I would give Microsoft, it would be to better align the title of such sessions to their content!

This being said, with everything that was mentioned, I figured it would be a good idea to summarize it all (without going into too much detail) in a short write-up. As time permits, I will go into more detail on each of these items later this week.

If you’re not interested in more information about each feature, and just care about the headlines, here’s what was announced:

  1. Cross-premises delegation permissions (e.g. Send-on-Behalf, Calendar permissions, …) will be fully supported. Expected timeframe is Q1/2018. Fix for this is already rolling out in the service.
  2. Microsoft is working to solve the Automapping problem in hybrid deployments. Fix is being rolled out and (Private) Preview starting soon.
  3. In the future you will be able to remove the last Exchange server after having moved all mailboxes to the cloud. Plumbing for this has already started and expected to be released in the coming 12-18 months. Though with Microsoft, you never know!
  4. Microsoft is working on allowing you to move mailboxes cross-tenant. The capability to do so has been demoed in the session, but more work is needed to offer a more holistic approach. This is important, because cross-tenant migrations entail more than just moving mailboxes. There’s mail routing, there’s other workloads and – perhaps most importantly – there’s the need for proper governance. None of which was discussed (or showed) at this time. The timeline for this capability is the coming 12-18 months. This means that 3rd-party vendors (like QuadroTech, BinaryTree) are still very much needed to facilitate such scenarios today. Microsoft isn’t just there yet. Future will tell how useful Microsoft’s capability will be and how 3rd-party vendors will adopt to enhance the experience even further.
  5. To drive down complexity for hybrid deployments, a new hybrid solution backbone is being developed. This backbone which uses a “connector” will no longer require inbound connections (no more firewall ports to be opened) and is part of the solution for earlier new features. Think of the connector like an Azure App Proxy which uses the same principle (I wouldn’t be surprised that it’s a modified version thereof). Exchange Online will then, instead of using the “Public” Internet, route traffic to the connector through which it then makes its way to on-prem (outbound TCP443 connection). Timeline is in the next 6 months or so.
  6. Send-As permissions are a bit harder to solve. This will require item 4 to be solved (which will probably require item 5 to be done too). However, once that is done, this scenario will be covered as well. Today, however, the workaround is to explicitly define permissions in both EXO/On-Prem (it works!).

Other news – not necessarily hybrid related – that was announced in this session:

  1. Client Access Rules are coming to Exchange Online. These rules allow you to control how someone can access Exchange Online.
  2. new On Send events allow you to create add-ins which can fire when someone sends a message (e.g. DLP, content inspection, classification etc.). Currently only for OWA. Outlook clients coming (much) later.

There’s plenty of exciting stuff coming in the next few months. For now, we will still have to work with the limitations that exist, but if you are in the planning phase for Hybrid Exchange, it might be worth keeping these announcements in the back of your mind.

As things unfold over the coming weeks and months, I will be covering a lot of the details here, and in the Office 365 for IT Pros ebook. Make sure to grab your copy here!

Cheers,

Michael

Blog Exchange Hybrid Exchange

Microsoft releases new “Tenant Restriction” capability

A few days ago, Microsoft announced the General Availability of the “Tenant Restriction” capability. Although I have not been able to play with it so far, I wanted to take a few moments to reflect on the usefulness of the feature following a debate I had with a customer questioning me why they would be interested in something like this.

The Tenant Restriction capability, as the name already implies, allows an administrator to restrict access to a specific tenant. You might wonder how this is different from e.g. disallowing someone to authenticate by e.g. disabling their account? In the latter scenario, the user might not be able to use their account to login to e.g. Office 365, but that won’t prevent them from accessing other tenants (with other identities). From a data leakage point-of-view, the latter can be potentially dangerous. Maybe this is best explained with an example.

Let’s say a user called George works for Belgian Waffle House ltd. They have a tenant in Office 365 called “bwf.onmicrosoft.com”. George also works for a non-profit organization called the Belgian Chocolate Lovers and, they too, have a tenant in Office 365 called “bcl.onmicrosoft.com”. When no tenant restrictions have been configured, George can login to the bwf.onmicrosoft.com tenant (as he should!), but nothing would prevent him from logging in into bcl.onmicrosoft.com while at work. One might question why this is a problem, but let’s assume for a second that George first logged into the bwf.onmicrosoft.com tenant and downloaded some corporate documents. Perhaps these documents describe a new merger plan between the Belgian Waffle House and some Swiss Chocolate maker… As a Belgian chocolate lover, he might be interested in that! Either way, after downloading the document, he then logs into the bcl.onmicrosoft.com tenant and can upload the files there. The reason why he is able to login to both tenants is because the endpoint (e.g. login.microsoftonline.com) is a single endpoint for all tenants, world-wide. Blocking the endpoint (e.g. through a proxy server) would also prevent George to login into the bwf.onmicrosoft.com tenant.

Of course, there’s other ways to restrict access –but those pertain to accessing the tenant itself. For instance, an administrator can define a set of corporate IP addresses from which a user is allowed to authenticate into the corporate tenant. While this effectively prevents someone from accessing the tenant outside the corporate network, it doesn’t solve the problem described above.

The way this new Tenant Restriction capability works, is quite simple and the process isn’t really new. When a user authenticates to Azure AD (and thus a service which relies on Azure AD), the authentication platform will also look for a (HTTP) header called “Restrict-Access-To-Tenants“. The value of this header should contain all the tenants the user is allowed to access. If the tenant that the user is trying to authenticate to is listed, access is granted. If not, a warning message is displayed:

Image source: Microsoft.

A few things to reflect upon:

  • For this to work, there must be (some sort of) a proxy server between the user and the internet. Basically, anything that can add a header will do. If you want to ensure the limitation to access a tenant is maintained, e.g. also outside the corporate network, the user must always access the internet through a proxy server that injects the header. For this to work, other counter measures (such as ensuring the user cannot modify proxy settings etc.) must be present. Additionally, the proxy server must be accessible from outside the corporate network as well. One thing that would fit this requirement is a “proxy-as-a-service” such as e.g. ZScaler. But there’s others too.
  • The tenant restriction capability is not something you configure in Azure. Instead, it relies solely on your network infrastructure (proxy, ssl device, …) to inject the header. As such, the latter is quite important and you must consider the implications of doing so.
  • The feature only works with Modern Authentication. This is fine for the majority of Microsoft’s own application, but if you use other applications or even built-in ActiveSync apps, you must block access for those “legacy” apps if you want to maintain the restriction.
  • You can use the feature for free with Office 365, but have to buy a premium license if you want to restrict access to other applications relying on Azure AD for authentication.
  • The process described above only needs to be applied to the authentication process, hence thus only for the Azure AD endpoints. Users must not necessarily go through a proxy for access to e.g. SharePoint online or Exchange online.
  • Given the reliance on Modern Authentication, and because you cannot control how other tenants are setup, if those tenants still allow legacy authentication (e.g. basic auth), the restriction is bypassed (d’oh!). I hope/expect this to change in the future. However, if you also control the endpoint (and thus can control what applications can be used), it is still very effective.

As you can see, while the feature is pretty cool, it’s not 100% watertight. Perhaps that is a problem, perhaps not. It really depends on what your use case is for implementing it. However, if DLP is on your mind, every little thing can help and it can be an efficient way to stop the majority of the users of (accidentally) leaking sensitive data. Of course, it’s only a small cog in a much bigger machine as there’s many other features in Office 365 (and beyond) that can help you to prevent data leakage.

For more details, please read the announcement from Microsoft here.

 

Blog Office 365

Get your copy of Office 365 for IT Pros!

The Ultimate Guide to Office 365


Office 365 has over 1.2 million customers
with more than 70 million active users worldwide. Stay up to date in this fast moving, cloud-first world with the most comprehensive, independent guide to Microsoft Office 365:

 

  • Learn. Understand how Microsoft’s online cloud services really work, and the role that Exchange Online plays in the Office 365 ecosystem.
  • Master. Learn how to plan, deploy, migrate and manage Office 365, including migrations, mail flow, security, file sharing, and more.
  • Grow. Do more than just Exchange. Make use of Delve, SharePoint, and other applications to take advantage of everything that Office 365 can offer.

Get your copy HERE.

Blog PROMO

“Conference season” is about to start!

Every year in September, right after the summer holidays, there is an unofficial start of a new “work season”. For some this unofficial start moment comes a bit earlier, for others a bit later. Some even say their work season lasts the entire year… But that’s besides the point. The fall traditionally also heralds a myriad of tech conferences, each fighting for a moment in the spotlights. With Microsoft’s massive Ignite conference moving in from May, this year’s “conference season” promises to be exceptionally busy.

I’ve always liked going to conferences. Although content is important, having the opportunity to talk to peers and interact with the speakers (experts) is something I’ve learned to value more and more with each conference I attended in the past.

This year, I’m lined up to speak at a bunch of conferences again. If you have read some of my previous announcements, you’ll notice that I’m speaking at a pretty much the same conferences as before. Continue reading to find out why!

Blog Events News