For many organizations, a move to Office 365 brings new options for accessing services, such as Microsoft Exchange,...
over the Internet. Even though many organizations provide access to Outlook Web App, Outlook Anywhere or ActiveSync, some don't want end users to access email from an Internet cafe, a personal device or anywhere outside the office. If your organization fits into the latter category, you should build a Client Access Policy.
Office 365 is an Internet-based service, which means that unless you buy Microsoft's dedicated offering, all clients must traverse the public Internet to access it. Some organizations mandate client access be from secured (often corporate) devices.
Out of the box, one advantage of Office 365 is you don't need to be on a corporate device. You can access provided services, including installing Outlook and downloading email, from anywhere with Internet connectivity. For some organizations, especially those that work with financial or personal information, the ability to connect any device this way means they could potentially breach regulations or internal business policies.
For Office 365 to be a viable technology, moving services such as email to it means having the ability to restrict who can access it -- and from where -- as well as what's essential. But it's more complicated than restricting who and what can access the Active Directory Federation Services (AD FS) servers federated with Office 365.
Outlook is an active client, which means the client sends the username and password to Office 365, which then reaches out and authenticates on the end user's behalf. Unless you only want to use basic browser-based services such as OWA and SharePoint, you'll need to provide access to AD FS from Office 365 addresses. By default, any Outlook client with the correct credentials can authenticate whether or not the AD FS servers are exposed to the wider Internet.
Microsoft knows this is a requirement for many organizations, so it built in a feature called Client Access policies.
Available features and key requirements
A Client Access Policy is one of a number of basic policies Microsoft supports for restricting access to Office 365:
- Block all external access to Office 365 services;
- Block all external access to Office 365 services, except from ActiveSync devices;
- Block all external access to Office 365 services, except from passive (e.g., browser-based -- OWA or SharePoint Online) clients;
- Block all external access to Office 365 services to members of specific Active Directory Groups;
- Block only external Outlook clients.
When we say "block all external access," this means from IP address ranges you don't specify. If VPN clients access Office 365 through your Internet breakout, they are classified as internal. All of these policies block access to Lync Online and the licensing services for Office 2013 from external clients.
On the server side, you need to make sure you meet two minimum requirements:
- AD FS 2.0 Update Rollup 2, AD FS 2.1 or AD FS 2012 R2;
- AD FS proxy, Web Application Proxy or a reverse proxy that meets these requirements outlined.
AD FS and the Office 365 tenant should be in a good, working state. This typically means that one or two test mailboxes have been configured and you've tested authentication across clients.
You'll need to choose which of these scenarios best meets your requirements, and make sure you have a complete list of external IP addresses or IP address ranges from which internal clients will come.
Implementing a Client Access Policy
The documentation for Client Access policies on TechNet can seem complex if you're looking to go off the beaten track or build your own regular expressions for IP address ranges. But there's a simpler way to set them up.
By using Microsoft's Client Access Policy Builder, which is a PowerShell script that gives you a graphical user interface, you can implement changes using a helpful wizard. To get started, simply download the script to your primary AD FS server. If you're running Windows Server 2012 R2, you'll need to make a small adjustment to the script before execution to ensure it correctly loads the AD FS module.
Search for the following line:
If (($OSVersion.Major -eq 6) -and ($OSVersion.Minor -eq 2))
Replace the -eq with -ge so it detects we're running 2012 R2 (minor version 3):
If (($OSVersion.Major -eq 6) -and ($OSVersion.Minor -ge 2))
We've completed the hard part. Now, launch the Client Access Policy builder. You'll see the builder UI as a simple one-page form. When you're ready to make the changes, locate Step 1 and choose Create Rules for Claim Types (Figure 1).
After creating the claim types, enter the settings specific to your scenario. For our example, we'll choose to block all external access except for Exchange ActiveSync, and then enter our organization's external IP address. When we're happy with the new configuration, we'll choose Build (Figure 2).
After making the changes, we can verify they've been applied within the AD FS Management Console. Navigate to Trust Relationships > Claims Provider Trusts and locate Active Directory. Then choose Edit Claim Rules (Figure 3). You'll see five new rules as described in Step 2 of the TechNet article referenced above (Figure 4).
You can then verify that the rules to block Office 365 access from external clients were applied by navigating to Trust Relationships > Relying Party Trusts then choosing Edit Claim Rules for the Microsoft Office 365 Identity Platform (Figure 5).
The Edit Claim Rules window should appear. Select Issuance Authorization Rules, check that you have a new claim listed named Block all external access to Office 365 and then choose Edit Rule (Figure 6).
You'll see the contents of the rule. ActiveSync is explicitly mentioned, along with the external IP address (Figure 7).
You don't need to make any changes to what's here unless you want to delete the new rules.
As with any change, ensure that the AD FS alternations have the expected results. Access from internal clients and Exchange ActiveSync clients should be unaffected. Access from external clients should result in a Not Authorized error message on attempted sign-in using a browser or refusal to accept the password in Outlook.
About the author
Steve Goodman is an Exchange MVP, and works as a technical architect for one of the U.K.'s leading Microsoft Gold partners. Goodman has worked extensively with Microsoft Exchange since version 5.5 and with Office 365 since its origins in Exchange Labs and Live@EDU.