What is the purpose of the two new XDS security roles?

Recently, I discovered two new security roles in the application that seem to have a relation with eXtensible Data Security (XDS). Anything related to security and for that reason also XDS intrigues me. In this post, you will read about the two new security roles and how they can be useful, or not…

XDS roles for bypassing policies?

While working on a specific requirement, I wanted to add roles to a user and found two new security roles having a technical label and made a note to check out their purpose. Both roles do have the word bypass in the name, which would mean that it would elevate the rights and users will see all data, regardless of activated security policies as part of the eXtensible Data Security (XDS) framework. I’m not fully sure, but I think these roles got added in version 10.0.37.

XDSDataAccessPolicyBypassRole

The description of the first of the two is clear. If you add this to a user, the permissions become role-based and indeed will bypass the security policies. My first test was with one of the XDS examples, I created before: Secure data by warehouse. Despite the active policy and assigned warehouses for the user, it showed all warehouses. The XDSDataAccessPolicyBypassRole role is not aware of individual policies, it will bypass them all. I also tested the same with Global address book security. In my setup, specific users were not able to see all customers, only those with specific address book tags. When this role is assigned, also for this scenario, the record-based data security is being ignored and the user will see all customers.

After the tests, I searched for more information on the internet and found an updated section about this role on Microsoft Learn: Extensible data security policies – Finance & Operations | Dynamics 365 | Microsoft Learn. Before providing my thoughts on this role, let’s first learn about the other role.

XDSPolicyByPassRoleScenarioTestRole

The description of this security role raises some questions for me. The description is: “This role is used for XDSPolicy ByPass UT“. When reading the documentation on Microsoft Learn, there is no information provided for this role. Instead, it suggests opening links to XBOX support which is not useful for this topic. An additional search on the internet does not give a specific hint to a post talking about this role. Well, by publishing this post, search engines should be able to direct to this post, I suppose.

I did perform a Metadata search in Visual Studio, reverse-engineered some kernel DLLs, and used the cross-reference. Initially, there was no hit apart from finding the security role object with the name XDSPolicyByPassRoleScenarioTestRole. I realized I didn’t update the cross-references after one or two updates. When I updated the cross-references for all standard application objects, it brought me to a security policy, named: XDSCustTableOnCustGroup10Policy.

When looking at the properties, the security role I wanted to investigate is used to limit a security policy to this single role. So, the name is suggesting to bypass security policies, but it is used for a different purpose. This security policy is restricting the CustGroup table. But for what reason? The name suggests a group with ID 10. When looking at the details of how the query XDSQCustGroup10Query is designed, indeed the query has a hardcoded value 10 on the CustGroup field.

So, what is the purpose of this role and security policy? The objects are part of the model Application foundation. It is odd to have a security policy in the standard application where the customer group has a hard-coded value. The customer group value 10 is used in the demo dataset but is not expected to exist in all Dynamics 365 production instances around the world. It looks like the abbreviation UT in the description of this role means Unit Test. I can only think of having this security role and policy being used for test scenarios, for the security role that bypasses the data security (XDSDataAccessPolicyBypassRole). For customer implementations, the security policy XDSCustTableOnCustGroup10Policy and the security role XDSPolicyByPassRoleScenarioTestRole are not relevant. Weirdly, Microsoft added these objects in the standard application. Hard-coded values, like the assumption of the existence of a customer group value, don’t belong in a standard application. I would suggest ignoring this bypass test role.

When to bypass data security policies

Coming back to the first role named XDSDataAccessPolicyBypassRole. As mentioned, this role will change user behavior by having pure role-based access permissions without restrictions on data as defined in security policies. When will this be useful and what considerations would you need to take before applying such a role to a user in an environment?

Initially, I think, granting access to this role should be an exception. Like being careful in assigning the system administrator role, this should also be carefully considered. Don’t assign this role, unless there is a valid business justification. Some reasons why bypassing the data security might be valid are:

• Check if missing data is caused by an XDS security policy
• Temporary access to add new setup records in tables that are restricted by a policy.
• An own configured or developed restricted administrator role that needs to have access to all data, like a system administrator.

When possible, use this role in non-production environments. Only when you think there is no other option, then you can consider assigning the role to a user in a production environment. In case you have businesses where GxP is important or have sensitive and private data, also policies on these tables are ignored. There is a feature in the application called Private location security. This feature is also managed with the help of the XDS framework. In case you apply the XDSDataAccessPolicyBypassRole, the user will be able to see all private addresses and contact details despite the settings for the roles in the parameters. In case you allow a user to bypass the data security policies, you might violate e.g. GDPR regulations. Not only the European Union but also other countries have data privacy laws that should be followed carefully to prevent possible high fines for privacy breaches.

I do hope you liked this post and will add value for you in your daily work as a professional. If you have related questions or feedback, don’t hesitate to use the Comment feature below.


That’s all for now. Till next time!