web
You’re offline. This is a read only version of the page.
close
Skip to main content

Notifications

Announcements

No record found.

News and Announcements icon
Community site session details

Community site session details

Session Id :
Dynamics 365 Community / Forums / Microsoft Dynamics CRM (Archived) / CRM 365 (On-Prem) says...
Microsoft Dynamics CRM (Archived)

CRM 365 (On-Prem) says a SystemUser account has no permissions to Report Entity even though it does - Any way to repair a User's permissions?

(0) ShareShare
ReportReport
Posted on by Sam Alex 6

We have a User that is unable to run reports, and after checking the Report Server logs, Trace, and checking permissions in XMLToolBox CRM is saying the user lacks the Read Privilege on the Report entity.  Going through the user's Roles it does have Read privileges, even when I create a SQL statement to view the links between the Privileges and the User through Roles it's there... but CRM isn't seeing it.  I then removed all permissions to the user and re-added with the same issue, though when I check a user who's setup identically to the issue user (even verified in SQL) CRM still says the one user has no Read permissions to the Report Entity.  So I assigned a different AD account to the issue user and create a new user with the exact same permissions and it works...  it can view Reports. 

Creating a new account isn't ideal as the user's account in CRM has it owns many records and has lots of activities and such linked to it.   Is there some way to refresh or reset all permissions on a User or somehow see why CRM thinks this user does not have the privilege when it clearly does?  

Thanks.

*This post is locked for comments

I have the same question (0)
  • Suggested answer
    Arun Vinoth Profile Picture
    Arun Vinoth 11,615 Moderator on at

    Sometimes weird issues like this happens.

    In on-premise, you can refresh the user profile by changing the domainname to someone else. After save you can revert to the original user domainname.

    Basically the POA table has to recalculate & AD account resync will iron out all the wrinkles.

  • Sam Alex Profile Picture
    Sam Alex 6 on at

    I've tried that already, but it's still not working.  I took over the user's CRM account by changing the domain name to a test user, but the test user now has the same issue plus XRMToolBox Access Checker still shows no Read access to Report Entity.  I changed it back to the original user but still no go.  I also read that giving the user a new role with the required access then removing it can fix this sometimes, but that didn't work either.  Yet I can map the user to a new SystemUser entity record and add the exact same Roles and Teams and it works.  I also built a SQL statement joining [SystemUser], [SystemUserRoles], [Role],  [RolePrivileges], and [Privilege] together, and the appropriate Privileges exist.  I can give the user Sys Admin permissions and it turns green plus I can create a Role with just Read permissions on Report entity and it works, but the user isn't getting the Privilege from the Roles it already has which clearly do have this privilege.

    Checking POA table both users have access rights on their SystemUser and UserSettings Entity records which is expected plus the original user has some shares on completely unrelated custom entities so I think POA is okay.  But even after removing these other custom entity shares with just the two it's still the same.  So I don't believe this is related to POA.

  • Arun Vinoth Profile Picture
    Arun Vinoth 11,615 Moderator on at

    Sounds fishy. You are saying only one existing role privilege is not working for particular systemuser record (with any domainname). Am I right?

  • Sam Alex Profile Picture
    Sam Alex 6 on at

    Fishy indeed. Yes, other users with the exact same roles and teams in the same Business Unit work without issue and XRM Tool Box shows the Read privilege on Report Entity exists where this one user it doesn't.  I can even recreate the user with the exact same permissions and it works fine.  Something is very fishy about this one SystemUser, and I'm at a loss on what.  POA, UserSettings, SystemUser, Roles, Teams, everything I've checked is exactly the same.  Even running a query in SQL to link the Privilege for Read to Report Entity back to the User is the same where it should exist.  

    I could take the work around and create the new user and attempt to reassign all the old user's stuff to the new user, but since CRM doesn't allow SystemUser records to be deleted I'd rather find a way to fix this as opposed to a work around in-case it occurs again.

    For now I'm searching the entire database for all references to the SystemUser GUID's to compare and see anything that's different.  Just hoped someone else ran into this before and had some suggestions.

  • Raghu Krishnamurthy Profile Picture
    Raghu Krishnamurthy 80 on at

    I had faced a similar issue long back with CRM 2011. I had followed the below steps and it had worked.

    1. Elevate the user's privilege to System Admin.

    2. Run the report.

    3. Revert the privilege back to the original security role.

  • Sam Alex Profile Picture
    Sam Alex 6 on at

    Okay I found what I think is the problem, but I'm unsure how to fix it within a Microsoft supported means.  The difference is in SystemUserPrincipals.  I ran SQL Profiler as I checked the permissions in XMLToolBox and found the query it's running which joins the POA table to SystemUserPrincipals.  

    select max((POA.AccessRightsMask|POA.InheritedAccessRightsMask) & 0x00000001) +
max((POA.AccessRightsMask|POA.InheritedAccessRightsMask) & 0x00000002) +
max((POA.AccessRightsMask|POA.InheritedAccessRightsMask) & 0x00010000) +
max((POA.AccessRightsMask|POA.InheritedAccessRightsMask) & 0x00000004) +
max((POA.AccessRightsMask|POA.InheritedAccessRightsMask) & 0x00080000) +
max((POA.AccessRightsMask|POA.InheritedAccessRightsMask) & 0x00040000) +
max((POA.AccessRightsMask|POA.InheritedAccessRightsMask) & 0x00000010) +
max((POA.AccessRightsMask|POA.InheritedAccessRightsMask) & 0x00000020) as 'AccessRights'
from PrincipalObjectAccess as POA
join SystemUserPrincipals sup on POA.PrincipalId = sup.PrincipalId
where POA.ObjectId = @ObjectId AND
sup.SystemUserId = @PrincipalId and
POA.ObjectTypeCode = @ObjectTypeCode
group BY POA.ObjectId;

    When I compare the new account I created for the user which works to the original account with issues the Organization PrincipalId is missing from SystemUserPrincipals.  When I run this to compare the SystemUser entity to SystemUserPrincipals on the PrincipalID of the Organization there are 5 active Systemuser records with on Organizational PrincipalID in SystemUserPrincipals, the user with this issue is one of them.

    select su.FullName,
sup.PrincipalId
from dbo.SystemUserBase su
left outer join SystemUserPrincipals sup on sup.SystemUserId = su.SystemUserId and sup.PrincipalId = '7F5A1D29-D433-4AF9-8DAF-9DB85EC08A3A'
where su.IsDisabled = 0 and sup.PrincipalId is null;

    So I ran this to add it, which yes I know is totally unsupported, but this is a Test environment so no Production changes have occurred.  I hope to find a supported way to fix this if possible before even thinking of a SQL change, but at least I know what the issue is:

    insert into dbo.SystemUserPrincipals (SystemUserPrincipalId,PrincipalId,SystemUserId)
values (newid(),'7F5A1D29-D433-4AF9-8DAF-9DB85EC08A3A','FBFC5FAE-0FF1-E411-940F-005056843A8A');

    After this the Report Entity now shows the correct Privilege with Read Privilege.  So apparently the Organization PrincipalID was missing from the SystemUserPrincipal for the user when it was created or possibly it was removed somehow.  We never ever make direct SQL changes so I'm confident this wasn't due to a SQL change.  

    So anyone have a suggested way to update this through a supported means outside of SQL?

    Thanks.

  • Verified answer
    Sam Alex Profile Picture
    Sam Alex 6 on at

    Okay found a solution that appears to work.  When I checked Inactive users they do not have the Organization GUID in SystemUserPrincipals, so I deactivated then reactivated the users and it added the Organization GUID to the SystemUserPrincipals.  Simple enough... as to why these few users were missing the appropriate items in SystemUserPrincipals that's anyone's guess.  They were created over a span of a few years and by different users, so possibly just a SQL hiccup as they were modified.

  • Sam Alex Profile Picture
    Sam Alex 6 on at

    Ahh, I did this except that I didn't run the report, just promoted the user to System Admin then moved back.  But I found the fix was to deactivate then reactivate the user which fixed an underlying issue in SystemUserPrincipals.

Under review

Thank you for your reply! To ensure a great experience for everyone, your content is awaiting approval by our Community Managers. Please check back later.

Helpful resources

Quick Links

Responsible AI policies

As AI tools become more common, we’re introducing a Responsible AI Use…

Neeraj Kumar – Community Spotlight

We are honored to recognize Neeraj Kumar as our Community Spotlight honoree for…

Congratulations to the November Top 10 Community Leaders!

These are the community rock stars!

Leaderboard > 🔒一 Microsoft Dynamics CRM (Archived)

#1
SA-08121319-0 Profile Picture

SA-08121319-0 4

#1
Calum MacFarlane Profile Picture

Calum MacFarlane 4

#3
Alex Fun Wei Jie Profile Picture

Alex Fun Wei Jie 2

Last 30 days Overall leaderboard

Featured topics

Product updates

Dynamics 365 release plans