🚫 400 Bad Request. Access to Outlook on the web has been blocked by your organization 🛑✉️🔒

Jev included in Exchange Online Outlook Microsoft 365 Troubleshooting

2024-04-29 875 words 5 minutes

/posts/2024/400-bad-request-access-to-outlook-on-the-web-has-been-blocked-by-your-organization/featured-image.png

Contents

While this post is outside of my usual topics, I would like to share a solution for an error message which returns just a single search result on Google. I want to share it because it took me some time to figure out what was going on. So in case someone else runs into this issue this post might be helpful.

The Issue

It all started after the network team updated the network to a new public IP. Right after this change all users started to get the error message 400 Bad Request. QWNjZXNzIHRvIE91dGxvb2sgb24gdGhlIHdlYiBoYXMgYmVlbiBibG9ja2VkIGJ5 IHlvdXIgb3JnYW5pemF0aW9uLiA8QlI+PEJSPkNsaWNrIDxhIGhyZWY9Ii9vd2Ev bG9nb2ZmLm93YSI+aGVyZTwvYT4gdG8gc2lnbiBvdXQu (Base64) when trying to access Outlook on the web (OWA) in Microsoft 365.

/posts/2024/400-bad-request-access-to-outlook-on-the-web-has-been-blocked-by-your-organization/badRequest.png — Outlook Web App - 400 Bad Request

And in case you are wondering, the decoded the Base64 string of the error message reads: Access to Outlook on the web has been blocked by your organization. <BR><BR>Click <a href="/owa/logoff.owa">here</a> to sign out.

What made this a bit more peculiar is that this error was shown only when accessing https://outlook.office.com/ (Outlook on the web) all other M365 services where accessible and working as expected.

Initially everyone thought that the error could be caused by a conditional access policy in Microsoft Entra ID, however conditional access policies should trigger at a much earlier stage, during the log-in. After checking the policies we found that there where none configured which would block access to access Outlook on the web (OWA) in Microsoft 365. Next all firewalls and proxies where checked and where possible disabled during troubleshooting. At this point a test set-up was created which allowed us to disable all network routing and security measures. The issue persisted…

Even WireShark traces didn’t yield any useful information. The only thing that was clear from the traces was that the server was sending a 400 Bad Request response.

The Root Cause

After banging our heads on the wall I decided to go back to basics and have a look at the request and response using the developer tools available in any modern browser. This is where I noticed the following payload message:

/posts/2024/400-bad-request-access-to-outlook-on-the-web-has-been-blocked-by-your-organization/badRequestPayload.png — ClientAccessRuleOWAErrorMEssage

While I am far from an expert in Exchange Online I do remember Client Access rules from back in the day when I had a couple of integration challenges with Exchange on-premises. I always assumed that the conditional access policies took over the functionality once provided by Client Access rules. But based on this message it seems that Exchange Online still has this functionality. For those who are not familiar what client access rules are an quick summary.

Client Access Rules

Client Access Rules help you control access to your Exchange Online based on client properties or client access requests. You can prevent clients from connecting to Exchange Online based on their IP address, authentication type, and user property values, and the protocol, application, service, or resource that they’re using to connect. - source

A quick search on the interwebs revealed that indeed the Client Access Rules are still available in Exchange Online. However they are deprecated and scheduled for retirement in September 2024. As illustrated by hte following image.

Image source

The Solution

Since the Client Access Rules are ancient technology the UI to manage them is not available in the Exchange Online admin center. Instead you have to use the ExchangeOnlineManagement PowerShell module. The following snippet installs this module in the current user scope, imports it, connects to Exchange Online and lists all present Client Access Rules. Just make sure to change the $exchangeAdminUpn value to your Exchange admin.

After running the snippet as expected a single Deny Access Client Access Rule was listed with the ‘old’ IP address in the exception list.

/posts/2024/400-bad-request-access-to-outlook-on-the-web-has-been-blocked-by-your-organization/casPolicies.png — Active Client Access Rule

As a quick fix I extended the exception list using the following snippet with the new IP address. The troublesome error 400 Bad Request. QWNjZXNzIHRvIE91dGxvb2sgb24gdGhlIHdlYiBoYXMgYmVlbiBibG9ja2VkIGJ5 IHlvdXIgb3JnYW5pemF0aW9uLiA8QlI+PEJSPkNsaWNrIDxhIGhyZWY9Ii9vd2Ev bG9nb2ZmLm93YSI+aGVyZTwvYT4gdG8gc2lnbiBvdXQu (Base64) was no longer shown and all users where able to access Outlook.

As shown in the above snippet I also added a new rule with the highest priority which allows access to remote PowerShell. I have done this to prevent myself from locking myself out in the future. This rule is an important safeguard to preserve access to your organization. Without this rule, if you create rules that block your access to remote PowerShell, or that block all protocols for everyone, you’ll lose the ability to fix the rules yourself (you’ll need to call Microsoft Customer Service and Support). - source

Naturally the next step is to remove the deprecated Client Access Rules and replace them with Conditional Access Policies. However that requires a bit more planning, consideration and testing so it’s a user story on our backlog.

If you are interested in the conditional access deployment you can find more information here .

Wrapping up

And that’s all folks! I hope you found this post helpful and/or educational. If you are interested in the reference material used to make this post, please visit the following links.

As always, a big thanks for reading this post. If you liked it, don’t be shy and have a look at my other posts .