Issue Summary:
When a user in any site collection attempts to add a CQWP to a page, and uses that webpart to render items from list type “Announcements” or “Issues”, the resulting list items are displayed, but produce a “List Does Not Exist” error when clicked. To understand why this happens, we need to better understand how the webpart is processing this request. If you look carefully, you will notice that rather than the webpart providing a direct link to each item, as would be expected, instead it provides a link to a _layouts page which hangs off the <Root> Site Collection for that Web Application, called “CopyUtil.aspx”. Further analysis indicates that this page receives the querystring parameters provided by the CQWP and does some processing in order to locate the proper site, web, list, and item, after which it forwards the user to that item’s display form. As part of its processing, it does some security checks to ensure that the requesting user has what it known as “Limited Access”, which provides view access to specific list libraries such as the mater page and layouts gallery. The reason it does this is so that it can be sure the user will have the permissions needed to pull any needed master pages or layouts, etc. needed to view the target item. Interestingly enough, it doesn’t perform these checks against those libraries in the target site, but rather the libraries which exist in the <Root> Site Collection. If the requesting user doesn’t have access to those libraries, the call fails, returning the “List Does Not Exist” error as described above. Not so helpful, but this is how it works…
Forensic Analysis:
As the problem was isolatable to the production environment, and could not be replicated in any development or integration environments, we did some comparisons the production environments to see if we could reproduce it. The results of those tests, using testing site collections setup for this purpose indicated that the effect could not be reproduced. We consulted the database folks and had them recheck and compare the database permissions between those environments to ensure the proper application pool accounts had the needed content db access, and that the permissions were equivalent between the two environments. Everything checked out, and no differences could be identified. We then set our focus on the permissions of the root site collection itself, and discovered that if a specific test user was granted viewer rights to the root site collection, the effect was eliminated. After performing a detailed group by group analysis of the root site collection security for all environments, we were able to locate the primary causal discrepancy. The issue was related to the membership of an OOTB delivered site group called “Style Resource Users”. This is a limited access group that ships with the site collection. When a new site is created, this group comes with “All NT Authenticated Users”, however this can be optionally removed to further secure (or in our case, break) the environment. Based on our assessment, it appears whoever setup the root site collections elected to futrhur secure these sites in this fashion by removing the group.
Resolution:
As a single unit test, we were able to temporarily add NT Auth Users to the group and verify that:
A) The Problem was resolved
B) The user still received an “Access Denied” when visiting the root site collection directly
Recommendation:
It is recommended that the membership of the “Style Resource Users” group be audited in all root site collections in all web application in all production environments, to ensure that NT Auth Users is present, and all other user accounts or group have been removed. After this change, which is in alignment with the design and the automation, the above error should no longer be present.
Please let me know if there are any questions. Thanks!