The Test-ClientAccessRule cmdlet can be used to verify that the rule you created works as expected. Now, because I’ve only blocked external access to OWA (in other words I used an exception in the CAR above), I can work with it just fine when I’m using an “internal” device. The message shown above can use some improvements, but it should give the user and admin enough information to understand what the cause is. Here’s how the experience looked like for any external attempt to open OWA:
Both the documentation and the actual PowerShell cmdlet will warn you about this, however in my case the rule started working almost immediately. Once you have created the rule, you will have to wait for a while for it to take effect. Here’s how the rule looks like: New-ClientAccessRule -Name "BlockOWAExternal" -AnyOfProtocols OutlookWebApp -ExceptAnyOfClientIPAddressesOrRanges 11.22.44.55-Action DenyAccess The example I used was to block access to OWA externally – something that was not possible until now, even in federated scenarios, unless you were willing to sacrifice some other functionalities, or to use Azure AD Conditional access. This in turn means you need to be very careful not to block PowerShell access, or you will be forced to place an awkward support call 🙂 I would strongly advise you to review the documentation before creating any Client Access Rule!Īssuming you’ve familiarized yourself with the process, you can fire up a connection to Exchange Online PowerShell and create your first CAR. Let’s go.įirst of all, managing of Client Access Rules is all done via PowerShell. Sadly I still don’t have CARs across all my tenants, but it’s enough to give the feature a quick test.
Namely, Client Access Rules, or the functionality that allows us to control access to Exchange Online based on location, protocol and authentication type.
The wait is over – one of the most requested features has finally hit my tenant.
0 kommentar(er)
