We recently discovered an "undocumented feature" in the Microsoft Dynamics CRM 2011 security model that only affects users on teams that own records. The issue came up when a client called and said that his sales people were able to see other people's opportunities when they shouldn't. The Sales Person security role was defined to only allow these people see their own opportunities, but we were able to determine that they were seeing opportunities owned by others when the parent customer of that opportunity (Account or Contact) was owned by a team that this user was a part of.
After opening a ticket with Microsoft, we learned that this was "functioning as designed." Although not documented anywhere, Microsoft Dynamics CRM permissions to child records are indeed inherited from parent records. The setting that drives this behavior is not documented but is configurable. On the relationship (in this case between Account and Opportunity), you must set the 'Type of Behavior' to 'Configurable Cascading' and both 'Assign' and 'Reparent' to 'Cascade None.'
At this point, you have stopped CRM from inheriting of permissions for future child records, but for opportunities that already exist, there is still an entry (a non 0 value in the InheritedAccessRightsMask field) in the PrincipalObjectAccess (POA) table that says this record has inherited permissions from its original parent. They can still be seen by the wrong users and since we have stopped the cascading, changing the owner of the parent record from the team to a different user no longer has any effect on the child record.
The recommended way to reset this field is to simply "reparent" the CRM opportunity temporarily (for instance to a dummy account) and then set the parent customer back to its original. The idea is that by setting the customer field, the system reexamines the relationship, sees that it is no longer cascading and that permissions should not be inherited, this then resets the InheritedAccessRightsMask to 0.
Hopefully this is as far as you need to read as this will clean up such a security issue in a vanilla system. In our particular client situation however, it did not resolve the issue because we had created an extra relationship between Account and Opportunity (a second lookup to Account on the Opportunity form). This relationship could not be set to 'Configurable Cascading' because the system will not allow you to have two different relationships that define cascading rules on the same two entities. This second relationship seemed to interfere with the resetting of the inheritance field and this was accepted as a bug by Microsoft. We are not expecting a fix any time soon for Microsoft CRM 2011.
If you run into this, your remaining options are few. If you have an on-premise implementation of Microsoft CRM you have the option of manipulating the SQL database directly to set the InheritedAccessRightsMask in the PrincipalObjectAccess table to '0' for the affected records. Note: Manipulating the database directly is completely unsupported and not recommended by Microsoft.
The only other option we can see is to remove the extra relationship and do the recommended cleanup described above. If you have data in that field, this will require some finagling to preserve it.
To avoid this scenario, when initially implementing Microsoft CRM in an environment where security needs to be tight and teams are going to own records, save yourself some trouble and turn off cascading from the start.
