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


when the account is fixed that same procedure says:

Permission levels given to M\User1

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?

  • I just verifed the farm is running the User Profile Service, but NOT the User Profile Synchronization service.
    – lwbecker2
    Nov 27, 2012 at 22:13

1 Answer 1


SharePoint will always check first against the usertalble in the site collection. Even if UPS is not running some "sync" actions can still take place.

A simple check is to Backup the User Profiles in question and delete them from the UPA database and see if this still occurs.

You can also break out fiddler and watch the traffic with the users in question and verify where the issues is. Unfortunately with SSRS involved you cant see it all users side, you will also need a network trace on the servers to see the Server to Server communication. You can use native tracing in 2008 and above, or the fall backs of NetMon or Wireshark.

If you have multiple servers configured with NTLM authentication you will have "double hop" issues with SSRS. This can cause what appears as "random" events as sometimes the user request will stay on box, but fail when one server tries to contact another and impersonate the user. You either need to be sure the servers are configured to point at them selves via HOSTS file so as not to jump off box, or enable Kerberos, or enable Claims authentication (assuming SQL 2008 R2 SP1 or higher).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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