Personalized Community is here!
Quickly customize your community to find the content you seek.
Have questions on moving to the cloud? Visit the Dynamics 365 Migration Community today! Microsoft’s extensive network of Dynamics AX and Dynamics CRM experts can help.
2021 Release Wave 1Discover the latest updates and new features to Dynamics 365 planned April 2021 through September 2021.
Release overview guides and videos Release Plan | Preview 2021 Release Wave 1 Timeline
The FastTrack program is designed to help you accelerate your Dynamics 365 deployment with confidence.
FastTrack Program | Finance and Operations TechTalks | Customer Engagement TechTalks | Upcoming TechTalks | All TechTalks
Or as I like to call it - Fun with PrincipalObjectAccess records!
Consider the following scenario.
Test it, works every time.
Going to a more technical view, the PrincipalObjectAccess table is designed to store both directly granted permissions (AccessRightsMask) and indirectly granted permissions (InheritedAccessRightsMask). These will generally come in pairs or chains where one or more inherited permissions have a directly granted permission at the top.
What happens in the sequence described above is that we are left with inherited permissions to records that are not linked to directly granted permissions. As a result they cannot be removed and are just left as orphaned permissions floating in the system.
Back to my real-life CRM system. It now appears that I have thousands (if not more) of these ghost permissions floating around as I have no easy or supported way of removing them. Some users have access to data they are not supposed to see.
Any ideas?You know you want to, it's a challenging problem! ;)
To keep this post short, I have not provided any queries or heavy technical details. I will provide those in another post.
As promised, some more technical details.
The query I used to output the data below is this:
from PrincipalObjectAccess poa full join
Account a on a.AccountId = poa.ObjectId
and poa.ObjectTypeCode = 1
where a.AccountId in (
Taking my example sequence step by step, the results for this query are the following:
Neither of the accounts has any POA records linked to them. They were never shared.
After sharing the parent
This is again as expected. The parent account has a direct permission of '1' and the child has an inherited permission of '134217729' (this is just a '1' with the additional Inherited flag in a high bit).
After child ownership change
Here we see CRM's security model beginning to crumble. While I can still logically expect a '1' permission for the parent, this should no longer be inherited by the child as the rule for 'Cascade User-owned' is no longer valid. However, I could live with this if it stopped here. It's about to get much worse.
After parent sharing revoking
And there you have it. The child account now has ghost permissions assigned to it. These are inherited from... Nowhere. They are not visible in the UI and cannot be modified.
The only way to revoke these ghost permissions would be to revert the ownership change, return the parent sharing, and then revoke it again.
Of course, there is always direct database deletions but we all know that's not the way to go.
Did you find an answer to this question?
Any update on this?
No solution to this was found.
Wow! These inherited permissions can't be revoked even programmatically. I too have the same problem. Its really challenging!
Business Applications communities