0

We have an on premise install of SharePoint 2013. Using our farm account, let's say spfarm, we built out a handful of web applications. Since it is the farm account, it inherently gets full access to all site collections created under it by default. Somehow, on one of our web applications, the spfarm account has had it's permissions revoked. Does anyone know how the farm account could mysteriously have all of it's default inherited permissions removed and it no longer has access to the site?

More Information: The farm account still has DBO access to the content database for the problematic web application. Also, in an attempt to fix the issue, we deleted the web application, but kept the content DB in tact. Then re-created the web application and attached it to the existing content DB. The problem was fixed briefly, but then coming in to work the next day, the exact same problem came back and the farm account lost all permissions again. Seems to point to a timer job or some process killing it off. We don't have any custom scheduled jobs either.

0

Reason 1 : The user accounts can be manually deleted from the specific content DB.

Reason 2:

The farm account will be deleted from the farm admin groups and then create a new web application and site collection. now add it back, here there is a possibility of loosing access when you dont do IISRESET because the permissions wouldn't have been propagated completely.

  • Thanks for the ideas! For Reason 1, we confirmed that the content DB for the web application still had the farm account listed ad DBO. For Reason 2, unless I'm misunderstanding, the farm account was never removed from the farm admin group – Nick Steenstra Jul 29 '15 at 20:32
  • ok, is it cross domain environment. mention all the granual details of the farm as well as recent admin/config related activities as this is not a regular behavior of any of the sharepoint sites. – kesava Jul 29 '15 at 21:28
0

This ended up being a very silly issue. Our server admins would go in and add in an Active Directory group with explicit deny rights to the web application. This group was populated via a server job that ran daily, and somehow this job grabbed all SharePoint accounts and placed them in the group. The odd thing is that the farm account would never show the deny rights, but in checking another service account, we saw the deny rights and were able to finally figure out the issue. Silly! But glad it was an easy fix.

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.