Please read my blog's comment policy here.
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.
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:
Rules #2, #3, and #4 can be controlled using the checkboxes found at Tools > Internet Options > Security > Local Intranet > Sites:
The top box controls rule #2, while the second checkbox controls rules #3 and #4.
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:
Or in the Metro-style browser:
If you click the “Turn on” button, you’ll see the following confirmation:
If you choose Yes, the settings inside Tools > Intranet Options > Local Intranet > Sites will adjust to:
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.
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 http://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 http://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 http://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.
When markup runs in the Local Intranet Zone, it may behave differently than markup running in the Internet Zone. These differences include:
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, http://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 http://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.
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:
(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:
List of new TLD applicants: newgtlds.icann.org/.../strings-1200utc-13jun12-en
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.