2

We are having a strange issue in Our Production Farm .We had configured a Host named Site Collection in our default web application on Port 80 and from time to time we are getting 403 Forbidden error when accessing this site (For all the users) and the site will be automatically working after some time .This issue is happening only in this Host named Site Collection (We have only one HSNC in our farm ) .The other web applications and Site Collections which are not HSNC are acting fine

Can some one please suggest whats wrong .This is the Authentication i have presently enter image description here

  • is it the root site collection of the web app? – Waqas Sarwar MVP Mar 30 '15 at 15:21
  • No there is a root Site Collection in the web app already pointing to the server name like (itedaxx0) its the new HSNC we created portal that's giving this error – Anil Mar 30 '15 at 15:29
  • how many WFEs in farm? what type of authentication you are using? what type of site tempalte being used? – Waqas Sarwar MVP Mar 30 '15 at 15:31
  • Hi Waqas we have 4 WFEs and i even hard coded my hosts to check each individual server and the template we are using is BLANKINTERNET#0 .I kept the authentication screenshot in the question – Anil Mar 30 '15 at 15:38
  • that's the publishing site, did you configure the Object cache for that web app(super user and super reader)? – Waqas Sarwar MVP Mar 30 '15 at 15:40
1

For me this was caused by faulty account for the App Pool for just one of the WFE. This is a description of the investigation and eventual cause;

After some routine maintenance on our SP2010 SP2 farm (which involved a reboot of servers) we noticed an intermittent 403 error on the main intranet page. This was quickly identified as an issue on one of the web front end servers (which was always failing, but being covered by the load balancer). It also only affected the root site collection from that server, and other site collections were fine.

Some blog articles mentioned 403's being caused by inadequate permissions on the bin directory of the site, but we tried this without success.

We even rolled back the VM image of the server to before the maintenance, but this also made no difference.

Looking in the ULS logs for the ailing WFE, there were a series of strange errors regarding PermissionMask (verbose logging had been enabled);

"Verbose PermissionMask check failed. asking for 0x00000015, have 0x00000000"

This had me thinking that perhaps the authentication or authorization process were blocked somewhere.

Next up, logging in with a normal user account turned up something interesting; A normal user could see much of the homepage, except Navigation and CQWP were missing. Site Collection Admins saw only the 403. This made us think of the Object Cache, as faulty configuration would strim out elements such as Navigation, and CQWP.

On this basis we turned up this article; http://blogs.technet.com/b/pfelatam/archive/2011/12/01/performance-sharepoint-2010-cache.aspx

Alas it wasn't quite right. No CBA in this site, but certainly something wrong with the credentials or authorization mechanism.

Going into the Cache settings we hit a clue. We got access denied for the Output Cache config page on the faulty server, even for the Farm Admin account. On the working WFE's the setting page could be accessed. Disabling Output cache made no difference to the error.

We were getting a bit stumped at this point. However as output cache was implicated we began poking around in IIS for potential clues. Then we found the issue; some genius had configured the sites App Pool to run under a different account on this WFE compared to the others. Changing it to match the other WFE solved all the issues. It had been working, and it seems the re-boot had made it lose its authentication token or whatever. Anyway, legacy misconfiguration was to blame. :(

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.