Quick PowerShell Stuff 23

When it comes to PowerShell and Office 365 one thing is for sure, change is constant. Nothing can be more revealing that looking at some of the new cmdlets that are appearing in the various workloads for Office 365. For this article, we are covering a series of cmdlets that were released on Jan. 16, 2018 for Exchange Online. These cmdlets are all centered around the new ‘Client Access Rule’ concept:

Get-ClientAccessRule
New-ClientAccessRule
Remove-ClientAccessRule
Set-ClientAccessRule
Test-ClientAccessRule

Microsoft documentation on this feature:
https://technet.microsoft.com/en-us/library/mt842508(v=exchg.150).aspx

Cmdlet Review
The cmdlets provided begin with a full set of verbs and by this I mean we have Get, Set, New, Remove and Test. If you have not created any Client Access Rules, then there are none to begin with. Running Get-ClientAccessRule will show no results when run for the first time. In order to create our first rule, we’ll need to use the New-ClientAccessRule cmdlet. We can review the Get-Help -Examples for this cmdlet first:

There are quite a few options available for tweaking the control of access to your environment. Here are some useful parameters or the New-ClientAccessRule cmdlet:

• Action – Can allow or deny access based on other criteria
• AnyOfAuthenticationTypes – Authentication types that are valid for control are – AdfsAuthentication, BasicAuthentication, CertificateBasedAuthentication, NonBasicAuthentication and OAuthAuthentication
• AnyOfClientIPAddressesOrRanges –
• AnyOfProtocols – Allow or block various access protocols to Exchange Online – ExchangeActiveSync, ExchangeAdminCenter, ExchangeWebServices, IMAP4, OfflineAddressBook, OutlookAnywhere, OutlookWebApp, POP3, PowerShellWebServices, RemotePowerShell and REST
• ExceptAnyOfAuthenticationTypes – Exceptions to the Client Access Rule authentication protocols –
  AdfsAuthentication, BasicAuthentication, CertificateBasedAuthentication, NonBasicAuthentication and OAuthAuthentication
• ExceptAnyOfClientIPAddressesOrRanges – This parameter can be a single IP, an IP range and or CIDR IP with subnet.
• ExceptAnyOfProtocols – The reverse of the ‘AnyOfProtocols’ setting, but with the same protocols –
  ExchangeActiveSync, ExchangeAdminCenter, ExchangeWebServices, IMAP4, OfflineAddressBook, OutlookAnywhere, OutlookWebApp, POP3, PowerShellWebServices, RemotePowerShell and REST
• ExceptUsernameMatchesAnyOfPatterns – allows the rule to look at one or more usernames to match and apply access rights.
• Scope – The parameter scopes the rule to either End-User connections or all connections made to the service.
• UsernameMatchesAnyOfPatterns – Pattern match user names instead of specifying an exact match.
• UserRecipientFilter – Filters the rule based on recipient properties – City, Company, CountryOrRegion, CustomAttribute1-15, Department, Office, PostalCode, StateOrProvince and StreetAddress.

Creating a Rule
So what can we actually accomplish with the above parameters? We can create rules that are targeted – blocking a particular user or group of users or we can create more broadly target rules that affect all users. With these rules we can decide how we want users to connect to Exchange Online.
** NOTE ** All of these controls are available via PowerShell only. Hopefully something will be added to the Exchange Admin Center for Exchange Online in order to facilitate this for those adverse to PowerShell.
Let’s tackle some scenarios and create rules based on these scenarios:
Example One
In this scenario we want to create two different Client Access Rules. One is to block all access to Exchange Online unless the users is on a corporate subnet and if they are a member of a particular group. The second rule will allow members of IT to connect no matter where they are.
Rule One

New-ClientAccessRule -Name 'Corporate Policy' -UserRecipientFilter {CustomAttribute11 -eq 'InternalOnly'} -AnyOfClientIPAddressesOrRanges '10.0.0.0/24' -Action AllowAccess
<BR>

Rule Two

New-ClientAccessRule -Name 'IT Access Policy' -UserRecipientFilter {CustomAttribute11 -eq 'ITDept'} -Action AllowAccess

Notice that when the rules are created, we are provided with a warning about the rule taking effect in 24 hours, for the first rule, and an hour subsequently after that.

We can verify the rules were created correctly with Get-ClientAccessRule:

Detailed look at one of the rules:

Example Two
In this next example scenario, we need to block access for any user to POP, IMAP and OWA:

New-ClientAccessRule -Name 'Block Protocols' -AnyOfProtocols Pop,Imap,OutlookWebApp -Action DenyAccess

A fairly easy rule to implement.
Example Three
For this last example we need to block all PowerShell access to the tenant for users with a Custom Attribute 10 of ‘NoPowershell’:

New-ClientAccessRule -Name 'Block PowerShell Access' -UserRecipientFilter {CustomAttribute11 -eq 'RemotePowerShell'} -AnyOfProtocols PowerShellWebServices, RemotePowerShell -Action DenyAccess

Testing Rules
This one is rather interesting and you need possibly more variables for input than you may have put into your rule to begin with. For example, if we were to test any of the sample rules that are show previously, we need to provide the Test cmdlet with at least this information:

• Protocol
• RemoteAddress
• AuthenticationType
• RemotePort
• User

Sample run form the test cmdlet:
A successful test of an ‘AllowAccess’ rule would look like this:

Key thing is to know the criteria you are testing for because if you do not get any results back from the Test-ClientAccessRule cmdlet, then you are not providing the correct data or test person in the cmdlet.
Removing Client Access Rules
The easiest of the cmdlet is the one for removing rules. All we need is the name of a rule and we can remove it. First, let’s check the rules we have so we can get the right name:

Sample removal:

Remove-ClientAccessRule 'Block PowerShell Access'

Conclusion
Before implementing these rules, make sure you layout the intention and can match the PowerShell cmdlet settings to what you are allowing or blocking in Exchange Online. Blocking certain authentication protocols, for example, could have unintended consequences. Test before pushing out to production users. Be especially careful with restricting PowerShell access as you could lock everyone out and then you won’t be able to work with your tenant with PowerShell any more.
Last comment I want to make is that I do hope this functionality is released in the GUI as it would be nice to build these like Transport Rules for SMTP flow management.