SharePoint 2010 / 2013: Access Denied to claims web apps

All users, even admins with full control policy for web application get Access Denied when browsing to claims auth site collections.
In SharePoint 2013, they get the standard SharePoint access denied page that says:
“Sorry, you don’t have access to this page”
In SharePoint 2010, users get the standard SharePoint access denied page that says:
“Error: Access Denied”
If you take a Process Monitor trace, you will that “NT Authority\IUSR” is getting access denied to the root folder for the web application. For example: C:\inetpub\wwwroot\wss\VirtualDirectories\80.
You look at the Permissions for C:\inetpub\wwwroot\wss\VirtualDirectories\80, and you see that “Everyone” has been given Read permissions there along with all files and sub-folders. This group should contain the IUSR account, yet you still see the access denied in Procmon.
Note: If the "Everyone" group does not have Read permission at the root of each web app folder structure, that would cause this problem too.
In this situation, there are some things that users can successfully browse to. They include:
Central Admin
Pages in _layouts
Web apps that use Windows Classic authentication.

Cause

In the Local Security Policy | Local Policies | User Rights Assignment, “Bypass traverse checking” -- did not have the “Everyone” or “Users” group listed here, or anything that would contain the IUSR account. Because IUSR did not have this permission, it could not traverse C:\inetpub\, or C:\inetpub\wwwroot\, etc to get to C:\inetpub\wwwroot\wss\VirtualDirectories\80, and therefore was showing access denied for that directory even though it had permission at that level.

Resolution

1. Add a group that contains IUSR to “Bypass traverse checking” in the Local Security Policy. This could be “Everyone”, or “NT Authority\Authenticated Users”, or “Users”.
2. Gpudate /force
3. IISReset
Note: These policies may be pushed down to the machines via GPO, so you may have to change it at that level.

More Information

If you turn ULS logging up to verbose, you should see errors like the following just before it does the GET for _layouts/AccessDenied.aspx.
Notes: These entries may not have a correlation ID associated with them.
The errors are the same in both 2010 and 2013.
w3wp.exe (0x129C) 0x1DC0 SharePoint Foundation Claims Authentication ftc8 Verbose Access Denied: Authentication is required.
w3wp.exe (0x129C) 0x1DC0 SharePoint Foundation General 8gs1 Verbose Access Denied for /. StackTrace: at Microsoft.SharePoint.Utilities.SPUtility.HandleAccessDenied(HttpContext context) at Microsoft.SharePoint.IdentityModel.SPFederationAuthenticationModule.OnEndRequest(Object sender, EventArgs args) at System.Web.HttpApplication.SyncEventExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute() at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously) at System.Web.HttpApplication.PipelineStepManager.ResumeSteps(Exception error) at System.Web.HttpApplication.BeginProcessRequestNotification(HttpContext context, AsyncCallback cb) at System.Web.HttpRuntime.ProcessRequestNotificationPrivate(IIS7WorkerRequest wr, HttpContext context) at System.Web.Hosting.PipelineRuntime.ProcessRequestNotificationHelper(IntPtr managedHttpContext, IntPtr nativeRequestContext, IntPtr moduleData, Int32 flags) at System.Web.Hosting.PipelineRuntime.ProcessRequestNotification(IntPtr managedHttpContext, IntPtr nativeRequestContext, IntPtr moduleData, Int32 flags) at System.Web.Hosting.PipelineRuntime.ProcessRequestNotificationHelper(IntPtr managedHttpContext, IntPtr nativeRequestContext, IntPtr moduleData, Int32 flags) at System.Web.Hosting.PipelineRuntime.ProcessRequestNotification(IntPtr managedHttpContext, IntPtr nativeRequestContext, IntPtr moduleData, Int32 flags)