Administering GP Security

During my Interactive Discussion at Convergence over GP Security it became clear that I need to post what I do with my customers to help with administering and maintaining their GP security.  This will only focus on GP 10 and later.

There are many very well designed reports buildt into the product which are great for documenting, however, they fall short in helping to analyze or maintain your security.  To do security analysis you need something more interactive, something you can slice-n-dice or drill into. 

Here are two tools that I use:

• SQL View (that I can import into Excel)

• Support Debugging Tool

SQL View:

There is a great SQL View on MPV Victoria Yudin’s blog site called “SQL View with Security and SmartList details in GP”.  Be sure to read her entire post as the SQL View is dependent on the Security Resource Descriptions table being populated, but not by default.  The (counter intuitive) Clear Data method that she describes to populate the table only populates descriptions for Forms and Reports.   The SQL view will return every security setting, but only Forms and Reports will have descriptions.   Since 90% of security analysis and debugging is related to Forms and Report, this view is a great place to start.

Once you have the view in place, there are many ways to get the data into Excel. I am going to give you my favorite method through SmartList Builder.  With SmartList Builder you can point directly to the view, and once you have built and deployed your SmartList, the true slicing-n-dicing can begin!

PowerUser – The access that PowerUsers have will not show up in this SQL View.  Why? Because the PowerUser Role is not really a Role at all--it is a hard coded feature that exempts the user from ALL security.  What this really means is that there are no security tasks or operations created, so I don’t recommend the use of PowerUser in any environment.  If a user needs PowerUser type access, I recommend creating a new role and assigning the specific access needed; typically speaking, the Power User role won’t pass muster with SOX compliance.

As I mentioned before, because only Forms and Reports are populated into the Security Descriptions table you are only getting 90% of the resources, and some require 100%.  This is usually driven out of a need to comply with SOX reporting.   One of the big items for SOX is reporting who has Series Posting Permissions access.  Since this type of security access is not a Form or Report, the description of it doesn’t exist in the Resource Description table.  Other resources outside of Forms and Reports include Customization Tools , Document Access, Files (Tables),  Letters, Navigation Lists, SmartList Builder Permissions, SmartList Object, Microsoft Dynamics GP Import, etc.  If you need to see a description for ALL resources, we now have a solution for that.  The Support Debugging Tool (which I talk about later) has a feature that will populate the table with every resource in your system including 3rd party dexterity based solutions.  This new feature will be included in build 15. At the time of this posting build 15 is still in Beta but should be released soon. 

To populate the Resource Descriptions Table (SY09400) using the Support Debugging Tool enhancement, you will need to make sure that you have build 15 or greater installed.  Build 15 will trigger in on the Clear Data routine described in Victoria’s blog and populate the rest of the resource descriptions.  No additional steps are required. 

Support Debugging Tool:

What?  You don’t know what this is??  Then you missed the hottest session at Convergence this year!  The Support Debugging Tool is a tool created by David Musgrave to help resolve tricky support cases.  The SDT has a ton of tools built into it to help administer many aspects of GP.  The security pieces are a small part of the tool, but I find it to be the most important to my customers. 

The Options (windows) that I will be discussing are:

• Security Information window
• Security Profiler window

Security Information window:

As Mariano Gomez would ask David Musgrave on stage at convergence, “I need to know who in my company has access to Sales Transaction Entry window. Can the Support Debugging Tool help me with this?”.  Of course David’s answer would be, “Yes it can!”.

The beauty of this window is its ability to give you a lot of information quickly.  Describing all the features of the window would take days, hopefully this picture will give you a understanding of the power of this tool.

As you can see, the current resource is the Sales Transaction Entry window.  You can see on the right what users have access to this window, and the left pane shows that the user got access to this window via the PowerUser Role.  Lastly, in the System Level, you can see all the Tasks that include this window and all the roles associated with the task.

Seeing all of this in one screen is very powerful.

Security Profiler Window:

Doesn't it drive you crazy when a user keeps getting an access denied message and you can’t figure out what resource it is trying to open??  The Security Profiler window is the answer to that problem.  After the window is open it will record all security check information for that user.  If a user tries to access a resource that they don’t have access to, it will record a “Denied” status (see the last entry on the clip below).  The Security Profiler actually shows much more information, but I was unable to include everything in this picture.

 
To see a prime example of how to use the Security Profiler in all its grandeur, please check out David’s Blog entry on Solving Security Privileges Errors Using the Support Debugging Tool.

The Support Debugging Tool is downloadable via PartnerSource, if you are a customer then you have to ask your partner for a copy of it.  For more information on the tool please go to David’s blog  Support Debugging Tool for Microsoft Dynamics GP.

Conclusion:

These two tools have helped my customers out greatly.  I hope they help you just as much!

Terry Blaser