none
"SCRIPT5: Access is denied" error when accessing web sites using LocalStorage

    質問

  • We are having an issue with Internet Explorer 10 affecting users on a number of our Windows 8 workstations. When a user visits a web site that uses the Local Storage feature of HTML5, the page is not displayed correctly. For example, if you visit this page:

    http://jsfiddle.net/xFtQR/

    You should see text in the grey boxes in the lower-right hand corner if everything is working. For the affected users, nothing is displayed. In addition, if you open the F12 Developer Tools and reload the page, the following error message is displayed: "SCRIPT5: Access is denied.". It appears the LocalStorage feature is broken for these users.

    From the troubleshooting I've done so far, I've determined that this issue does not affect the Local Administrator account on these computers, but it does affect any domain user and any new local user I create, whether the local user is in the Administrators group or not. This leads me to believe the issue may be related to the default user profile in the image that was applied to these computers.

    Other observations:

    • Performing a complete reset of Internet Explorer settings (from Tools > Internet Options... > Advanced) does not resolve the issue
    • These sites do work correctly after turning off Protected Mode for the Internet Zone (from Tools > Internet Options... > Security) 
    • These sites also work correctly when InPrivate Browsing is turned on

    I've tried using Process Monitor to determine whether access is being blocked to a folder. On a working computer, iexplore.exe creates a file within a folder at C:\Users\username\AppData\LocalLow\Microsoft\Internet Explorer\DOMStore. I can't see anything on an affected computer that would prevent IE from creating this folder, as the security settings on the folder all appear to be correct.

    The location of this folder appears to be stored in the registry at HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\5.0\LowCache\Extensible Cache\DOMStore. I've tried copying this key from a working computer and blanking it out entirely to have IE recreate it, but neither resolved the issue. I've even gone as far as to try and compare an export of the registry from the default user profile from a working system and an affected system but I haven't been able to pinpoint any differences which I thought might be relevant.

    I've tried the "Internet Explorer Performance" and "Internet Explorer Safety" troubleshooters in the Control Panel.

    Here are some links to articles on other sites which make reference to the same (or a similar) issue:

    http://answers.microsoft.com/en-us/ie/forum/ie10-windows_7/ie10-script5-access-is-denied/e87bdb30-7f2a-4510-bfa3-a22b995f777b
    http://community.spiceworks.com/topic/357825-ie10-script5-access-is-denied
    https://github.com/meteor/meteor/issues/1291

    Unlike these other cases, deleting an affected user's profile does not resolve the issue (further bolstering my theory that the issue is due to an issue in the default profile in my case).

    Thanks in advance for any assistance anyone can provide!



    2013年10月30日 21:42

回答

  • With some excellent detective work by Microsoft Product Support (thanks Siddarth!), the solution has been found.

    It turns out that in addition to the security settings on a folder, there is an integrity setting. More information about it is here.

    The integrity setting on the AppData\LocalLow folder in each user's profile is supposed to be set to "Low" (hence the name, presumably). In our case, the integrity level was not set correctly on this folder. To rectify the problem, we will need to run the following command under each user's profile (with a login script, for example):

    icacls %userprofile%\Appdata\LocalLow /t /setintegritylevel (OI)(CI)L

    As for how this incorrect setting was propagated in the first place, it is because the LocalLow folder in the C:\Users\Default\Appdata folder in our customized OS image had the wrong setting. The C:\Users\Default folder is the template for a new user profile, so each new user on these computers was affected. I examined the C:\Users\Default\AppData folder on another machine without a customized user template and found the LocalLow folder is not present at all, so in our environment we will be deleting the C:\Users\Default\AppData\LocalLow from each machine to prevent the issue from affecting future new users.

    EDIT: If the command above does not resolve the issue, the registry key that points to the low integrity DOMStore folder may have been changed. Check the CachePath registry value at HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\5.0\LowCache\Extensible Cache\DOMStore. It should be %USERPROFILE%\AppData\LocalLow\Microsoft\Internet Explorer\DOMStore.

    • 回答としてマーク Ryan G. Steele 2013年12月24日 2:18
    • 編集済み Ryan G. Steele 2014年1月15日 19:20 Added information about checking the registry key
    2013年12月24日 2:18

すべての返信

  • Hi,

    jsfiddle uses an iframe to host the results page.

    see http://msdn.microsoft.com/en-us/hh563496.aspx

    see http://blogs.msdn.com/b/ieinternals/archive/2012/03/23/understanding-ie10-enhanced-protected-mode-network-security-addons-cookies-metro-desktop.aspx

    You should use feature testing to test for DOM Storage support. DOM storage support is user configurable on the Advanced tab of Internet Options. Post questions about html, css and scripting in MSIE browsers for website development to

    the MSDN IE Web Development forum

    http://social.msdn.microsoft.com/Forums/ie/en-US/home?forum=iewebdevelopment

    with a link to your website (jsfiddle is inadequate and does not return your server's response headers)

    Regards.


    Rob^_^

    2013年10月31日 0:08
  • Hi Rob, thanks for your reply.

    Just to clarify, I'm not developing a web site. I'm trying to get IE 10 to work properly with other people's websites that use HTML5 Local Storage. I used the jsfiddle link as a simple example of a site that does not work correctly, but I can post some additional examples that our users have reported:

    • twitter.com - Clicking the "compose new tweet" button does nothing
    • Passport Canada - The navigation menus ("Apply or renew", "Service locations", "ePassport", etc.) do not work
    • Citizenship and Immigration Canada - The vertical menu ("Start your life in Canada", "Check application status", etc.) does not work

    In all cases listed above, the "SCRIPT5: Access is denied" error appears in the F12 Developer Tools console on the affected machines.

    I will further point out that on a different Windows 8 machine with the same security settings (Internet zone set to Medium-high, Protected Mode enabled), the jsfiddle link I posted works correctly, as do the other sites listed above.

    I hope this clarifies things. Let me know if you need any further information.

    2013年10月31日 0:24
  • With some excellent detective work by Microsoft Product Support (thanks Siddarth!), the solution has been found.

    It turns out that in addition to the security settings on a folder, there is an integrity setting. More information about it is here.

    The integrity setting on the AppData\LocalLow folder in each user's profile is supposed to be set to "Low" (hence the name, presumably). In our case, the integrity level was not set correctly on this folder. To rectify the problem, we will need to run the following command under each user's profile (with a login script, for example):

    icacls %userprofile%\Appdata\LocalLow /t /setintegritylevel (OI)(CI)L

    As for how this incorrect setting was propagated in the first place, it is because the LocalLow folder in the C:\Users\Default\Appdata folder in our customized OS image had the wrong setting. The C:\Users\Default folder is the template for a new user profile, so each new user on these computers was affected. I examined the C:\Users\Default\AppData folder on another machine without a customized user template and found the LocalLow folder is not present at all, so in our environment we will be deleting the C:\Users\Default\AppData\LocalLow from each machine to prevent the issue from affecting future new users.

    EDIT: If the command above does not resolve the issue, the registry key that points to the low integrity DOMStore folder may have been changed. Check the CachePath registry value at HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\5.0\LowCache\Extensible Cache\DOMStore. It should be %USERPROFILE%\AppData\LocalLow\Microsoft\Internet Explorer\DOMStore.

    • 回答としてマーク Ryan G. Steele 2013年12月24日 2:18
    • 編集済み Ryan G. Steele 2014年1月15日 19:20 Added information about checking the registry key
    2013年12月24日 2:18
  • You did a lot of good work on this problem!

    I'm getting 'access is denied' also, when using IE11, from some javascript I'm writing that uses localStorage.  Your jsfiddle test doesn't output anything unless I switch to inPrivate mode, then it works (so does my page).  (Also, this MS forum page doesn't work in IE11 for me unless I switch to inPrivate; could be my cookie settings.)

    Internet options -> Advanced -> Enable DOM Storage is checked.

    Here's what icacls says:

    C:\Users\Baffin\AppData>icacls LocalLow
    LocalLow NT AUTHORITY\SYSTEM:(I)(OI)(CI)(F)
             BUILTIN\Administrators:(I)(OI)(CI)(F)
             WIN7\Baffin:(I)(OI)(CI)(F)
             Mandatory Label\Low Mandatory Level:(OI)(CI)(NW)

    Successfully processed 1 files; Failed processing 0 files

    I wonder what should it say?  (I'm hesitant to make changes till knowing more.  If this is a widespread problem, I wonder if MS is planning a fix.)

    (This is on a Win7 system)

    2014年1月6日 3:40
  • Hi Baffin,

    The settings on the C:\Users\Baffin\AppData folder look good, but they may be incorrect on the subfolder where IE is trying to store the files. The icacls command I posted above will apply the correct settings to the LocalLow folder and all its subfolders. You can run the icacls command on the specific folders that IE needs the setting changed on if you're hesitant to apply the setting on all folders and subfolders.

    What's the output of the following command?

    icacls "C:\Users\Baffin\AppData\LocalLow\Microsoft\Internet Explorer"

    If "Mandatory Label\Low Mandatory Level" does not appear in the list, then this is the cause of the problem.

    To apply the setting change to just this folder:

    icacls "C:\Users\Baffin\Appdata\LocalLow\Microsoft\Internet Explorer" /setintegritylevel (OI)(CI)L

    One thing I should mention: I've seen evidence that the root cause of this problem may be the use of a "system cleaner" utility.


    2014年1月8日 0:43
  • When I run the command exityou requested, I get:

    C:\Users\Baffin\AppData\LocalLow\Microsoft\Internet Explorer (line break inserted here)
    NT AUTHORITY\SYSTEM:(I)(OI)(CI)(F)
      BUILTIN\Administrators:(I)(OI)(CI)(F)
      BANKS\Baffin:(I)(OI)(CI)(F)
      Mandatory Label\Low Mandatory Level:(I)(OI)(CI)(NW)

    Successfully processed 1 files; Failed processing 0 files

    (I haven't used a 'system cleaner' utility, unless something like MS's Disk Cleanup qualifies)

    What do you figure?

    2014年1月13日 20:46
  • That looks okay too — you can see the "Low Mandatory Level" setting has been applied. It could, however, be the setting on the DOMstore folder within that folder (sorry, should have had you check that folder to begin with). You can check with:

    icacls "C:\Users\Baffin\AppData\LocalLow\Microsoft\Internet Explorer\DOMstore"

    If that returns with the "Mandatory Label\Low Mandatory Level" setting in the list, then you are likely experiencing a different issue that I was.

    You might want to try opening the following registry key in RegEdit and verify the settings in it:

    HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\5.0\LowCache\Extensible Cache\DOMStore

    If the value of CachePath is something other than "%USERPROFILE%\AppData\LocalLow\Microsoft\Internet Explorer\DOMStore", then the location of the low integrity DOMStore folder has been changed from its default for some reason. You would either need to change it back or verify the integrity setting of this folder at its alternate location.



    2014年1月13日 21:16
  • Here's the result of the icacls command:

    C:\Users\Baffin\AppData\LocalLow\Microsoft\Internet Explorer\DOMstore (line break inserted)
    NT AUTHORITY\SYSTEM:(I)(OI)(CI)(F)
      BUILTIN\Administrators:(I)(OI)(CI)(F)
      BANKS\Baffin:(I)(OI)(CI)(F)
      Mandatory Label\Low Mandatory Level:(I)(OI)(CI)(NW)

    Regedit says:

    HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\5.0\LowCache\Extensible Cache\DOMStore

    is set to:

    %USERPROFILE%\AppData\Local\Microsoft\Internet Explorer\DOMStore

    This differs from what you expected in that it contains 'Local' instead of 'LocalLow'.  When I go to that folder (which exists) and run icacls, I get:

    C:\Users\Baffin\AppData\Local\Microsoft\Internet Explorer\DOMstore
    NT AUTHORITY\SYSTEM:(I)(OI)(CI)(F)
     BUILTIN\Administrators:(I)(OI)(CI)(F)
     BANKS\Baffin:(I)(OI)(CI)(F)

    (Note: no 'mandatory' line)

    The LocalLow\...\DOMStore folder is empty; the Local\...\DOMStore has folders.

    As mentioned initially, my scripts write to localStorage when IE11 is run in inPrivate mode, which for me means less restrictions (cuz in 'normal' mode I've got it set to block third-party cookies).

    I presume that in inPrivate mode any localStorage writes would be removed at session end. If so, the folders in Local must be from normal mode operation.  In which case, they were able to write despite the 'Mandatory' missing, and they could write but my script can't now.  Hmm, the most recent modification date on the dozen or so files is 2013-Jun; maybe something changed then, since sites corresponding the xml files there have been accessed since then.

    Thoughts?

    2014年1月15日 1:45
  • Yes, I think we've identified the problem. I would recommend changing the registry key so it points to the DOMStore folder in LocalLow rather than Local.

    I had also found that, for our clients, accessing an affected website with InPrivate enabled worked correctly. I suspect InPrivate uses a different mechanism to store the local files.

    2014年1月15日 18:40
  • I changed the registry key (to LocalLow from Local) and now when running my page from a server, it works!  Not only that, but other web sites (such as Google) are now able to write to it (the date on all the DOMStore folders is current).

    When I load my page locally (from file://), localStorage isn't defined, but I gather that's normal for IE.

    So, I wonder:

    1) what the registry on a 'correct' win7 system should be (pointing to LocalLow I presume?)

    2) how my system's registry value got perturbed

    3) how many other systems out there will be like that (have non-functioning local store)

    It's interesting that changing the registry key, as happened on my system, is apparently a way to disable all web sites' ability to use local store.

    Thank you very much for sharing your knowledge and your help on this, Ryan!

    2014年1月16日 3:14
  • Great advice! It helped me to change the registry value for DOMstore

    2015年1月22日 13:05
  • Hello,

    First I want to thank you for your replay about the access denied, than I tried with an old application that needs IE8 -_- , but after January, IE8 will not be supported by Microsoft.

    I use IE11 with Document Mode IE9, the functionality is Drag&Drop developed on Java

    My question is:

    I used this cmd but with M not L

    icacls %userprofile%\Appdata\LocalLow /t /setintegritylevel (OI)(CI)M

    I have always access denied but the functionality work; the only issue is each time I need to refresh the page after using this functionality

    So is there any solution to force the refresh of the IE11 page?

    Thanks Regards,

    Oussama   

    2015年9月10日 15:36
  • This worked for me.

    I could not access Pluralsight.com using the new user experience GUI

    Parts of the page did not load and got Access Denied errors in F12 developer tools

    I changed the reg setting from Local to LocalLow and created the LocalLow folder

    I then ran the script and restarted ie

    That fixed it but maybe I only needed to run the script- not sure.

    2015年10月29日 16:54