Office 365 Internet Explorer Security Settings – The Final Frontier

On the post http://www.tuomi.ca/2014/06/23/overcoming-sticky-logouts-office-365-azure-windows-intune-web-browser/, I tried to rationalize IE security settings relating to Office 365.

I spent a good three hours last night trying to understand why http://support.microsoft.com/kb/2507767 indicates that Office 365 users should have their Internet Explorer security zones set with the main properties in both Trusted & Intranet security Zones. Any authoritative () advice on if we’ve been wrong all these years advising just the Intranet Zone in https would be great!

Trusted Sites Zone:
https://*.microsoftonline.com
https://*.sharepoint.com
https://*.outlook.com
https://*.lync.com
https://*.office365.com
https://*.office.com
https://*.microsoftstream.com
https://*.sway.com
https://*.powerapps.com
https://*.yammer.com

Intranet Zone:

*.microsoftonline.com
*.sharepoint.com
*.outlook.com
*.lync.com
*.office365.com
*.office.com
*.microsoftstream.com
*.sway.com
*.powerapps.com

To my understanding the two base requirements for dual zones are WebDAV’y type stuff and ADFS SSO:

Theory 1: WebDAV
is that the intranet zone entries cater to the URLs without a dot but mostly for \\ UNC-style shares/webdav.The trusted sites version serves standard FQDNs. The intranet zone serves everything else. The PROPFIND stuff involved with ActiveX when Office documents are opened by IE is also likely borked by improper zone-age.

For example, I access an O365 doc library with “Open with Explorer View”, and the URL WebDAV negotiates is:
https://keithtuomi.sharepoint.com/sites/keithsandbox/Shared Documents

BUT.. if I wanted to map that as a network drive the URL I would need to use would be:
\\keithtuomi.sharepoint.com@SSL\sites\keithsandbox\shared%20documents

Notice that literal https:// is not in play here.

For a similar approach, you can try the steps at http://www.chickenlip.com/Blog/tabid/826/PostID/114/Create-Sharepoint-Windows-Explorer-Shortcut-for-Office-365.aspx to connect a local folder to SharePoint library. Try it with and without the dual zones to see the difference- i couldn’t personally get any unexpected logouts or other ill behaviour to occur but that could be caching. Worth testing.

To see what’s happening under the hood, download the ie zone analyzer tool from http://blogs.technet.com/b/fdcc/archive/2011/04/14/iezoneanalyzer-v3.aspx.  I ran a comparison of the differences between my Surface’s IE11 Intranet Zone & Trusted Sites Zone.  There’s few yellow line items in there that Intranet Zone has that would make sense that you would want for full Explorer-like capabilities.

Looking at http://support.microsoft.com/kb/2019105 , they define the Intranet Zone as:
The Local Intranet zone is defined as all network connections that were established by using a Universal Naming Convention (UNC) path and websites that bypass the proxy server or that have names that do not include periods (such as http://local), as long as they are not assigned to either the Restricted Sites or to the Trusted Sites zone. The Trusted zone has a default configuration of automatic logon only in the Intranet zone.

Theory 2: ADFS SSO
On http://support.microsoft.com/kb/2535227 they direct us to ensure the “enable automatic login” is set. OOTB Internet Explorer is set on both Intranet and Trusted site zones to “Automatic Login in Intranet Zone only”.

If this is not done, the users will be prompted for credentials from the AD FS server. Adding the AD FS server farm address to the Local Intranet zone allows IE to pass your credentials to the webpage added to the zone.

SO, my thinking is that although you could of course manually adjust these individual security settings for different zones, it’s an easier pattern to follow to just have the Intranet Zone be the place where you want to have automatic logon enabled. This will allow Internet Explorer to automatically pass the user’s credentials to the AD FS server.

Of course, since we know that URL’s without a dot in the them (e.g. https://corpIntranet) are always shunted into the Intranet Zone no matter what, this is more fuel for the fire that we would want to be working from the from the Intranet zone, in the case that we were federating https://corpintranet to https://*.sharepoint.com . Is that scenario supported? I think so, cannot confirm or deny based on what I looked up but it would be a pretty common scenario I’d think.

Conclusion:
In the end, i’ve..:
– Gone a bit bonkers trying to sort this out
– Haven’t got a 100% feeling about advising people to set both zones with those URLs
– Come to believe there’s a bunch of dependencies and variations across versions of Internet Explorer and the various O365 systems that make the Intranet Zone the right call sometimes, and Trusted Sites the other. Having the zones dual-configured like described allows MS Support to support all the scenarios with one simple directive.

References:
https://blogs.technet.microsoft.com/victorbutuza/2016/06/20/o365-internet-explorer-protected-mode-and-security-zones/
– Latest URL’s added
http://support.microsoft.com/kb/2507767 – article ref’d in my post
http://support.microsoft.com/kb/2507767 – MS support confirming. MSFT Mikey comes in later in the thread and contradicts the dual zone setup directive
http://support.microsoft.com/kb/2507767 – breaks down how having a dot in name causes address to be treated as if it’s in the Internet zone instead of Intranet zone and how to overcome
http://support.microsoft.com/kb/2507767 – describes O365 desktop tool setup. http://www.msexchange.org/blogs/walther/news/office-365-identity-federation-credential-prompt-from-a-domain-joined-machine-714.html – ADFS SSO Intranet zone requirement
http://support.microsoft.com/kb/2535227/en-us – ADFS SSO Intranet zone requirement

 

Trackback from your site.

Comments (2)

  • Avatar

    John Meredith

    |

    I’m with you — my brain tried to jump out of my head and run away after about 45 minutes of this, especially when I found the Authoritative List of Office 365 DNS names (including all the CDNs) and pondered whether they need to be included or not….

    This silliness kind of entices people to just whitelist as much as possible and give up on real security best practices, which is a shame.

    Reply

    • Avatar

      Keith Tuomi

      |

      It is a shame it seems so under-documented, as having these types of assets blocked or inaccessible can HUGELY affect end users experiences. Working on it with both the documentation teams and through scripting – there should be some means to make a tool like IE Zone Analyzer that would proactively tell you if you’re missing an exclusion. That would be predicated of course on us knowing all the DNS entries. 🙂

      Reply

Leave a comment

Categories