Photo designed by FreePik
Security within ERP systems is not easy or straightforward, over the years I have heard a lot of different ways that people have tried to create an ‘easy button’ for developing or configuring security. In most cases, these methods do not follow best practice but in some cases they can be flat out wrong and open your organization up to a potential security issue.
To that end, I wanted to start on on-going series of ‘security myths’ I have heard, focusing on D365FO but in most cases these also apply to other ERP systems as well.
Myth #1 – You Can Restrict Legal Entity / Company Access Within D365FO By Just Restricting the System User Role
I’ve actually written about this before but I wanted to bring it up again as this scenario has come up multiple times in the past.
The idea in this case is that instead of applying legal entity restrictions to all security roles assigned to a user, you can achieve security by just restricting legal entity access to the System User role. This normally occurs when a user is assigned a large number of roles and whoever is in charge of security doesn’t want to have to go to each role a user is assigned and manually assign the correct legal entity restrictions.
So the scenario would be something like this, I have a user that is assigned the Accountant role and System User role:
For the Accountant role, no legal entity restriction is enabled:
But for the System User role, you restrict the access to the correct legal entities the user should have. In this case, the Contoso Consulting (GLSI) legal entity:
So they can log in to the GLSI company:
But if they try to switch companies, they would get access denied error message:
Which seems secure… but let’s dig a little deeper.
If I now navigate to the ‘All Vendors’ page which the user has access to via the Accountant role in the GLSI company, everything works as expected:
But you may notice that in D365FO, the company or legal entity context is set as a query parameter in the URL meaning that by simply changing this to another company ID code I can switch companies. For example, if I change this to Contoso Consulting USA company (which is Company ID ‘USSI’) the system will gladly return the data.
This means that anyone that knows the company IDs of your system can easily navigate around and bypass the System User restriction.
The same thing can happen via code as well, let’s say I have a simple custom form that allows me to create Vendor Groups. The form takes in a vendor group name and a company / legal entity ID. When a user clicks the Submit button, the code changes company context to whatever company ID was entered, and uses the vendor group name supplied to create a new vendor group.
Note: This is not secure or safe code, it is purely meant to demonstrate this scenario.
When I navigate to this form with my test user, even though I am under the context of the GLSI company I can enter another another company within this form to test the creation of the vendor group:
When I click the Submit button, no permission error is presented and instead I get a success message:
And if I go and check the vendor groups in the USSI company, we can see this vendor group was successfully created:
This again shows that just applying legal entity restrictions to the System User role is not enough to effectively secure your D365FO environment, you must apply any legal entity restrictions that a user is required to have to all security roles assigned to the user.
Security By Obscurity is Not Secure
The idea of ‘security by obscurity‘ is not unique to D365FO, in fact it has been around for decades. The idea is that by hiding or not documenting certain features I can secure a system because no one knows about it. In this case, by ‘hiding’ the ability for a user to easily switch companies I can secure the system in this way. As proven above, this is not an effective technique.
Always be sure whatever system you are trying to secure, that you understand and utilize the security model within that system and do not try and secure it by ‘hiding’ or ‘obfuscating’ a particular feature or functionality.
Conclusion
I plan on writing about other ‘security myths’ in the coming weeks, if you have a ‘myth’ you have ran into feel free to drop it in the comments below and it might be a future blog post!
Shout out to Andrew Tucker for the inspiration for this blog post!