Compartilhar via

The Intranet Zone

  • Artigo

Internet Explorer maps web content into one of five security zones. After the Local Machine Zone, the Local Intranet Zone is probably the most misunderstood of the Zones, and is a common source of confusion and compatibility glitches.

Mapping into the Local Intranet Zone

For the Trusted and Restricted Sites zones, Zone Mapping is simple. URLMon checks the URL’s origin against the URL patterns in the user’s Zone mapping table, displayed inside Tools > Internet Options > Security > [Zone] > Sites. The Local Machine Zone is a bit more complicated, but I’ve written about that before. Sites that aren’t mapped to the Local Machine, Trusted, Restricted or Local Intranet Zones will be defaulted to the Internet Zone.

So, that leaves only the Local Intranet zone. How does the browser decide whether a resource should be mapped to the Local Intranet zone rather than defaulting to the Internet Zone? This mystery led to one of my very first investigations when I joined the Internet Explorer team.

Some might guess that the browser simply resolves the hostname using DNS and then maps “private” IP addresses (defined in RFC1918) to the Intranet zone. While that’s a fine guess, it’s actually incorrect, and the MapUrlToZoneEx2 function doesn’t take the IP address of the target site into account at all. There are a few reasons for this, including the fact that some large organizations have public IP addresses for hosts on their “Intranet” and that URLMon needs to be able to determine the Zone of a site even if that site isn’t presently reachable or listed in DNS.

Instead, determination that a site belongs to the Local Intranet Zone is based on a number of rules:

  1. Direct Mapping. As with other Zones, users or network admins may map a list of URL patterns into the Local Intranet Zone. This list is viewable by clicking Tools > Internet Options > Security >  Local Intranet > Sites > Advanced.
  2. The PlainHostName rule (aka "The Dot rule") . If the URI’s hostname doesn’t contain any periods (e.g. https://team/) then it is mapped to the Local Intranet Zone.
  3. The fixed Proxy Bypass list. If the user has a fixed proxy specified inside Tools > Internet Options > Connections > LAN Settings, then sites listed to bypass that proxy will be mapped to the Local Intranet zone. The fixed proxy bypass list can be found by clicking the Advanced button; it’s at the bottom of the screen in the box labeled Exceptions.
  4. (WPAD) Proxy Script. If the user’s proxy configuration is “Automatically detect settings” or “Use automatic configuration script” inside Tools > Internet Options > Connections > LAN Settings, the browser will run the FindProxyForUrl function in the specified WPAD proxy configuration script to determine which proxy should be used for each request. If the script returns "DIRECT", the browser will bypass the proxy and the site will be mapped into the Local Intranet Zone. When mapping a URL to a Zone, URLMon will call the FindProxyForUrl function to determine if the bypass rule applies. One interesting twist is that the proxy script may itself call dnsResolve to get a site’s IP address and use that information as a part of its determination.

Rules #2, #3, and #4 can be controlled using the checkboxes found at Tools > Internet Options > Security >  Local Intranet > Sites:

image

The top box controls rule #2, while the second checkbox controls rules #3 and #4.

Disabling Local Intranet Zone

Since Internet Explorer 7, the Local Intranet Zone may be disabled in certain environments. The Local Intranet Zone is enabled by default if the current machine is domain-joined. It is also enabled if the Network Location Awareness API indicates that at least one of the connections is managed (NLA_NETWORK_MANAGED).

In other cases, the user will see a notification upon visiting a site that would-have-been mapped to the Local Intranet Zone if that Zone had been enabled:

image

Or in the Metro-style browser:

image

If you click the “Turn on” button, you’ll see the following confirmation:

image

If you choose Yes, the settings inside Tools > Intranet Options > Local Intranet > Sites will adjust to:

image

The top box will be unchecked and the other Intranet-related options will be checked. The REG_DWORD named WarnOnIntranet under HKCU\Software\Microsoft\Windows\Current Version\Internet Settings\ will be set to 0, which means that even if you later recheck the “Automatically detect intranet network” box, you’ll never see the “Intranet settings are off by default” notification bar.

AppContainers, the Firewall and the Local Intranet Zone

Windows 8 introduced a new process isolation technology called AppContainer, which is used by the new Enhanced Protected Mode feature enabled by default in Metro-style Internet Explorer. AppContainers utilize the Windows Firewall to enforce restrictions on what network addresses may be contacted by code running within the AppContainer. If an AppContainer has the InternetClient capability, then outbound network connections may be made to the Internet. If an AppContainer has the PrivateNetworkClientServer capability, then network connections may be made to "private network" addresses. What is considered a "private network" is configurable by Group Policy / Network Administrators, but for many users this will include the RFC1918 addresses.

The AppContainer used by Enhanced Protected Mode has only the InternetClient capability and explicitly does not have the PrivateNetworkClientServer capability. This has some interesting implications.

Say you're a home user on a non-domain-joined PC, and you've got a wireless router running at 192.168.1.1, with the hostname "DDWRT". When you configured your wireless connection in Windows, you chose the option to allow connection to devices, which makes the 192.168.* address range a part of your "private network." Now, in Metro-style IE, try to open https://192.168.1.1. Observe that you see a "Page could not be displayed" error, because the target hostname was mapped to the Internet Zone (by the "dot rule"), and thus loaded in an Enhanced Protected Mode tab. That EPM tab runs in an AppContainer without permission to contact the private network, and thus the connection fails. Now, try loading https://ddwrt/ . You will see the "Page could not be displayed" error, but also the "Intranet settings are disabled by default" error message. Now, click the "Turn on Intranet Settings" button. Observe that the page reloads successfully, because https://ddwrt/ is mapped to the newly-enabled Local Intranet Zone (by the "dot rule") and the Local Intranet Zone runs at Medium IL, outside of EPM/AppContainer.

What’s Different in the Local Intranet Zone

When markup runs in the Local Intranet Zone, it may behave differently than markup running in the Internet Zone. These differences include:

  • Pages will run in Compatibility View unless they explicitly specify another document mode. This option can be disabled using the Tools > Compatibility View Settings menu.
  • The default security template for the Local Intranet Zone is Medium-low. This means that many URLActions have more liberal settings than content running in the Internet Zone. In particular, the popup blocker is set to allow popups, and features like ActiveX Filtering, the XSS Filter, and SmartScreen are disabled by default. Credentials may be automatically submitted to Intranet sites using the NTLM and Negotiate protocols.
  • P3P and cookie controls do not apply to sites in the Local Intranet Zone.
  • The Local Intranet Zone runs outside of Protected Mode at Medium Integrity Level. Cache, cookies, IndexedDBs, localStorage, etc are all partitioned and not shared between processes running at MediumIL and those running in Protected Mode or Enhanced Protected Mode. This can cause a number of problems with Single-Sign-on (SSO) and Federated Authentication architectures, because cookies set at one integrity level are not shared with tabs running at another integrity level. 

Hosting sites “at the root”

A few years ago, ICANN voted to allow organizations to create new generic TLDs. For instance, an organization could buy the TLD “insurance“ so that users could go to say, https://contoso.insurance or https://woodgrove.insurance.

The problem is that some purchasers of such TLDs will expect to be able to host pages “at the root,” so that, for instance, a user could visit https://insurance/ to sign up for a policy.

See the problem?

Because it lacks any embedded dots, this URL would be mapped to the Local Intranet zone, giving it different default behaviors and additional permissions. Additionally, the site isn’t reachable for many users—the user will end up with a “Page could not be displayed” error when they attempt to visit the site, because the user’s local DNS server will attempt to qualify the hostname and look for a non-existent record. Currently, nine country-specific TLDs attempt to host pages at the root; none of these sites can be loaded from most corporate networks.

-Eric

Comments

  • Anonymous
    June 08, 2012
    Great post, Eric. Another thing to note about the Intranet zone is that beginning in IE7, it became the most permissive of the zones (other than the Local Machine zone) when IE7 tightened the permissions on the Trusted Sites zone.  I wrote about it and issues that come up a few years ago here: blogs.technet.com/.../fdcc-and-internet-explorer-7-part-1-security-zones.aspx (Look for "Local Intranet Zone vs. Trusted Sites Zone") Also, in case anyone is still running IE7 on Windows Vista, it had Protected Mode enabled in the Intranet zone. To see the permissions differences between zones and all your security zone mappings, download IEZoneAnalyzer here: blogs.technet.com/.../iezoneanalyzer-v3-5-with-zone-map-viewer.aspx HTH

  • Anonymous
    June 12, 2012
    List of new TLD applicants: newgtlds.icann.org/.../strings-1200utc-13jun12-en

  • Anonymous
    November 20, 2013
    We have this problem in our network that our SharePoint site is available inside the network and outside the network. We put the SP Site into Intranet zone, it works just fine when I'm inside the network. If I'm outside at a client location accessing it from the Internet, I get the "Page cannot be displayed" error.  No option to get to the site. This started happening in Windows 8 but now someone who was upgraded to MSIE 11 on Windows 7 and then reverted back to MSIE 9 is having this problem.

  • Anonymous
    February 13, 2014
    Similar to Thomas, I have a web-app that works fine on all browsers but the certain submit buttons that require postback will not function on Windows8.1 with MSIE 11 (Works fine with windows 7 and MSIE 11). Unless of course you place my website in the "local intranet" zone than it works completely fine. Does anyone know what could be causing IE11 to break my website and why my site will work if it is placed in the "local intranet" zone? [EricLaw] Hit F12. What's the Document Mode? What Script errors do you see on your console when you enable script debugging and click the button? Chances are that this is magically fixed when moving to your Intranet zone because Intranet sites run in CompatView by default. See this post.

  • Anonymous
    February 13, 2014
    Document Mode is edge, Changing it does not help. I even tried adding <meta http-equiv="X-UA-Compatible" content="IE=9"> and this did not fix anything. I am using .NET 4, I tested upgrading to .NET 4.5 and it did not fix the issue either. I don't have any script errors in the console either. What happens when I click the button, it does the postback but it doesn't redirect me to the next page, I end up stuck on the same page instead. I have noticed when running network traffic,  only IE11 seems to send the post as a 200 and not a 302? In the form data posted, I receive unexpected characters eg. " �__VIEWSTATE= " instead of " __VIEWSTATE=" this unexpected character is random. I should mention the IE11 developer tools doesn't shoe this unexpected character. The data is correct when viewing it in the developer tools. It was when I checked the logs that I saw this unexpected character. Sometimes it is not "  ï¿½ " and it is " 2__EVENTTARGET " or " I__EVENTTARGET= " Thank you for your quick response Eric! It is appreciated. [EricLaw] Sorry, I should have clarified a bit-- it's not about the document mode, it's about the Browser Mode. The X-UA-Compatible setting doesn't change the User-Agent string, which is what causes unpatched ASP.NET sites to fail to send proper markup to IE11; in theory, your upgrade to .NET4.5 should have resolved that though. Regarding the "unexpected" data-- that looks like a UTF-8 byte order marker. Where (in what tool/window) are you seeing it? Can you email me a Fiddler SAZ File of the failing scenario? (Click File > Save All Sessions in Fiddler)

  • Anonymous
    February 13, 2014
    The latest patches that claimed to fix IE11 have been applied to my version of .NET 4. |When testing on Fiddler, my site will actually work ( I figure that when running Fiddler, it will trigger the local intranet zone for IE?). So I can't reproduce the issue when Fiddler is running. When the site is in "Local Intranet" zone the garbage characters don't exist. So I'm not sure if the fiddler SAZ file would prove much use. I will investigate to see if I can get the garbage characters to appear in fiddler, I haven't thoroughly checked the data with fiddler. Just some more info: Nginx is my proxy. My development server is local, so obviously I can't reproduce the issue with it. I have to test this issue on my live site. Would you know of a way to completely disable local intranet settings? [EricLaw] Working with Mac, we found that the problem is the change IE took to disable the use of RC4 ciphers on the Internet. Her NGinx proxy is dropping part of the post body when IE uses the AES cipher. I'll be writing a new blog post about this topic shortly.

  • Anonymous
    February 25, 2014
    The comment has been removed

  • Anonymous
    February 25, 2014
    Even with my site in the intranet area, I can reproduce the bug randomly. I've set the X-UA-Compatible IE=EmulateIE9... :(

  • Anonymous
    March 02, 2014
    It seems that IE10 + NTLM automatic authentification (in intranet zone) + Apache WWW server making loadbalancing (even when sending all requests to the same server) is the buggy combination. I suppose it randomly send/receive a NTLM header All these work :

  • Removing the NTLM authentication
    - using IE11
    - requesting directly the production the serveur (squizzing the frontal WWW) [EricLaw] Do you have a network capture you could send me?
  • Anonymous
    March 12, 2014
    I workaround the problem by using an URL with the session %USERNAME% variable, which stores the cookie (lost at the session close). This is not authentification, but fit our needs. How to realize a network capture ? [EricLaw] Clear your cache. Start Fiddler (enable HTTPS decryption in Tools > Fiddler Options > HTTPS if the target site is HTTPS). Start IE. Reproduce the problem. In Fiddler, choose File > Save Session Archive.