A client was looking to limit access to mailboxes from outside the corporate network in order to improve data security. Because Outlook can cache mailbox information on a local machine, they would like their users to be able to connect to Outlook only from corporate machines. These are the requirements:
- Outlook users can only use corporate laptops to connect as long as they establish a VPN tunnel to the corporate network
- OWA can be used from any machine without restrictions
- ActiveSync can be used from any device but the device must be approved by an administrator
Active Directory Federation Services (AD FS) 2.0 provides a way to configure these types of policies. Office 365 customers using Single Sign-On (SSO) who require these policies can now use client access policy rules to restrict access based on the location of the computer or device that is making the request.
To enable client access policy, you must complete the following steps:
Step 1: Install the Update Rollup 2 for AD FS 2.0 package on your AD FS servers
Download the Update Rollup 2 for Active Directory Federation Services (AD FS) 2.0 package and install it on all federation server and federation server proxies. The package can be downloaded from http://support.microsoft.com/kb/2681584
Step 2: Add five claim rules to the Active Directory Claims Provider trust
After the Update Rollup 2 for Active Directory Federation Services (AD FS) 2.0 package has been installed on all federation servers and federation server proxies, and the AD FS Windows service has been restarted, use the following procedure to add a set of claim rules that make the new claim types available to the policy engine.
In this step, you will have to add five acceptance transform rules for each of the new request context claim types using the following procedure.
On the Active Directory claims provider trust, create a new acceptance transform rule to pass through each of the new request context claim types.
- Click Start, point to Programs, point to Administrative Tools, and then click AD FS 2.0 Management
- In the console tree, under AD FS 2.0\Trust Relationships, click Claims Provider Trusts, right-click Active Directory, and then click Edit Claim Rules
- In the Edit Claim Rules dialog box, select the Acceptance Transform Rules tab, and then click Add Rule to start the Rule wizard
- On the Select Rule Template page, under Claim rule template, select Pass Through or Filter an Incoming Claim from the list, and then click Next
- On the Configure Rule page, under Claim rule name, type the display name for this rule; in Incoming claim type, type the following claim type URL, and then select Pass through all claim values
- To verify the rule, select it in the list and click Edit Rule, then click View Rule Language. The claim rule language should appear as follows:
- c:[Type == “http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-forwarded-client-ip”%5D => issue(claim = c);
- Click Finish
- In the Edit Claim Rules dialog box, click OK to save the rules
- Repeat steps 2 through 6 to create an additional claim rule for each of the following claim types shown below until all five rules have been created.
|Rule Name||Issued Claim|
Step 3: Update the Microsoft Office 365 Identity Platform relying party trust
This step allows you to configure what type of clients to block. At Equitable, we have created a custom block scenario – Block all external access to Office 365, except Exchange ActiveSync and browser-based applications such as Outlook Web Access or SharePoint Online.
Below is the claim rule we configured for this scenario:
exists([Type == “http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-proxy”%5D) &&
NOT exists([Type == “http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-client-application”, Value==”Microsoft.Exchange.Autodiscover”]) &&
NOT exists([Type == “http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-client-application”, Value==”Microsoft.Exchange.ActiveSync”]) &&
NOT exists([Type == “http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-endpoint-absolute-path”, Value == “/adfs/ls/”])
NOT exists([Type == “http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-forwarded-client-ip”, Value=~”\b123\.123\.123\.1\b|\b134\.134\.134\.2\b”]) &&
=> issue(Type = “http://schemas.microsoft.com/authorization/claims/deny”, Value = “true”);
Once configured, the ADFS services were restarted and confirmed through testing to be accurate. This change only needed to be done on the first ADFS server installed in the farm as it holds the master copy of the Windows Internal Database (WID).