You are on page 1of 3

The Intranet Zone - EricLaw's IEInternals - Site Home - MSDN Blogs

10/4/12 9:44 PM

The Intranet Zone


EricLaw [MSFT] 5 Jun 2012 10:48 AM

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 URLs origin against the URL patterns in the users Zone mapping table, displayed inside Tools > Internet Options > Security > [Zone] > Sites. The Local Machine Zone is a bit more complicated, but Ive written about that before. Sites that arent 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 thats a fine guess, its actually incorrect, and the MapUrlToZoneEx2 function doesnt 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 isnt 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 URIs hostname doesnt contain any periods (e.g. http://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; its at the bottom of the screen in the box labeled Exceptions. 4. (WPAD) Proxy Script. If the users 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 sites 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:

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:

Or in the Metro-style browser:

http://blogs.msdn.com/b/ieinternals/archive/2012/06/05/the-local-intranet-security-zone.aspx

Page 1 of 3

The Intranet Zone - EricLaw's IEInternals - Site Home - MSDN Blogs

10/4/12 9:44 PM

If you click the Turn on button, youll 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, youll 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 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.

Whats 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
http://blogs.msdn.com/b/ieinternals/archive/2012/06/05/the-local-intranet-security-zone.aspx Page 2 of 3

The Intranet Zone - EricLaw's IEInternals - Site Home - MSDN Blogs

10/4/12 9:44 PM

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, 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 isnt reachable for many usersthe user will end up with a Page could not be displayed error when they attempt to visit the site, because the users 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

Aaron Margosis 8 Jun 2012 11:19 PM

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

EricLaw [MSFT] 13 Jun 2012 6:03 AM

List of new TLD applicants: newgtlds.icann.org/.../strings-1200utc-13jun12-en

http://blogs.msdn.com/b/ieinternals/archive/2012/06/05/the-local-intranet-security-zone.aspx

Page 3 of 3