_______________________________
In This Chapter
- Client Access
- Outlook Web Access (OWA)
- GAL Segmentation
- Enable Address Book Policy Routing
- Create Recipient Filter
- Create Address Lists
- Create Global Address List (GAL) and Offline Address Book (OAB)
- Create a New Address Book Policy
- Accepted Domains
- POP3 and IMAP4
- Client Access Rules
_______________________________
For Exchange Online, configuration does not involve any of the normal server configuration that would normally need to be completed for an on-premises server. Instead we need to focus on features that can be enabled, configured and modified with PowerShell. These elements are crucial to a successful and good experience for your end users.
With a hosted Exchange environment we need to look at things like granting access to certain protocols or a user. This could mean configuring all mailboxes to connect via only ActiveSync, OWA and MAPI while blocking all users from connecting over IMAP or POP3. We can also control the experience users have with OWA and ActiveSync with policies that are built-in or ones we create new and apply to users on Exchange Online.
We will also explore Address Lists Segregation which allows different users to see different sets of users in Outlook. Typical use of this feature would be for large corporations looking to limit an address book by regions or perhaps a company with many subsidiaries would want to isolate some user look ups in their GAL.
POP3 and IMAP for will covered as they are offered as part of the Office 365 suite of connection protocols and some Line of Business applications still require these protocols. We’ll explore what can be configured in a hosted Exchange environment for these two protocols.
End user access is key to a functional messaging system. This goes for Exchange servers as well. Access for clients comes in the form of OWA, Outlook and ActiveSync. For this chapter we will cover OWA, Outlook Anywhere and MAPI over HTTP. These items need to be configured before clients begin to connect to the Exchange 2016 servers.
Client Access Mailbox
There is a subset of cmdlets that we can use to control certain parts of the client access experience for users. These cmdlets will allow us to control protocols and settings associated with those protocols. We can control the settings for POP3, MAPI behavior, EWS and overall which protocols are even allowed.
PowerShell
What cmdlets are available for the CASMailbox phrase?
Get-Command *CASMailbox*
We can see there are cmdlets for Get and Set, but we also have an interesting pair of cmdlets for a CAS Mailbox Plan. We will see what these do a little later on.
First let’s review the Get-CASMailbox cmdlet and see what it provides for us:
Get-CASMailbox Damian
- ActiveSyncEnabled - This allows a connection to the mailbox from a device that uses ActiveSync
- OWAEnabled - Web mail access via your favorite browser over Port 443
- POPEnabled - by default this allows a secure POP3 connection on Port 995
- IMAPEnabled - enabled by default as well for IMAP4 access on Port 993
- MAPIEnabled - This was the standard protocol for access via Outlook clients
From the Get-CASMailbox cmdlet we can see that there are five main protocols listed and in the case of this one mailbox, they are all enabled. As we can see here all of these protocols/access methods are enabled by default for mailboxes in Office 365. The same methods can all be disabled or enabled depending on the needs of the organization.
The Get-CASMailbox | Ft provides a pretty basic view and we will explore later how we can use this as a reference for the Set-CASMailbox to alter what protocol a mailbox can be accessed with.
Now image that we would like to see a more detailed view of these CAS protocols and the settings for one mailbox:
Get-CASMailbox Damian | FL
As we can see there are quite a few properties we can adjust for each of the protocol methods as well as revealing a couple more - EWS and MAPI/HTTPS.
One common task for these protocols is to decide what access we would want to provide for the users. Do we want all users to access OWA, ActiveSync, MAPI, MAPI over HTTPS, POP, IMAP and so on?
Scenario
You have a new IT manager who has decided that she would like to secure access to Office 365 mailboxes. She has asked the Help Desk and Administrators to figure out what protocols are in use and to lock down those that are not. After investigating here is the recommendation that is presented to the IT Manager:
In Use: ActiveSync, MAPI/HTTPS, ECP, OWA
Not In Use: POP, IMAP, MAPI
The IT Manager wants to now restrict these protocols for all mailboxes in Office 365. Because the Get-CASMailbox cmdlet was use to pull the protocol types, it is decided that the Set-CASMailbox cmdlet be used to restrict access:
Get-Help Set-CASMailbox -Examples
Reviewing the examples it looks like each protocol can be specified in the Set-CASMailbox cmdlet. As all mailboxes will be affected, the Get-Mailbox cmdlet should be piped into the Set-CASMailbox cmdlet like this:
Get-Mailbox | Set-CASMailbox -PopEnabled $False -IMAPEnabled $False -MAPIEnabled $False
Once the changes are made, we can check with a Get-Mailbox cmdlet, which will show the following:
Notice that the protocols that were disabled, now show ‘False’ as expected. However, notice the last protocol ‘MapiHTTPEnabled’. No value is displayed for this protocol. When reviewing the Get-Help for Set-CASMailbox, what we find is that the ‘MAPIHTTPEnabled’ parameter for Set-CASMailbox, only works in Exchange 2016. The MAPI over HTTPs is set to be ‘the’ protocol to connect to Office 365 (it may be by the time you read this) and it is not configurable at this point either.
In some scenarios you may want to block access to a protocol like MAPI over HTTPS or RPC over HTTPs and this can be done with Client Access Rules, which is covered at the end of this chapter.
Another set of parameters that are commonly configured are ‘OWA Mailbox Policy’ and ‘ActiveSyncDebugLogging’. The first is used to set a policy that applies to mailboxes for when they access their mailboxes via OWA. The second can be used to help diagnose ActiveSync connection issues.
Example - OWA Mailbox Policy
If we’ve configured an OWA Mailbox Policy called ‘Company OWA Policy’ we can apply this like so:
Set-CASMailbox Damian -OwaMailboxPolicy
We can also apply the same policy to multiple mailboxes or all mailboxes depending on the needs within PowerShell.
Example - ActiveSync Debug Logging
Mobile access to email has become more important year after year. Whether you connect with an Windows Phone, iPhone or Android sometimes issues occur where the connection cannot be made. So we can turn on some logging and send that to an email address for further diagnostics. The setting for a single mailbox can be initiated by turning on ActiveSync Debug Logging:
Set-CASMailbox Damian -ActiveSyncDebugLogging $True
After the troubleshooting is complete, make sure to turn this setting off:
Set-CASMailbox Damian -ActiveSyncDebugLogging $True
In addition to the CAS Mailbox cmdlets, there is also a set of CAS Mailbox Plan cmdlets. Let’s explore what these cmdlets can be used for. First, the two cmdlets:
What information can get from just the ‘Get’ cmdlet:
Get-CASMailboxPlan | Ft
Well the results from the cmdlet are far from ideal. First, where is the name?
Get-CasMailboxPlan | Ft Name
Notice that the names are a little more descriptive. The plans also correspond to the licensing that is assigned or can be assigned to users to enable certain features in Exchange Online. A chart of the licensing can be found here:
https://msdn.microsoft.com/en-us/library/dd229067(v=exchsrvcs.149).aspx
Let’s examine the ‘ExchangeOnlineEnterprise’ license which corresponds to an E3 licenses in Office 365:
Get-CASMailboxPlan ExchangeOnlineEnterprise-124f6119-7869-40e4-90a6-14e20837d794 | Fl
If we remember the settings revealed with ‘Get-CASMailbox’ cmdlet, a lot of the available properties here are similar. We would also notice that there are some missing properties as well. For example, settings that appear to apply to a single user are not included in the CAS Mailbox plan - ActiveSyncAllowedDeviceIDs, ActiveSyncBlockedDeviceIDs, ActiveSyncMailboxPolicyIsDefaulted and HasActiveSyncSuppressReadReceipt. However, all the other settings included in the CAS Mailbox planned can be applies en masse to all mailboxes with a certain license applied to them. A practical approach to this would be to use the plan configuration to globally change the protocols allowed or change settings that need to be set for all mailboxes in Exchange Online. In the case of the next example, we are reducing the protocols allowed for any mailbox with an E3 license:
Set-CASMailboxPlan ‘ExchangeOnlineEnterprise-124f6119-7869-40e4-90a6-14e20837d794’ -PopEnabled $False -IMAPEnabled $False -MAPIEnabled $False
Now, while we can make these changes, there are some parameters that are not allowed and are restricted to Microsoft:
In the case of Set-CASMailboxPlan, over 30 parameters are for Microsoft use only. While it would be nice to configure these plans to make the changes global, Microsoft would prefer these changes not be made without their guidance. These parameters can also be verified on the TechNet page for this cmdlet:
https://technet.microsoft.com/en-us/library/mt492754(v=exchg.160).aspx
Outlook Web Access (OWA) is the web client that is typically used by users who don’t need all of the capabilities of Outlook, do not use Outlook enough to justify a license, mobile users and road-warriors. Like Exchange on-premises, Exchange Online has policy and settings that can be applied to affect the users experience for OWA as on-premises you could also configure the OWA virtual directories to achieve the same effect.
Configuring OWA in Exchange Online is limited to configuring OWA Mailbox Policies. All other configuration options are left behind the scenes:
Get-command *owa*
Let’s start with the Get-OWAMailboxPolicy to see what we have available for configuration:
We can see from the results, we have a default policy and nothing else defined. We can dig into more details with the Format-List options like so:
Get-OWAMailboxPolicy OWAMailboxPolicy-Default | Fl
The above is a small sample of the available properties that are included in the default OWA Mailbox Policy. This is quite different from what is available in the Exchange Admin Center:
The web based access to the OWA Mailbox Policy allows access to some common features like File Access and Offline Access. This is perhaps easy to configure in the Exchange Admin Center. As we can see, by default we have one OWA Mailbox Policy which is by default applied to all mailboxes as they are created:
Get-Mailbox | Get-CASMailbox | Ft DisplayName,OWAMailboxPolicy
These two users have the default OWA Mailbox policy assigned to them. By default a lot of options are enabled and this may or may not be the desired result. The provided options in the GUI may not be the options we need to tweak for our user population. As such, we can use PowerShell to make these changes and produce a policy that is what we need. For example, we would like to turn off some of the cloud options for attachments for these users:
From the above screenshot we can see we have some interesting options that are on by default. Let’s adjust these so that there are no cloud attachment options enabled. We can do so by disabled Dropbox, Google and Box as available options, like so:
Set-OwaMailboxPolicy OwaMailboxPolicy-Default -DropboxAttachmentsEnabled $False -BoxAttachmentsEnabled $False -GoogleDriveAttachmentsEnabled $False
Now we have this as a result:
For this example, OneDrive is still enabled as this will be part of our Office 365 tenant, controlled with Office 365 security processes and thus considered safe for attaching to emails.
There are some properties of the OWA Mailbox Policies that are considered a ‘MultiValuedProperty’. What this means is that the property contains multiple values and needs to be treated a bit differently then other properties which are single value ones. What does that mean? Let’s review one example - ‘BlockedFileTypes’. This property contains 88 file types. These 88 are the default file types that are blocked by Exchange Online. What if we need to add a value or extension? First, don’t do this:
Set-OwaMailboxPolicy OwaMailboxPolicy-Default -BlockedFileTypes ‘.txt’
That will set the property to just ‘.txt’. The other 88 default file types will be wiped out. So, don’t do that, unless that was your intent. In order to add a value, we’ll need to store all 88 file types in a variable, add the new one to that variable and then apply that variable to the ‘BlockedFileTypes’ variable. To do so, we run a set of PowerShell cmdlets like so:
Sample Code to Add Blocked File Types
$CurrentFileTypes = @()
$CurrentFileTypes = (Get-OwaMailboxPolicy).BlockedFileTypes
$OWAPolicyName = ‘OwaMailboxPolicy-Default’
$Loop = 0
# Get New File Types
Write-Host ‘ ‘
Write-Host ‘How many new file types do you want to add? ‘ -NoNewLine -ForegroundColor Yellow
$Number = Read-Host
Write-Host ‘--------------------------------------------’ -ForegroundColor Yellow
Write-Host ‘ ‘
Do {
Write-Host ‘File type to add: ‘ -NoNewLine -ForegroundColor Green
$Type = Read-Host
$CurrentFileTypes += $Type
$Loop++
} While ($Loop -lt $Number)
# Add File Types
Write-Host ‘ ‘
Write-Host ‘Adding file types now.’ -ForegroundColor Yellow
Write-Host ‘’
Set-OwaMailboxPolicy -Identity $OWAPolicyName -BlockedFileTypes $CurrentFileTypes
Write-Host ‘ ‘
Write-Host ‘Done adding file types.’ -ForegroundColor Cyan
The above script allows for use input which allows for this to be run at any time in the future. Here is what a sample run would look like if we wanted to add some custom file types:
Now, what if we wanted to do the reverse and remove the file type specified? How would we code for that? The easiest cmdlet to use to remove items is Compare-Object. Compare-Object will allow PowerShell to look at the entire contents of a variable looking for a particular string.
Sample Code to Remove Blocked File Types
#Variable Definition
$CurrentFileTypes = @()
$Remaining = @()
$NewFileTypes = @()
$CurrentFileTypes = (Get-OwaMailboxPolicy).BlockedFileTypes
$OWAPolicyName = ‘OwaMailboxPolicy-Default’
$Loop = 0
# Get New File Types
Write-Host ‘ ‘
Write-Host ‘How many new file types do you want to Remove? ‘ -NoNewLine -ForegroundColor Red
$Number = Read-Host
Write-Host ‘--------------------------------------------’ -ForegroundColor Red
Write-Host ‘ ‘
Do {
Write-Host ‘File type to remove: ‘ -NoNewLine -ForegroundColor Yellow
$Type = Read-Host
$Remaining = (Compare-Object -ReferenceObject $CurrentFileTypes -DifferenceObject $Type).InputObject
$Loop++
} While ($Loop -lt $Number)
# Any remaining file types will be stored in $NewFileTypes variable
$NewFileTypes = $Remaining
# Add File Types
Write-Host ‘ ‘
Write-Host ‘Removing file types now.’ -ForegroundColor Red
Write-Host ‘’
Set-OwaMailboxPolicy -Identity $OWAPolicyName -BlockedFileTypes $NewFileTypes
Write-Host ‘ ‘
Write-Host ‘Done removing file types.’ -ForegroundColor Red
Sample removal of a custom file type:
Now that we have an OWA Mailbox Policy configured we can assign them to our mailboxes in an Exchange Tenant. Typically there is one default OWA Mailbox Policy that is set for 99% of the mailboxes in an organization. We can verify what is already present with this one-liner:
Get-Mailbox | Get-CASMailbox | ft DisplayName,OWAMailboxPolicy
Which provides this for results:
If we’ve created more that one OWA policy we can assign it with the Set-CASMailbox cmdlet. An example of this would be if there is a separate policy for IT, C level executives and the rest of the company. In this case, we can assign the different policies to different people. Before assigning policies, verify the policies that are available:
Now that we have the names available, we can assign the policies:
Set-CASMailbox Damian -OwaMailboxPolicy ‘IT OWA Policy’
Set-CASMailbox John.Doe -OwaMailboxPolicy ‘C-Level OWA Policy’
After assigning the OWA Mailbox Policies make sure to verify the changes:
The last option we have for OWA Mailbox Policies is removal. If there are excess policies or policies that need to be removed because they are no longer needed, we can remove them as well with the Remove-OWAMailboxPolicy. Remember to change the OWA Mailbox Policy for any users who are assigned to this policy otherwise you will experience an error like so:
GAL Segmentation is the concept of separate address lists that are limited access wise to sets of users. Think of a company that has many subsidiaries. Users in the parent company have access to all the information of their subsidiaries. However, each subsidiary may not necessarily have the same access. When it comes to Exchange Online, we may want to isolate these entities so they only see their own address lists. This is just one use case for the GAL Segmentation feature in Exchange Online. In order to configure this, we’ll need to perform these steps:
- Enable Address Book Policy Routing
- Create Recipient Filter
- Create Address Lists
- Create Global Address List (GAL) and Offline Address Book (OAB)
- Create a new Address Book Policy
Microsoft’s official guidance is listed below and applies generally to Office 365 and Exchange 2013+:
https://technet.microsoft.com/en-us/library/hh529948(v=exchg.150).aspx
Enable Address Book Policy Routing
The first step down the road of GAL Segmentation is the enabling of Email Address Book Policy routing. This setting can be changed with the Set-TransportConfig cmdlet available in Exchange Online. If we review the Get-Help for Set-TransportConfig, we see there is a parameter that will allow the configuration of that setting:
Get-Help Set-TransportConfig -Full
Using the related ‘Get’ cmdlet, we can verify that this is disabled by default:
Get-TransportConfig | fl AddressBookPolicyRoutingEnabled
We can now configure this for true and move on to the next step:
Set-TransportConfig -AddressBookPolicyRoutingEnabled $True
In order to construct a valid address book that is usable for a particular group of users, we will need to decide what users will be placed in that Address Book. A common method is to use a distribution group. For our example configuration we will have one distribution group per subsidiary, one distribution group for the main company and one distribution group for all mailboxes in the entire company.
Example
For this scenario there is a company call Railroad Holdings, Inc. This company had five subsidiaries - West Coast Trains, East Coast Trolleys, British Railway, Great Railroad Company and Subway Car Corp. In order to create these distribution groups and keep them up to date, we’ll use the New-DynamicDistributionGroup:
Get-Help New-DynamicDistributionGroup -Examples
In this example, users in each subsidiary company will have their CustomAttribute10 set to the company that they work for. Each group will thus be created based on this criteria.
Company
Railroad Holdings, Inc
West Coast Trains
East Coast Trolleys
British Railway
Great Railroad Company
Subway Car Corp.
Here is the code to create each DDL:
New-DynamicDistributionGroup -Name ‘All - Railroad Holdings, Inc’ -RecipientFilter {CustomAttribute10 -eq ‘Railroad Holdings, Inc.’}
New-DynamicDistributionGroup -Name ‘All - West Coast Trains’ -RecipientFilter {CustomAttribute10 -eq ‘West Coast Trains’}
New-DynamicDistributionGroup -Name ‘All - East Coast Trolleys’ -RecipientFilter {CustomAttribute10 -eq ‘All - East Coast Trolleys’}
New-DynamicDistributionGroup -Name ‘All - British Railway’ -RecipientFilter {CustomAttribute10 -eq ‘All - British Railway’}
New-DynamicDistributionGroup -Name ‘All - Great Railroad Company’ -RecipientFilter {CustomAttribute10 -eq ‘All - Great Railroad Company’}
New-DynamicDistributionGroup -Name ‘All - Subway Car Corp.’ -RecipientFilter {CustomAttribute10 -eq ‘All - Subway Car Corp.’}
Sample creation of one of the above Dynamic Distribution Groups:
Before we begin to configure new Address Lists for Exchange Online, we need to make sure the correct permissions are applied. As Microsoft states on Tech Net - “In Exchange Online, the *-AddressList cmldets are only available in the Address Lists management role. By default in Exchange Online, the Address List role isn’t assigned to any role groups. To use any cmdlets that require the Address List role, you need to add the role to a role group.” This means that before we begin, we need to assign this permission to the admin user we use to configure Exchange with.
We can see the role we need to assign by checking it with the Get-ManagementRole cmdlet:
We need to create a Role Group and assign this Management Role to it:
After creating the Role Group, we now assign this group to a user to manage lists:
Remember to close your PowerShell session to Exchange Online after adding this Role Group and then reconnect. Otherwise the new Address List cmdlets will not be available. Now that we have the correct permissions, we can review the default Address Lists with this cmdlet:
Get-AddressList
What other Address List cmdlets are available?
Get-Command *AddressList
For creating new Address Lists, it looks like the ‘New-AddressList’ is the cmdlet we’ll need. Let’s first review the examples for the cmdlet:
None of the above examples exactly match our scenario. We will use Example 1, match the Recipient Type as a user mailbox and the distinguished name of the group we used as well. First, we need to get the distinguished name of the group:
$DDN = (Get-DynamicDistributionGroup ‘All - Railroad Holdings, Inc’).DistinguishedName
After that we can then use the $DDN value in our recipient filter as one of the criteria for adding users to the Address List:
New-AddressList -Name “All - Railroad Holdings” -RecipientFilter “RecipientType -eq ‘UserMailbox’ -And MemberOfGroup -eq ‘$DDN’” -DisplayName “All - Railroad Holdings”
Now we have one Address list. We will need to do the same for each Dynamic Distribution Group. We can even do a loop to process each of these:
#Define Groups to be used for the Address Lists
$Groups = “All - Railroad Holdings”,”All - West Coast Trains”,”All - East Coast Trolleys”,”All - British Railway”,”All - Great Railroad Company”,”All - Subway Car Corp”
Foreach ($Group in $Groups) {
$DDN = (Get-DynamicDistributionGroup $Group).DistinguishedName
New-AddressList -Name $Group -RecipientFilter “RecipientType -eq ‘UserMailbox’ -and MemberOfGroup -eq ‘$DDN’” -DisplayName $Group
#Clear $DDN variable
$DDN = $Null
}
With a successful run we see each Address List’s creation:
Verifying the lists are available:
Create Global Address List (GAL) and Offline Address Book (OAB)
Now that we have our Dynamic Distribution Groups and Address Lists created, we can configure the two most important parts of this exercise - a new GAL and a new OAB for each subsidiary. Let’s see what PowerShell cmdlets are available to us for each of these tasks.
Global Address List (GAL)
Get-Command *GlobalAddressList
Examples for New-GlobalAddressList:
Get-Help New-GlobalAddressList -Examples
We will follow the second example a bit in our code below:
$DDN = (Get-DynamicDistributionGroup ‘All - Railroad Holdings, Inc’).DistinguishedName
New-GlobalAddressList -Name ‘Railroad Holdings GAL’ -RecipientFilter “MemberOfGroup -eq ‘$DDN’”
$DDN = (Get-DynamicDistributionGroup ‘All - West Coast Trains’).DistinguishedName
New-GlobalAddressList -Name ‘West Coast Trains GAL’ -RecipientFilter “MemberOfGroup -eq ‘$DDN’”
$DDN = (Get-DynamicDistributionGroup ‘All - East Coast Trolleys’ ).DistinguishedName
New-GlobalAddressList -Name ‘East Coast Trolleys GAL’ -RecipientFilter “MemberOfGroup -eq ‘$DDN’”
$DDN = (Get-DynamicDistributionGroup ‘All - British Railway’).DistinguishedName
New-GlobalAddressList -Name ‘British Railway GAL’ -RecipientFilter “MemberOfGroup -eq ‘$DDN’”
$DDN = (Get-DynamicDistributionGroup ‘All - Great Railroad Company’).DistinguishedName
New-GlobalAddressList -Name ‘Great Railroad Company GAL’ -RecipientFilter “MemberOfGroup -eq ‘$DDN’”
$DDN = (Get-DynamicDistributionGroup ‘All - Subway Car Corp.’).DistinguishedName
New-GlobalAddressList -Name ‘Subway Car Corp GAL’ -RecipientFilter “MemberOfGroup -eq ‘$DDN’”
We can verify the GAL’s were created:
Offline Address Book
To create a new Offline Address Book, we need to find the relevant cmdlets:
Get-Command *OfflineAddress*
Get-Help New-OfflineAddressBook -Examples
Now that we have some examples to use, we’ll create our new ones, one for each GAL we created before. This way we now have a GAL and OAB per company. For our example, we’ll need six new Offline Address Books.
New-OfflineAddressBook -Name “Railroad Holdings OAB” -AddressLists ‘All - Railroad Holdings’
New-OfflineAddressBook -Name “West Coast Trains OAB” -AddressLists ‘All - West Coast Trains’
New-OfflineAddressBook -Name “East Coast Trolleys OAB” -AddressLists ‘All - East Coast Trolleys’
New-OfflineAddressBook -Name “British Railway OAB” -AddressLists ‘All - British Railway’
New-OfflineAddressBook -Name “Great Railroad Company OAB” -AddressLists ‘All - Great Railroad Company’
New-OfflineAddressBook -Name “Subway Car Corp OAB” -AddressLists ‘All - Subway Car Corp.’
We can verify our Offline Address Books are available:
Create a New Address Book Policy
We’ve now created many objects in Exchange Online to get here - Dynamic Distribution Groups, Address Lists, Global Address Lists and Offline Address Lists. At this point we are ready to configure the segmentation piece. First part of this is to create an Address Book Policy that will contain the Offline Address Book, Global Address List and Address Lists. One of the surprise items for the creation of an Address Book Policy is the requirement for a Rooms List. So if you are in the process of creating Address Book Policies, make sure to have a rooms list ready.
New-AddressBookPolicy -Name ‘Corporate ABP’ -AddressLists ‘All - Railroad Holdings’ -GlobalAddressList “Corporate GAL” -OfflineAddressBook “Corporate OAB” -RoomList ‘All Rooms’
New-AddressBookPolicy -Name ‘West Coast Trains ABP’ -AddressLists ‘All - West Coast Trains’ -GlobalAddressList “West Coast Trains GAL” -OfflineAddressBook “West Coast Trains OAB” -RoomList ‘West Coast Trains Rooms’
New-AddressBookPolicy -Name ‘East Coast Trolleys ABP’ -AddressLists ‘All - East Coast Trolleys’ -GlobalAddressList “East Coast Trolleys GAL” -OfflineAddressBook “East Coast Trolleys OAB” -RoomList ‘East Coast Trolleys Rooms’
New-AddressBookPolicy -Name ‘British Railway ABP’ -AddressLists ‘All - British Railway’ -GlobalAddressList “British Railway GAL” -OfflineAddressBook “British Railway OAB” -RoomList ‘British Railway Rooms’
New-AddressBookPolicy -Name ‘Great Railroad Company ABP’ -AddressLists ‘All - Great Railroad Company’ -GlobalAddressList “Great Railroad Company GAL” -OfflineAddressBook “Great Railroad Company OAB” -RoomList ‘Great Railroad Company Rooms’
New-AddressBookPolicy -Name ‘Subway Car Corp ABP’ -AddressLists ‘All - Subway Car Corp.’ -GlobalAddressList “Subway Car Corp GAL” -OfflineAddressBook “Subway Car Corp OAB” -RoomList ‘Subway Car Corp Rooms’
After the Address Book Policies are created, we need to assign the Address Book Policy (ABP) to user’s mailboxes. Now, in the previous pages where we created our Address Lists, you’ll note that we used the ‘CustomAttribute10’ to identify which company a user is in and use that to assign the ABP:
Get-Mailbox -Filter {CustomAttribute10 -eq ‘Railroad Holdings, Inc.’} | Set-Mailbox -AddressBookPolicy ‘Corporate ABP’
Get-Mailbox -Filter {CustomAttribute10 -eq ‘West Coast Trains’} | Set-Mailbox -AddressBookPolicy ‘West Coast Trains ABP’
Get-Mailbox -Filter {CustomAttribute10 -eq ‘East Coast Trolleys’} | Set-Mailbox -AddressBookPolicy ‘East Coast Trolleys ABP’
Get-Mailbox -Filter {CustomAttribute10 -eq ‘British Railway’} | Set-Mailbox -AddressBookPolicy ‘British Railway ABP’
Get-Mailbox -Filter {CustomAttribute10 -eq ‘Great Railroad Company’} | Set-Mailbox -AddressBookPolicy ‘Great Railroad Company ABP’
Get-Mailbox -Filter {CustomAttribute10 -eq ‘Subway Car Corp’} | Set-Mailbox -AddressBookPolicy ‘Subway Car Corp ABP’
We can verify that the attribute and the ABP are correct for all users:
Accepted domains are the SMTP domains that your Exchange Online will accept email for. By default the only domain defined is the default Microsoft define domain - ‘Tenant.OnMicrosoft.Com’. When it comes to PowerShell there isn’t a lot we can do. Unlike Exchange on-premises where we configure these domains in Exchange instead. These domains are available because they were configured globally for Office 365.
PowerShell
Get-Command *accepted*
Okay. So we can review Accepted Domains currently present in Office 365 and we can configure existing ones. However, we cannot add, remove or do much with Accepted Domains in Exchange Online. Let’s review what the commands we can use, starting with the Get-AcceptedDomain cmdlet:
Get-AcceptedDomain | Ft -Auto
That at least provided a quick list of defined Accepted Domains in Exchange Online. We can still use Format-List in order to get more detailed information on the domain.
Get-AcceptedDomain | Fl
Now we can see some value to the Get-AcceptedDomain cmdlet. However, while information is revealed, reviewing the Set-AcceptedDomain cmdlet reveals that not much can be changed by the Office 365 Admin. Let’s first start with a sample usage of the cmdlet:
Get-Help Set-AcceptedDomain -Examples
If we review the available parameters for Set-AcceptedDomain, there are only four that we can use and they are circled in red in the below screenshot:
So in reality we can change the Domain Type, if Subdomains are allowed and if the domain is simply a relay domain for internal emails.
POP3 and IMAP4 protocols are common connection protocols for clients other than Outlook. The protocols are also commonly used by applications and programs to scrape a mailboxes information and or messages. How can these properties be utilized? Let’s take a scenario where a company has put in place a policy that restricts the use of certain protocols in Exchange Online. IT wants to restrict POP3 and IMAP access. There is a small subset of users that require the use of these protocols and IT wants to limit IMAP and POP protocols. Lastly, we need to accomplish these goals with PowerShell and it needs to be scalable.
Each protocol will have two groups of users – those that have access and those that do not. The first step would be to group users that should have access as this group will be the easiest to build and maintain rather than trying to maintain a group of those to block access to a resource. In Active Directory, create a group called “POP3 Access” and another called “IMAP Access”. We then add users who will have access to these resources, using Active Directory Users and Computers.
Now that the groups are populated with users a script will be needed to enforce these access conditions. What is needed in order to build the script?
- Need to store this user list in a variable to determine access or use the group name in the script as the determining factor for access in the script.
- What access should be granted or denied depending on members?
- What commands can we use to query this information in Exchange?
- What commands can we use to add or remove access to the resource?
- How often do we would want to reinforce this action?
PowerShell Cmdlet Determination
Storing the names of users who need access or using the group name?
Using a group name is far easier than storing the list of names. The reason to do this is if PowerShell were to cycle through each mailbox to determine access, it would be easier to see if they are a member of a group (single comparison) versus comparing a list of uses (multiple comparisons). The single comparison method is much faster.
What access should be granted or denied depending on group membership?
In this case, the requirement was to allow certain user’s access to POP3 and block all other users from using POP3. Going back to the Get-CASMailbox cmdlet, ‘OWA Enabled’ is an option that can be configured on a mailbox. Get CASMailbox has a set-command for changing settings – Set-CASMailbox. Not knowing what options that can be configured, we can run a ‘Get-Help Set-CASMailbox –Full’ to see what options can be changed, while specifically looking for POP3 and IMAP4:
Looking closely at the options we see IMAPEnabled and POPEnabled. Both have two settings - $True and $False. We can set these values for each mailbox in Exchange Online.
It is worth noting here that if you have used Exchange on-premises you will see the lack of IMAP and POP PowerShell cmdlets that could be used to configure these settings. For example if we run ‘Get-Command *IMAP*’ Wee see that there are three cmdlets we can choose from:
Get-ImapSubscription
New-ImapSubscription
Set-ImapSubscription
These cmdlets can be used for ingestion purposes and are not intended for use as client protocol settings. This means that we are indeed limited to the Set-CASMailbox cmdlet as show above. Now, there are configurable options beyond simply enabling the protocol on a per mailbox or a global basis with the cmdlet:
- ImapForceICalForCalendarRetrievalOption
- ImapMessagesRetrievalMimeFormat
- ImapSuppressReadReceipt
- ImapUseProtocolDefaults
However, as we can see by the available options, these are not related to how a client connects to Office 365 with the IMAP protocol. In order for a client to connect, it must be configured according to Microsoft’s official documentation on this - https://technet.microsoft.com/en-us/library/dn551174(v=exchg.150).aspx.
With the base command figured out, the next step is to use these cmdlets to set the access for all mailboxes or for some mailboxes based off of group membership. How can group membership be verified?
What commands can we use to query this information in Exchange?
First, we need to store the group name in a variable:
$POPGroup = Get-MSOLGroup -All | Where-Object {$_.DisplayName -eq “POP3 Access”}
$IMAPGroup = Get-MSOLGroup -All | Where-Object {$_.DisplayName -eq “IMAP Access”}
Then we can get a list of users in that group:
$POPAccess = Get-MSOLGroupMember -GroupObjectId $PopGroup.ObjectId -All | Select-Object -ExpandProperty DisplayName
$IMAPAcess = Get-MSOLGroupMember -GroupObjectId $ImapGroup.ObjectId -All | Select-Object -ExpandProperty DisplayName
** Note ** These cmdlets need to be run after a connection to the MSOL Service has been made.
What commands can we use to add or remove access to the resource?
As discussed above, one PowerShell cmdlet and two parameters will allow for the changing of access to IMAP or POP:
Set-CASMailbox –IMAPEnabled $True
Set-CASMailbox –POPEnabled $True
$False would be used to disable access to those not in these groups.
Putting It Together
Then, using the names of the groups stored in $MemberOf, check for any groups that match our POP3 Access groups and then set POP3access:
If ($MemberOf -Like “*POP3 Access*”) { Set-CasMailbox $Alias –POPEnabled $True}
Putting these pieces together, we can create a script like this: (note we are excluding the Discovery mailbox as well)
# Group Names
$POPGroup = Get-MSOLGroup -All | Where-Object {$_.DisplayName -eq “POP3 Access”}
$IMAPGroup = Get-MSOLGroup -All | Where-Object {$_.DisplayName -eq “IMAP Access”}
# Group Membership
$POPAccess = Get-MSOLGroupMember -GroupObjectId $PopGroup.ObjectId -All | Select-Object -ExpandProperty DisplayName
$IMAPAccess = Get-MSOLGroupMember -GroupObjectId $ImapGroup.ObjectId -All | Select-Object -ExpandProperty DisplayName
# Set POP Access - Remove all and then set those allowed
Get-Mailbox | Set-Mailbox -POPEnabled $False
Foreach ($Mailbox in $POPAccess) {
Set-CASMailbox $Mailbox -POPEnabled $True
}
# Set IMAP Access - Remove all and then set those allowed
Get-Mailbox | Set-Mailbox -IMAPEnabled $False
Foreach ($Mailbox in $POPAccess) {
Set-CASMailbox $Mailbox -POPEnabled $True
}
Prior to running the above script, validate who has the setting enabled or disabled: (note what mailboxes are disabled)
After the script is run, ONLY John and Richard would get POP3 access, all others remain disabled ($False) because they are members of the correct group.
For the IMAP configuration, we would also see something similar:
Before the script:
After the script:
How often we would want reinforce this action?
Once the script is created, we would then need to decide how and when to enforce these settings. Running the script weekly and daily would be ideal from a restrictive access view. The script can be deployed as a cleanup tool or enforcement tool using the Windows scheduler, setting up jobs to handle these changes on a weekly or daily basis.
What is it?
Client Access Rules are specifically designed to control access to Exchange Online by allowing or blocking different types of client connections. These rules are similar to Transport Rules that we would use to control the flow of email in Exchange Online. We can control whether MAPI is allowed, PowerShell connections allowed and also control these by group or user just for some examples of what is allowed. Now, these rules are different from Conditional Access as Client Access Rules controls authentication for Exchange Online whereas Conditional Access can control access to other workloads beyond Exchange as well as determining MFA requirements for those apps.
When it comes to PowerShell and Office 365 one thing is for sure, change is constant. Nothing can be more revealing than 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 in January of 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
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 – Define single IP or IP Ranges as a criteria for the rule.
- 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 user names 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.
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
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, we need to block access for any user to POP, IMAP and OWA:
New-ClientAccessRule -Name ‘Block Protocols’ -AnyOfProtocols Pop,Imap,OutlookWebApp -Action DenyAccess
Notice there are no parameters for users or attributes or any other checks. Simply blocks these forms of access from your Exchange Online Tenant. Use rules like this carefully. Test it out to make sure it meets your company’s needs.
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
Make sure to test this rule prior to moving it into production.
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 shown previously, we need to provide the Test cmdlet with at least this information:
- Protocol
- RemoteAddress
- AuthenticationType
- RemotePort
- User
Sample run from 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’
Final Thoughts on Client Access Rules
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.