We are seeing some odd behavior with some accounts in a SharePoint 2010 Farm that is installed in an Active Directory Domain with a 1-way trust established to another AD domain.
Here is the configuration:
SharePoint 2010 Farm in Domain P.
Main set of user accounts and groups in Domain M, SharePoint service accounts are in the P Domain, in the future some user accounts will be in the P domain.
There is a one-way trust established between M and P (P trusts M, M does not trust P).
The solution we are buiding:
We have a solution, that involves SSRS reporting and SharePoint sites that is architected as follows:
There is site collection called Reports with a document library of data sources, data sets, and reports (.rdl files) in it.
Let’s call the site : http://wfe/sites/reports/
There are other Site Collections (SC01, SC02, SC03, etc) that view reports (from the central Reports site collection) and pass in site-specific parameters.
These site are http://wfe/sites/SC01, etc.
We grant M\user1, M\user2, etc access to SC01.
We grant NT Authority\Authenticated Users READ access to the central reports site. (And as part of troubleshooting, groups like M\All-Users which contains all accounts in domain M)
The goal is not to grant users specific access to the report site, but to have them access via membership in some Domain M AD group.
The problem:
Things work great. M\user1 can access SC01, and can view reports. Then, one day, M\user1 logs in and can still access the site SC01 fine, but the Report Viewer webpart show an error. The ULS logs indicate a permissions problem.
This problem is fixed in one of two ways:
1) Adding M\User1 specifically to have READ permission on the Reports site collection
2) Without ever granting M\User1 any permissions to the site, going to http://wfe/sites/reports/_layouts/people.aspx?MembershipGroupId=0, finding the entry for M\User1 and DELETING it.
(The membershipGroupID=0 is an automatically generated list of people that have ever accessed the site I think, not people that we have manually added)
Re: 1) we are going to have too many users that will have access and need to be able to use AD Groups from Domain M. (e.g. M\ReportReaders, we are using broader groups now just for development/testing)
Re: 2) This fix works, but appears to be temporary. Eventually the user will have the same problem and deleting their account from the people.aspx?MembershipGroupId=0 list will fix it.
It would seem to be that something is getting messed up with the account record SharePoint is keeping.
When it gets messed up, it fails a permissions check and doesn't seem to be looking up the account from the domain groups the account is in.
When the account is deleted (from the All Users list at people.aspx?MembershipGroupId=0) it seems to cause SharePoint to re-check the domain membership and since the account is in a group, it works.
Other observations:
Doesn't happen to all the accounts, just some of them.
from the http://wfe/sites/reports/_layouts/user.aspx page, when we select Check Permission, and enter the problematic account, it says:
Permission levels given to M\User1
None
when the account is fixed that same procedure says:
Permission levels given to M\User1
Read
Given through the "NT AUTHORITY\Authenticated Users (NT AUTHORITY\authenticated users)" group.
The Questions
What areas/techniques do you suggest for troubleshooting this?
I have been looking through ULS logs and event logs but I am just seeing the "insufficient" permissions message until we fix the problem.
Does it sound like a User Profile Service sync issue? (see comment, it is not running)
Why would it only affect some accounts?
What is causing the existing records to get "corrupted" or to stop working as expected?
