For a recent project, I needed the ability to test custom role access within a D365FO environment but was having a difficult time getting a test account created to assign this access to. My personal user had SysAdmin access, was there anyway for me to be able to test role access with just my user account? Here is the solution I came up with!
Solution
The idea that I had was to have a simple form where I could assign and revoke the SysAdmin role from a user. This would allow me to:
- Assign the roles I would like to test to my own user while assigned the SysAdmin role,
- Revoke the SysAdmin role from my own user (leaving only the test roles assigned to my user)
- Test the role access
- After testing, assign the SysAdmin role back to my user
Custom Form Creation
The first thing I did was to create a new menu in the System Administration module area by first creating the extension of the System Administration menu object, and then creating a new menu item for my form:
The form I created was extremely simple, one button to assign the SysAdmin role and one button to revoke the SysAdmin role:
The code behind the buttons is fairly straight forward, but one thing I would like to point out is that D365FO treats the SysAdmin role somewhat differently than other roles. Normally when a role is revoked, the system will delete the entry from the SecurityUserRole table. For the SysAdmin role however, the system will never actually delete the entry from this table and instead will just set the ‘AssignmentStatus’ value on the role assignment to ‘Disabled’. If the user is assigned the SysAdmin role again in the future, the system will find the user role assignment that already exists and change the ‘AssignmentStatus’ from ‘Disabled’ to ‘Enabled’.
The code for the assignment of the SysAdmin role performs the following tasks:
- Gets the ID of the user that clicked on the button
- Queries the SecurityRole table to get the RecId of the SysAdmin role
- Looks to see if this user has an entry for the SysAdmin assignment in the SecurityUserRole table and if it does ensures that the AssignmentStatus value is set to ‘Enabled’
- If this has not been assigned to the user before, it will insert a record in the SecurityUserRole table for the SysAdmin role for the user
The code for the SysAdmin revoke performs the inverse of the steps above:
- Gets the ID of the user that clicked on the button
- Queries the SecurityRole table to get the RecId of the SysAdmin role
- Looks to see if this user has an entry for the SysAdmin assignment in the SecurityUserRole table and if it does ensures that the AssignmentStatus value is set to ‘Disabled’
- If the user is not currently assigned the SysAdmin role, it does not perform any task and alerts the user that the SysAdmin role is not assigned to them currently
The code used for the form can be found here.
I then created a custom security privilege, which has access to the menu item I created for the form itself and has access to the SecurityUserRole table to be able to perform the assign/revoke role tasks.
Testing the Solution
After completing the above steps we can see that there is a new entry in the System Administration module called ‘Alex Meyer’s Security Toolkit’ and under that is the ‘Assign/Revoke SysAdmin’ form:
When you click this button a dialog appears from the right side of the screen with the custom form:
To test the solution, I used a separate SysAdmin account in my environment and assigned the ‘Alex Meyer Security Toolkit’ custom role as well as any other roles I would like to test to the user. In this example, I just assigned the Accountant role to the user but you could assign any number of roles that you would like to test to the user.
Note: The ‘Alex Meyer Security Toolkit’ role must be assigned to your user otherwise you will be unable to assign the SysAdmin role back to this user after your testing
To give some context, here is what my environment looked like logged in with the SysAdmin role assigned:
Now let’s go and revoke the SysAdmin access for this user:
And we get a message stating the SysAdmin role is successfully revoked from the user:
Now when I refresh the screen, we can see that my view has changed to reflect the security assigned to the user without the SysAdmin role:
Once we are done testing, we can navigate back to the ‘Assign / Revoke SysAdmin’ form and click on the ‘Assign SysAdmin’ button:
We get a confirmation the SysAdmin role has been successfully assigned:
And after refreshing, we can see the SysAdmin role has been successfully assigned back to the user:
Considerations
The above solution cannot be used on user accounts that actually created/deployed the environment as D365FO does not allow that user to have their SysAdmin access revoked, but can be used for any other user account. This is why I had to use a separate SysAdmin account in my testing above.
Also while this project absolutely works as intended, I cannot recommend this to be installed in a PROD instance of D365FO as of yet. There are additional features (like adding a logging/reporting functionality that I talk about in the next section) as well as error handling that I would like to better round out before I can confidently say this is PROD ready.
Next Steps
After creating this solution, I started to think more about the possibilities of using this as a type of ‘firefighter access’ functionality within D365FO which is a feature that I get asked about quite often (especially if the end user has background in SAP which has this feature out of the box). To be able to accomplish this we would need to do the following things:
- Have the ability to assign/revoke the SysAdmin role with a click of a button, while also being able to secure who has the ability to do this (this is already completed in the blog post above)
- Log when a user assigns/revokes the SysAdmin role
- Have the ability to report on this SysAdmin assignment log
- Have a way to report on what a user did while assigned SysAdmin, this can be accomplished through a combination of telemetry data and a change tracking solution
In the next few weeks, I plan on creating the above solution in steps while documenting the process along the way.
Stay tuned…
I really enjoy your blogs.
I’ve tried to contact you via site but it doesn’t appear anything is sent to you.
Two questions:
1. Have you created a role that has system admin but deny permission on assigning other users to roles?
2. Have you created a user that has all roles but not system admin?
BTW – your read-only role was a huge help to us.
Thanks,
Michael C.
Michael,
I apologize for not getting back to you – not sure why the messages were not coming across I will look into that.
To answer your questions:
1) The SysAdmin role is a programmatic role, it cannot be modified. Once you assign it a user has full access to everything in D365FO and not even the Deny permission can override it.
2) Are you asking to create a ‘fake’ SysAdmin role that would have full control to all objects but not have SysAdmin? You could potentially utilize the same process as when you created the ‘read only’ role but assign Delete permissions to it, but my question would be what is the business use case for something like this?
Thanks for this blog,
I have one question, is there some type of user security auditing native tool inside D365 FO that can be utilized to see who has been assigning roles in real time or not. we keep seeing users with in our environment with unauthorized roles or incorrect roles. I know this is possible in Fastpath but I was wondering if we can use FO.
Bruk,
The Microsoft answer for logging user activity within D365FO is the database log. While this functionality will show what users are making changes to objects it can consume a lot of system resources and cause performance issues. This is where a dedicated tool like the Fastpath Change Tracking (formerly known as Audit Trail) can help with that process.
Thank you so much.