Users don't remain logged in with mixed anonymous / integrated windows authentication (NTLM)

Question

I am not quite sure how to even begin to troubleshoot this. After some undetermined number of requests or actions an authenticated user will suddenly become anonymous again. Here is a sample series of events with the user status on the left of the arrow and the request they are making on the right

Anonymous -> Home.aspx
... user then clicks the LOGIN button ...
Anonymous -> /_layouts/15/Authenticate.aspx
Authenticated -> Home.aspx (Note: able to see restricted content)
... several other requests ...
... suddenly falls back to anonymous for no apparent reason ...
Anonymous -> AnyPage.aspx

I can't seem to trigger it on demand or through a repeatable sequence. There doesn't seem to be a difference between Publishing pages (customized masterpage) and regular system pages (oslo). Even going to various settings pages will either give the abbreviated settings - lists vanish from All Site Content where permissions hide them from anonymous - or give an error that access is denied (site settings).

Examing Central Admin -> Manage Web Applications -> Authentication Providers shows that I have just one "Claims Based Authentication" provider in the zone "Default". That zone is configured to "Enable anonymous access" and "Enable Windows Authentication / Integrated Windows authentication (NTLM)". FBA and Trusted Identity Providers are not enabled.

Has anyone else encoutered this? Any help or suggestions would be greatly appreciated.

Answer 1

Before everything, you will face this issue in a web app where a site collection is using SharePoint Server Publishing Infrastructure, metadata navigation, the Content Query Web Part, or navigation.

We had the same access denied issue almost 4 years ago and then with the help of MSFT support we got the solution.

By default, the Portal Super User account is the site’s System Account, and the Portal Super Reader account is NT Authority\Local Service. There are two main issues with using the out-of-box accounts.

1. The first issue is that some items get checked out to System Account, so when a query that includes these items is made, the checked out version of the item is returned instead of the latest published version. This is a problem because it is not what a user would expect to have returned, so the cache has to make a second query to fetch the correct version of the file. This negatively affects server performance for every request that includes these items. The same problem would occur for any user who has items checked out, if that user’s account was set to be the Portal Super User account. This is why the accounts configured to be the Portal Super User and the Portal Super Reader should not be user accounts that are used to log into the site. This ensures that the user does not inadvertently check items out and cause problems with performance.

2. The default Portal Super Reader account is NT Authority\Local Service, which is not correctly resolved in a claims authentication application. As a result, if the Portal Super Reader account is not explicitly configured for a claims authentication application, browsing to site collections under this application will result in an “Access Denied” error, even for the site administrator. This error will occur on any site that uses any feature that explicitly uses the object cache, such as the SharePoint Server Publishing Infrastructure, metadata navigation, the Content Query Web Part, or navigation.

Setting the super user account on SharePoint 2010 and getting Access Denied errors afterwards