I recently worked to help diagnose why a new website we deployed was getting 401.3 errors on its site images. It used forms authentication, and we could get some of the pages to load, but none of the images would load. I had confirmed that the application pool identity was a member of IIS_IUSRS, but the problem persisted.
Process Monitor was invaluable in diagnosing this issue. After filtering its process name to w3wp, It revealed that we were getting 'access denied' messages trying to fetch the images running under the context of NT AUTHORITY\IUSR:
After researching this a bit ("401.3 Unauthorized Due to ACL on Resource," "Thread: IUSR Built-in Account Associated with Users Group?" ) I took a look at the ACL for the images folder. In building the server, someone had removed the built-in Users group from having any permissions on C:\inetpub or its descendants. NT AUTHORITY\IUSR relies on its intrinsic membership in the built-in Users group to get rights to any anonymous access folders, so NT security was shutting us down. I replaced the rights at C:\inetpub with the defaults I found on another unmodified web server and the site began to work:
Process Monitor was invaluable in diagnosing this issue. After filtering its process name to w3wp, It revealed that we were getting 'access denied' messages trying to fetch the images running under the context of NT AUTHORITY\IUSR:
After researching this a bit ("401.3 Unauthorized Due to ACL on Resource," "Thread: IUSR Built-in Account Associated with Users Group?" ) I took a look at the ACL for the images folder. In building the server, someone had removed the built-in Users group from having any permissions on C:\inetpub or its descendants. NT AUTHORITY\IUSR relies on its intrinsic membership in the built-in Users group to get rights to any anonymous access folders, so NT security was shutting us down. I replaced the rights at C:\inetpub with the defaults I found on another unmodified web server and the site began to work:
No comments:
Post a Comment