HTTP 403 Forbidden error when try browse to a SharePoint web app

Received the following error when browse to a SharePoint web app

The website declined to show this webpage
HTTP 403
Most likely causes:
This website requires you to log in.

http-403

if we create a copy of the web.config file, rename the web.config file, refresh the home page, we receive an “HTTP 404 – Page Not Found” error.

Rename the web.config file back and refresh the page. The site is browse able for a while before failing after some time, We see the following error in Failed Request Tracing

filed-request-tracing

A procmon trace captured while accessing the web app from the server showed the following:

w3wp.exe 4180 CreateFile

C:\inetpub\wwwroot\wss\VirtualDirectories\Web80.Contoso.com80\bin ACCESS DENIED Desired Access: Read Data/List Directory, Synchronize
Disposition: Open
Options: Directory, Synchronous IO Non-Alert
Attributes: n/a
ShareMode: Read, Write, Delete
AllocationSize: n/a
Impersonating: NT AUTHORITY\IUSR

tcs-view

This issue usually occurs when a request from an authenticated user without local admin rights results in a failed read of the /BIN directory by the impersonating w3wp.exe (IIS worker process for ASP.NET) process.

This behavior is typically associated with lack of permissions to the temporary folder /BIN where ASP.Net assemblies are Just In Time (JIT) compiled.

Resolution

The solution is to ensure that the Authenticated Users or \Users group (which usually contains DOMAIN\Users group) has Read & Execute, List Folder Contents and Read permissions on the /BIN folder below

C:\inetpub\wwwroot\wss\VirtualDirectories{Sitename80}.

Follow the steps below to grant the required permissions:

a. Open Windows Explorer and navigate to the /bin directory of your web application
b. Right-click on the folder and click on Properties
c. Go to Security tab and click on Edit
d. Click on Add and add the local server group Authenticated Users or \Users (this usually contains DOMAIN\Users group).
e. Select the Read & Execute, List Folder Contents and Read permissions (if you are planning to add Everyone to the /bin folder, grant Read permissions only)
f. Click OK to apply the new settings
g. Refresh the page and we should be able to browse to the site.

More Information

If an administrator accesses the site/feature that caused the error, the subsequent requests from non-administrators would succeed. This behavior is typically associated with lack of permissions to the temporary folder where ASP.Net assemblies are Just In Time compiled.

The freb trace shows a 403.0 for ManagedPipelineHandler

It seems to go through quite a few ASPNet events – but happens during the ASPNetPageRender – it goes to the ASPNetPageRender Enter, then ASPNetHTTPHandler Leave.Only then does it get a 403.0 which is not an official RFC error. The first sub-status for 403 is 403.0.

Application pool in Classic or Integrated mode

Application Pool in Classic Mode – In this case, we can configure a Wildcard mapping for ASPNET_ISAPI.dll at the website level. That would propagate to child virtual directories. That should not need any further modifications at the virtual directory level.

Application Pool in Integrated Mode – In this case, all relevant virtual directories would need individual modifications. They need to be set for specific handler.

Advertisements

Access Denied Error after migrating to SharePoint 2013

Scenario:

We were working for a client, they had many groups and we had to build a collaboration portal for all the groups. Key thing was few sites of some groups were already present in SharePoint 2010 in different standalone servers. Migration was a key thing here as the existing sites has huge data, and huge user base.

The Requirement was to build a portal /web application which will have migrated sites and new set of sites as per agreed site structure. According to the agreed architecture and design we created a new web application and started building the site hierarchy.

As part of this we followed the regular approach database detach –attach method and migrated the existing SharePoint 2010 site .Migration was successful and we were able to access the site  with the system account. Later we tried with couple of site admin accounts, to our surprise we were getting “ACCESS DENIED” with any other user id.

Background:

By default when we create a web application in SharePoint 2013, it gets created with Claims authentication. When we migrate the content DB to 2013, it recognizes the user account only in this format i:0#.w|domainusername . Though it’s an AD account it no more recognizes the DomainUserName format.

SharePoint assumes all users to be claim users and renders them so. Therefore, a normal windows user – “DomainUserName” appears as “i:0#.w|DomainUserName”. Moreover, it uses the username in this same format to check for its permissions but does not find a matching entry for the user as the database has windows users – “DomainUserName”. So, the site will give you an access denied.

Note that the System Account will work since its “DomainUserName” is never used and System Account is a keyword used by SharePoint for the application pool identity. Therefore, it remains unaffected.

Solution:

In brief the share point 2010 site which needs to be migrated should be converted to claims format and then migrate it to 2013. But a word of caution , do not directly change the SP 2010 site to claims format in a production environment as it will not allow existing windows accounts to login and existing SharePoint 2010 site will be no more operational.

Below power shell script converts classic mode site to claims mode:

Power shell script

This script converts user accounts to claims format:

Script for converting user accounts to claims format

On executing the first script (to enable claims authentication) the SharePoint Content Database is made ready for claims based authentication but the already existing site users were windows users, are not “migrated” to be understood by claims authentication.

We use the second script to “migrate” the users. MigrateUser($true) will convert all user accounts to claims format. After running this script user accounts are converted in the database to claims format, therefore, user names are read correctly by SharePoint therefore, permissions for users are associated correctly by SharePoint hence the site permissions work correctly.

Note:

By any chance if you execute these scripts directly in productions, by executing $webapp.MigrateUsers($false) will not convert user accounts to windows mode, rather it will throw an exception. Make sure you have a temporary environment built where you execute the above scripts. Also note that these scripts are running on Web Applications so they will affect all site collections in that web application