High Level O365 Recommendations

Office 365 is a web-based service from Microsoft. Because it expects that the client and server are in direct communication, some ProxySG appliance configurations can interfere with access. Some issues are inherent to Office 365 and cannot be mitigated. The following sections describe high-level Office 365 issues—that is, issues not pertaining to a specific application within Office. When possible, best practices are provided. Otherwise, only the observed behavior is provided.

Symantec has a working relationship with Microsoft. If future updates from either side address these issues, these sections will be updated.

Required SGOS Releases

  • SGOS 6.5.10.4+
  • SGOS 6.7.2+

Known Issue with SGOS 6.5.9.14

B#243071—Disable SSL Detection policy prevents access to specific HTTPS URLs.

The following issue is resolved in SGOS 6.5.9.15. See below.

Symptom

  • ProxySG appliance running SGOS 6.5.9.14.
  • You have policy rules where Detect Protocol is set to No for SSL/HTTPS or HTTPS/SSL traffic (Disable SSL Detection object) for specific URLs. For example:

  • As a result, the clients are not able to connect to the specified destinations and receive connection error exceptions.

Workaround

Symantec is working on an update. Perform the following steps for SGOS 6.5.9.14.

  1. Disable all rules that match the rules described in the Symptom section above.

    Right-click the No. column and select Disable.

  2. Add entries to a CPL Layer (add a new layer or edit an existing layer) that match the VPM rules. For example:

    <Proxy>
    url.domain=//www.symantec.com/ detect_protocol[ssl, https, sips](no)

  3. Click Install Policy.

    If you encounter unexpected results, verify the ordering of your rules in layers are not affecting policy matches.

Fix: SGOS 6.5.9.15

The SGOS 6.5.9.15 update provides a resolution. However, you must perform an additional task.

  • If you previously used the Disable SSL Detection VPM object: After upgrading to a build with the fix (6.5.9.15+), you must open the VPM and click Install Policy again to get the correct policy.
  • If you manually installed CPL policy similar to detect_protocol[ssl,https](no), edit that policy to add ,sips after https. This allows the policy to maintain the same behavior in 6.5.9.15+ as in 6.5.9.14.

Port Exhaustion

Because proxies typically are deployed with Network Address Translation (NAT), the Internet believes that traffic from all clients come from a single IP address. This means the proxy will likely easily exceed more than the allowed connections.

Refer to Avoid Port Exhaustion to learn more and perform steps to mitigate.

Tenant Restrictions

Microsoft created an article titled Use Tenant Restrictions to Manage Access to SaaS Cloud Applications. Both the ProxySG and Advanced Security Gateway (ASG) appliances support this implementation. If you require this configuration, follow these articles.

Use of SAML

If you employ SAML authentication, an challenge exists where an Office 365 application—for example, Outlook—constantly displays an authentication challenge dialog. The likely cause is that SSL Interception is enabled, which currently has an issue with channel binding tokens (CBTs).

To mitigate this until a resolution is provided, bypass the SAML Identity Provider (IDP) URL.

Protocol Detection might also cause this behavior.

Explicit: Outlook-to-Exchange Connection is Slow

Symptom

The ProxySG appliance is deployed in Explicit Proxy mode, which means it receives web requests from PAC instructions on client systems and uses one or a select few IP addresses to connect to the Internet. Outlook attempts to connect directly to the Exchange servers, ignoring the explicit proxy settings. The firewall outbound settings prevent (either drop or block) Outlook from connecting. As Outlook proceeds through the IP addresses returned by DNS, the user views the behavior as Outlook trying to connect.

Workaround?

None at this time, given that this is caused by native Office 365/Outlook architecture. Presented as a behavior awareness item.

Unable to Activate Office 2013 or Windows 8

Symptom

Attempts to activate Windows 8 or Office 2013 applications through a ProxySG appliance or Advanced Secure Gateway appliance fail. This is caused by the involved servers are signed by an untrusted certificate authority.

Workaround?

  1. In the VPM, create a new rule in an SSL Access Layer.
  2. Set the Destination to a Request URL with a simple match to activation.sls.microsoft.com.
  3. Right-click Action and select New > Set Server Certificate Validation.
  4. Select the Disable server certificate validation option.
  5. Copy the rule. In the new rule, set the Destination to validation.sls.microsoft.com.

Error When Loading Office Help Files

Symptom

  • You have a Notify User coaching page enabled.
  • You cannot load the Help pages from within Microsoft Office.
  • During loading of the help files, you are prompted to Accept the notify page.
  • After accepting the Notify page, you receive the error message:

    Request Error (invalid_request) Your request could not be processed. Either 'deny' or 'exception' was matched in policy. This could be caused by a mis-configuration, or possibly a malformed request.

  • After clicking Accept during the notify process, Microsoft Office loads a new web browser window. When this occurs, the Referer header is lost:

    Referer: http://notify.bluecoat.com/notify-NotifyUser2?http/office.microsoft.com/aHR0cDovL29m<snip>

    This is required for the Notify User process to complete successfully otherwise the coaching page fails.

Workaround?

Bypass the Notify User rules for office.microsoft.com.

  1. In the VPM, locate the Web Access Layer that contains the Notify User object as an Action.
  2. Create a rule before this rule.
  3.  Set the Destination to a Request URL with a simple match to office.microsoft.com.
  4.  Set the Action to None.

    When Help files are requested, the policy evaluation matches rule 1, so the Notify User action is not triggered.

Microsoft Office 365 URLs and IP Address Ranges

Office 365 URLs and IP Address ranges are published and maintained by Microsoft Corporation. This reference is useful should you attempt to bypass or allow Microsoft Office 365 destination URLs or IP addresses through the ProxySG appliance.

Microsoft Reference

Symantec has no control of the URLs and IP Address ranges Microsoft selects to use as part of the Microsoft Office 365 Server pool.

Knowledge Base Articles

Symantec Technical Support publishes Knowledge Base (KB) articles as issues are discovered and discussed. The following article contains links to all other articles.

https://support.symantec.com/en_US/article.TECH246150.html

 

www.symantec.com