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.
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.
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)
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.
I'm facing the strange same problem with form submission in POST method, both standard input type="submit" and the ajax POST.
It's random and it drives me crazy.
Windows Server 2012, IE 10.
Not reproduced (yet) on Windows Serveur 2008 R2 / IE11
For an ActiveX to work, I had to set : http://*.mydomain.fr in Local Intranet, and http://myserver1.mydomain.fr, http://myserver2.domain.fr in the Trusted websites.
I'll try to tweak this options from what I read here all should be in Local Intranet to work better.
I was ready to configure the opposite.
Can you point me to your new blog article about encryption? But I don't think we changed default parameters for any encryption...
Even with my site in the intranet area, I can reproduce the bug randomly.
I've set the X-UA-Compatible IE=EmulateIE9... :(
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?
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 ?