Users can’t connect to Outlook in a 100% cloud, Federated Environment

  • [アーティクル]

By: Cesar Hara, Caio Ribeiro César

Outlook Connectivity is known to be a high volume support topic. The one described in this post is about a 100% Cloud structure, with the domain being federated (ADFS 3.0 and WAP).

Whenever administrators get Outlook Connectivity issues, they start by isolating the issue – there are dependencies for Outlook to successfully communicate with Exchange Online, and these layers must be split in a step-by-step procedure.

First, the basic stuff: environment.

Outlook will use different ways to connect to Exchange. Considerations are:

  • 100% Cloud: Autodiscover points to the cloud, Outlook clients get mailbox information from the XML and connect to the ExO server;
  • Hybrid Environments: recommendation is for Autodiscover record to point to the CAS servers. Meaning that the CAS is the one responsible for onprem mailboxes to connect or to identify oncloud mailboxes based on the targetaddress value;
  • Federated Organizations: authentication is a dependency for Outlook to connect to Exchange Online. This means that if Single Sign On is not working, Outlook won’t connect to ExO.

Depending on the situation, there are different troubleshooting steps and data to collect.

After we know the environment (in this example, 100% cloud mailboxes and federated organization), we can start by understanding the issue.

  1. What is the behavior? A.: Outlook doesn’t connect to Exchange. Users can connect to OWA and to the Portal without any issues.

If we try to add the account to Outlook, it loads in “server settings”. We get prompted several times for a password, without connecting to ExO:

1 2

2) Exchange Remote Connectivity Analyzer. We select “Office 365>Outlook Connectivity”, since it will test Autodiscover and RPC/HTTP or MAPI/HTTP.

3

After running the test, we get the following error message:

4

“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: request-id: 73238ecc-cdbc-492db5a X-CalculatedBETarget: ro1pr80mb1994.lamprd80.prod.outlook.com X-FEServer: DM2PR30CA0055 Content-Length: 0 Cache-Control: private Date: Fri, 12 Aug 2016 12:55:23 GMT Server: Microsoft-IIS/8.0 WWW-Authenticate: Basic Realm="" X-AspNet-Version: 4.0.30319 X-Powered-By: ASP.NET “

We can understand from the error that Autodiscover has failed to retrieve the XML. We can confirm this by running Test Email AutoConfiguration:

5

Or by getting a fiddler trace when prompted for password:

https://autodiscover-s.outlook.com/autodiscover/autodiscover.xml
HTTP/1.1 401 Unauthorized
Cache-Control: private
Server: Microsoft-IIS/8.0
request-id: 90c08569-b12a-405b-8a8b-4750d70e2c70
X-CalculatedBETarget: cp1pr80mb1128.lamprd80.prod.outlook.com
X-AspNet-Version: 4.0.30319
WWW-Authenticate: Basic Realm=""
X-Powered-By: ASP.NET
X-FEServer: SY3PR01CA0062
Date: Fri, 19 Aug 2016 19:01:06 GMT
Content-Length: 0

Httpstatus 401 (Unauthorized) shows that Outlook might lack valid authentication credentials for the target resource, or that authorization has been refused.

Next question is: is there any configuration in the Organization that might block Outlook from connecting to EXO? In this scenario, ADFS Claim Rules. Caveat: rules are set to block external access, and we can reproduce this behavior either internally and externally. Why?

Since this environment is federated and all mailboxes are hosted in Exchange Online, it means Outlook will not communicate directly with the ADFS server. O365 is responsible for this interaction, and for this reason, the authentication request hits ADFS as external.

Next step is to review ADFS Server event viewer 325 events (Applications and Services Logs > AD FS):

6

Highlighted messages are descriptive: “The Federation Service could not authorize token issuance for caller” ; “See event 501 with the same Instance ID for caller identity”.

If event 501 is expanded, we obtain more information about the token issuance authorization:

7

This means that a Claim Authorization Rule in ADFS is active, blocking this communication. In order to confirm, expand the following options in your ADFS Server:

Trust Relationships > Relying Party Trusts (RP) > Right Click on the O365 Relying Party, select “Edit Claim Rules, go to the Issuance Authorization Rules tab:

8

Edit the “Block External Access” rule and validate if the IP Address informed in the 501 event is added to it as an exception:

9

In the example above, the IP address is not added. Meaning it will by default block this external communication. After validating that the connection is from a valid trusted source using the claim rules regular expressions model, add the address (or range):

10

After adding the Public IP address to the rule, a new Autodiscover test is done:

11

We try to log to Outlook again from inside the network, this time with success.

In summary...

The claim rule was working as expected – since the external IP address from the connection wasn’t added to the exception. This can also happen to other filters, such as AD groups (event 501 will inform the group SID).

If needed, ADFS also has the possibility to enable audit mode - so you can trace each call with more verbose information.

Comments

  • Anonymous
    September 28, 2016
    Thanks