Tips on AX 2012 Security Development Tool – Part 6

As mentioned in my previous blog related to the security development tool, I will have a neat tip for developers (and interested functional people). With help of the Security Development Tool, you can use the AX debugger to debug some scenarios which are not reproducible when you have the system administrator role assigned. With system administration rights the system will behave different compared to users with limited permissions. In this post I will explain you how to use the AX debugger in combination with the Security Development Tool.

Tip: Use the debugger with limited permissions

First I would like to give also credits to a great person I have worked with on a project where we discovered the “hidden” feature within the Security Development Tool. His name is Peter Collewijn. Because there was an issue during the implementation which was only reproducible with limited access rights, we were looking for a way to find the culprit of it. He asked whether it was possible to use the Security test workspace in combination with the debugger. Where other people told him it was not possible and insane, I gave it a chance… So we tried out and read below the outcome…

Well in fact the procedure to achieve this is very easy. For this blog post I did not create a complex scenario for debugging, but simply added a breakpoint within an AX method to show you this feature. Before you start, make sure you do have the System administrator role within AX and you are assigned to the AD group Microsoft Dynamics AX Debugging Users.

1. Put a breakpoint where you want to have the debugger enabled. In this example I have put the breakpoint on the add method of the class Info. In this way on every infolog message the debugger will be triggered.

2. Open the security development tool form and select the role which raises the errors.

3. Open the Security test workspace. You will get the next notification first. It will provide some basic information what will happen with your security settings in AX during the time you have the workspace opened.

4. In this scenario I will just do something stupid to have AX raising an infolog by not filling all mandatory fields on the Number sequence form.

5. Try to close the form or save the records and the debugger will be triggered.

Now you are able to debug using the permissions of another user. Note that business logic that runs in CIL will not be triggered when you put a breakpoint. You can then either disable the user option Execute business operations in CIL or attach the Microsoft Visual Studio debugger to the Application Object Server (AOS). Have also a look at the Technet page Debug in Interpreted Mode Your X++ Code that Runs as .NET CIL [AX 2012].

Tip: Turn on portal security

Normally when you open the Security test workspace, a new workspace will be opened and the session will be restricted to non Admin mode.  The current roles of the user will be disabled, except for the System administrator and System user role. The role which should be tested will be granted to the current user.

Because you still have System administrator rights in AX, you cannot test the role on the enterprise portal and also SSRS reports will behave differently compared to normal user rights. As SSRS will use another thread connection towards the AOS, the SSRS started from the Security test workspace will have all rights on every table. So when you have tested the role, normal users can get an error on e.g. display methods because the user within the normal role has no access to certain tables.

To be able to test the Portal security and SSRS reports correctly you can enable the Portal security. If you then open the Security test workspace, you will get another message which you need to read very carefully! In this case also the System administrator role will be disabled. When something goes wrong, e.g. a client crash, you can’t login anymore because the System administrator role is disabled. The information message will tell you how to recover from this issue.

Now you are able to fully test the role also with restricted rights for the Enterprise portal and SSRS reports. Note that when you use this option, the trick with the AX debugger is not working as you are not a System administrator during the time the Security test workspace is active.

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!