Steps to reproduce
I would expect that:
- Observed permissions behaviour would be the same whether accessing IIS locally or remotely.
- The token impersonated by the server-side IIS code would be a medium-integrity token regardless of the integrity level of the client-side IE process.
- The optimisation of passing the token directly from IE to IIS when running on the same PC would only be performed when it has no impact on the behaviour, e.g. only when IE is running as medium-integrity.
Dev Channel specific:
Comments and activity
- Microsoft Edge Team
Changed Assigned To to “Tony S.”
Changed Assigned To from “Tony S.” to “Swathi G.”
Changed Assigned To from “Swathi G.” to “Forbes H.”
Changed Status to “Confirmed”
This issue was migrated from my https://connect.microsoft.com/IE/feedback/details/1025518/ issue, which contains more details that seem to have not been migrated:
When using IE Integrated Window Authentication with a local IIS in Server 2008 R2 there seems to be an optimisation where the token is passed directly to IIS instead of performing the same authentication that is used for a remote server. When using IE Protected Mode with IE running as a low integrity process, then the low integrity token appears to be passed to IIS which causes IIS not to have permission to read the files which are necessary to process the request (when impersonating the client), and so the request fails with a permission denied error.
This is an issue for remote support of our software, since we sometimes only have remote access to the server running IIS, not to a separate client PC.
Workarounds include disabling protected mode, or running IE elevated.
Comment Posted by EricLaw [ex-MSFT] on 10/11/2014 at 08:32
Interesting! I believe there’s some registry key somewhere that can be used to resolve this (whereby the stripped token isn’t sent for certain loopback hostnames).
Stepping back a bit though-- what URL are you using to access the local machine? If you’re using something like http://localhost, it should be properly mapped to a MediumIL process.
Comment Posted by nc101 [me] on 10/11/2014 at 10:55
Another part of the puzzle is that IE Enhanced Security Configuration is enabled by default on servers which causes Protected Mode to be enabled for the “Local Intranet” zones, and both “http://localhost/” and “http://[ComputeName]/” appear to be mapped to Local Intranet zone and so use the LowIL process. A further workaround is to add the “http://[ComputerName]/” URL to the “Trusted Sites” zone which has Protected Mode disabled by default, even with Enhanced Security Configuration.
- Microsoft Edge Team
Changed Assigned To from “Forbes H.” to “Ke X.”
Changed Status from “Confirmed” to “Won’t fix”