Updated 20th April 2017

There is an excellent article at http://blogs.technet.com/b/askds/archive/2012/06/26/an-adfs-claims-rules-adventure.aspx which discusses the use of Claims Rules in AD FS to limit some of the functionality of Office 365 to specific network locations, such as being only allowed to use Outlook when on the company LAN or VPN or to selected groups of users. That article’s four examples are excellent, but can be supplemented with the following scenarios:

• OWA for Devices (i.e. OWA for the iPhone and OWA for Android), also known as Mobile OWA
• Outlook Mobile Apps
• Using Outlook on a VPN, but needing to set up the profile when also on the VPN
• Outlook restrictions when using MAPI over HTTP
• Legacy Auth and Modern Auth Considerations

OWA for Devices and AD FS Claims Rules

OWA for Devices is an app available from the Apple or Android store and provides mobile and offline access to your email, adding to the features available with ActiveSync. Though OWA for Devices is OWA, it also uses AutoDiscover to configure the app. Therefore if you have an AD FS claim rule in place the blocks AutoDiscover you will find that OWA for Devices just keeps prompting for authentication and never completes, though if you click Advanced and enter the server name by hand (outlook.office365.com) then it works.

Using OWA for iPhone/iPad diagnostics (described on Steve Goodman’s blog at http://www.stevieg.org/2013/08/troubleshooting-owa-for-iphone-and-ipad/) you might find the following entries in your mowa.log file:

[NetworkDispatcher exchangeURLConnectionFailed:withError:] , “Request failed”, “Error Domain=NSURLErrorDomain Code=-1012 “The operation couldn’t be completed. (NSURLErrorDomain error -1012.)” UserInfo=0x17dd2ca0 {NSErrorFailingURLKey=https://autodiscover-s.outlook.com/autodiscover/autodiscover.xml, NSErrorFailingURLStringKey=https://autodiscover-s.outlook.com/autodiscover/autodiscover.xml}”

And following the failure to reach https://autodiscover-s.outlook.com/autodiscover/autodiscover.xml successfully you might see the following:

[NetworkDispatcher exchangeURLConnectionFailed:withError:] , “Request failed”, “Error Domain=ExchangeURLConnectionError Code=2 “Timeout timer expired” UserInfo=0x17dc6eb0 {NSLocalizedDescription=Timeout timer expired}”

and the following:

[PAL] PalRequestManager.OnError(): ExchangeURLConnectionError2: Timeout timer expired

[autodiscover] Autodiscover search failed. Error: ExchangeURLConnectionError2: Timeout timer expired

[actions] Action (_o.$Yd 27) encountered an error during its execution: Error: Timeout timer expired

[autodiscover] TimerCallback_PeriodicCallback_HandleFailedAutodiscoverSearch took too long (XXXms) to complete

The reason is that the first set of AutoDiscover lookups work, as they are connecting to the on-premises endpoint and authentication for this endpoint does not go through AD FS. When you reach the end of the AutoDiscover redirect process you need to authenticate to Office 365, and that calls AD FS – and that might be impacted by AD FS claims rules.

The problem with OWA for Devices and claims rules can come about by the use of the AD FS Claims Rules Policy Builder wizard at http://gallery.technet.microsoft.com/office/Client-Access-Policy-30be8ae2. This tool can be adjusted quite easily for AD FS 2012 R2 (change line 218 to read “If (($OSVersion.Major –eq 6) –and ($OSVersion.Minor –ge 2))” (look for AD FS servers that are –ge [greater or equal to 2] rather than just 2). The AD FS Claims Rules Policy Builder has a setting called “Block only external Outlook clients” – and this blocks Outlook, Exchange Web Services, OAB and AutoDiscover from being used apart from on a network range that you provide. The problem is that you might want to block Outlook externally, but allow OWA for Devices to work.

To solve this problem make sure you do not block AutoDiscover in the claims rules. In the “Block only external Outlook clients” option, its the 2nd claim rule that needs to be deleted, so you end up with just the following:

With AutoDiscover allowed from all locations, but EWS and RPC blocked in Outlook, you still block Outlook apart from on your LAN, but you do not block OWA for Devices. Use exrca.com to test Outlook Autodiscover after making this change and you should find that the following error is not present when AutoDiscover gets to the autodiscover-s.outlook.com stage.

The Microsoft Connectivity Analyzer is attempting to retrieve an XML Autodiscover response from URL https://autodiscover-s.outlook.com/Autodiscover/Autodiscover.xml for user user@tenant.mail.onmicrosoft.com.

The Microsoft Connectivity Analyzer failed to obtain an Autodiscover XML response.

An HTTP 401 Unauthorized response was received from the remote Unknown server. This is usually the result of an incorrect username or password. If you are attempting to log onto an Office 365 service, ensure you are using your full User Principal Name (UPN).HTTP Response Headers:

If you changed an existing claims rule you either need to restart the AD FS service or wait a few hours for it to take effect.

OWA Apps and AD FS Claims Rules

The above section covers why MOWA (Mobile OWA) needs AutoDiscover to work. The same is true for any client application such as ActiveSync or Outlook for iOS / Outlook for Android / Windows Mail etc that needs to run AutoDiscover to determine your mailbox settings. Therefore, as in the above section ensure you are not blocking AutoDiscover from external networks unless apps on mobile devices are also only allowed to work on your WiFi.

Outlook with AD FS Claims Rules and VPN’s

As mentioned above, Outlook can be limited to working on a given set of IP ranges. If you block AutoDiscover from working apart from on these ranges (as was the issue causing OWA for Devices to fail above) then you can have issues with VPN connections.

Imagine the following scenario: Web traffic goes direct from the client, but Outlook traffic to Office 365 goes via the LAN. A split tunnel VPN scenario.

In this example, if AutoDiscover and initial profile configuration has never run you have a claims rule that allows Outlook to work on the VPN (as the public IP’s for your LAN/WAN are listed in the claims rules as valid source addresses), but AutoDiscover fails due to the same rules (as the web traffic is coming from the client and not the LAN). Therefore AutoDiscover fails and Outlook is never provisioned, so it appears as if Outlook is being blocked by the claim rules even though you are on the correct network for those claim rules.

Outlook with MAPI over HTTP

Updated April 20th 2017

A new connection protocol was released with Exchange Server 2013 SP1 called MAPI/HTTP and has been available in Exchange Online for a time before the release of it on-premises. After this protocol was released, support was made available for it from a range of client versions and currently it works with Outlook 2010 and later (as long as you are on the supported versions and not Outlook 2010 SP1 for example). There is no support for MAPI/HTTP on Outlook 2007 which is why this client will stop working with Office 365 in October 2017 (as Microsoft turn off RPC/HTTP at that time).

With this new protocol in place for Outlook 2010, it is important to ensure that the AD FS claim rule for x-ms-client-application with a value of Microsoft.Exchange.RPC is updated to include Microsoft.Exchange.Mapi and Microsoft.Exchange.Nspi. And come October 2017 when RPC/HTTP is turned off in Exchange Online, claim rules could be updated to remove Microsoft.Exchange.RPC from their checks.

Therefore if you are an Exchange Online user with claims rules for AD FS you need to add the following rules. These would have the same IP ranges as your Microsoft.Exchange.RPC rule and would be identical to this rule in every way, just the x-ms-client-application string needs to look for the following (one rule for each):

• Microsoft.Exchange.Mapi
• Microsoft.Exchange.Nspi

The Microsoft.Exchange.Mapi rule can be named “Outlook MAPI/HTTP” and the Nspi rule can be named “Outlook MAPI Address Book”. You need to keep the Exchange Web Services and Exchange Address Book rules in place, but once all users are migrated to MAPI/HTTP you can remove the Microsoft.Exchange.RPC rule.

Note that Exchange Online caches your AD FS credential’s for 24 hours for connections from a single IP address, so if you successfully connect to Exchange Online (say because you have not got the Microsoft.Exchange.Mapi block in place) then you will not connect back to AD FS for 24 hours and so not be affected by new rules that are added after you connect. If you want to test if your new Microsoft.Exchange.Mapi block rules work then you need to connect to Exchange Online via a different IP address, so a trip to the nearest coffee shop in the quest for network lockdown on your companies expense is called for!

Also it is possible to create a single rule rather than the multiple rules listed above. A single rule would contain the claim rule clause similar to the below:

exists([Type == "http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-client-application", Value =~ "Microsoft.Exchange.WebServices|Microsoft.Exchange.RPC|Microsoft.Exchange.Mapi|Microsoft.Exchange.Nspi"])

Note that this is different from what the Rule Builder wizard creates, as that creates a string comparison value, which is compared to the result with ==, but when more than one possible string is stored in the value the comparison operator needs to be =~ which is string compared to RegEx, as the | sign makes the value in the claim rule a RegEx expression.

Legacy Clients and Outlook 2016

Outlook 2016 supports modern authentication out of the box (unlike Outlook 2013 which required client side registry keys and certain hotfixes). But you still need to enable Modern Authentication on your tenant in Exchange Online.

To check if Modern Auth is enabled run Get-OrganizationConfig | FL *OAuth2* from a remote PowerShell session connected to Exchange Online. The value of OAuth2ClientProfileEnabled will be $True if Modern Authentication is enabled. If it is not enabled then Outlook 2016 will use Legacy authentication protocols and so will be blocked by the claim rules discussed here. If you enable Modern Auth though, Outlook 2010 is impacted by Claim Rules and Outlook 2013 June 2015 update + reg keys and Outlook 2016 and later are not impacted by the claim rules above (see below for these). Outlook with Modern Auth is restricted with the use of Conditional Access in Azure AD Premium. If you do not turn on Modern Auth you can use the legacy auth claim rule restrictions until the point where Microsoft enable Modern Auth for you – therefore it is best that if you are doing this then make your changes at your schedule and enable Modern Auth now, EMS to block Outlook 2016 and claim rules to block Outlook 2010 until the point where Microsoft removes support for that product.

Therefore a single claims rule for blocking legacy auth would look like the following:

exists([Type == "http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-proxy"])
 && exists([Type == "http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-client-application", Value =~ "Microsoft.Exchange.WebServices|Microsoft.Exchange.RPC|Microsoft.Exchange.Mapi|Microsoft.Exchange.Nspi"])
 && NOT exists([Type == "http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-forwarded-client-ip", Value =~ "\b51\.141\.11\.170\b"])
 && exists([Type == "http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-endpoint-absolute-path", Value == "/adfs/services/trust/2005/usernamemixed"])
 => issue(Type = "http://schemas.microsoft.com/authorization/claims/deny", Value = "true");

Note that in the above, though this comes from ADFS on Windows Server 2012 R2, we are still recommending the use of x-ms-proxy and x-ms-forwarded-client-ip. That is because the insidecorporatenetwork claim cannot be used for legacy authentication, as all auth request originate from Exchange Online (active auth) which is never on-premises! This claim rule is added to the Office 365 Relying Party Trust Issuance Authorization Rules after the default Permit Access to All Users rule that the Convert-MSOLDomainToFederated cmdlet or AADConnect configures. The claim rule permits access to all, then denies access if an legacy authentication session happens for Outlook protocols where the forwarded IP address is not the public IP for your LAN

Use Claim Rules to Block Modern Auth Clients

So the final scenario here, newly added to this old post in April 2017, requires issuing deny’s to claims when insidecorporatenetwork is false for the protocols/user agents that you want to block. For example the following will block all modern auth requests from outside the network from all applications apart from ActiveSync and AutoDiscover (as AutoDiscover is used by ActiveSync to set up the mobile device initially):

exists([Type == " http://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork", Value == "false"])
 && NOT exists([Type == "http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-client-application", Value =~ "Microsoft.Exchange.ActiveSync|Microsoft.Exchange.Autodiscover"])
 && exists([Type == "http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-endpoint-absolute-path", Value == "/adfs/ls/"])
 => issue(Type = "http://schemas.microsoft.com/authorization/claims/deny", Value = "true");