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.
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.
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.
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.
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.
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)
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)
No comments:
Post a Comment