This issue has come up a number of times over the years and was raised again recently in a support case.

Summary

Here is the situation:

• Security Tasks and Security Roles have all been set up as desired. Security Roles have been assigned to the users in the live company and everything is working as expected. Users only have access to the areas of the application that they should.
   
• A test company is added to the system and a backup of the live company is restored into the test company. The Security Roles for the users were copied from the live company so that the security access was the same.
   
• When users log into the test company, they can access all of the application as though they have POWERUSER access. All the security settings look correct, but they appear to be ignored.
   
• Checking with the Fabrikam sample company, the same Security Roles are copied across and access is controlled as expected.

So what is happening that the security settings are not working in the test company?

Solution

The solution to this problem was very simple. The security settings were actually being ignored for this one company, and that was because Security was not enabled for the company. One look at the Company Setup (Microsoft Dynamics GP >> Tools >> Setup >> Company >> Company) and it was easy to see the problem.

The Security checkbox was not selected and so checking of security settings for the company is disabled. Selecting the Security checkbox and clicking OK resolved the issue. These settings are not restored with the company database as they reside in the SY_Company_MSTR (SY01500) table in the DYNAMICS system database.

Discussion

While we have resolved the issue, I wanted to discuss the consequences of not having the Security checkbox selected on a company.

Some may say that this is the test company and that we want users to be able to explore all aspects of the Microsoft Dynamics GP application so they can learn how to work with areas that are normally outside their day-to-day roles. I agree that this is a valid use of the test company, but disabling security entirely for the company is not the correct approach.

The reason for my concern is that if a user has equivalent to POWERUSER access in the test company, they can access the System series windows which control security. Now if they are not protected with the System Password, the user would be able to change security settings for any user in any company. This means that they could elevate their privileges in the live company.

So if you are planning to have any security active on your system in any company, make sure that ALL companies have the Security checkbox selected. If you want to give more access to users in the test company, then grant them additional Security Roles for the areas of the application you wish them to see.

Don't give them POWERUSER access in the test company and don't disable security entirely in the test company.

Additional Note 

If you use the Support Debugging Tool's Security Information window to look at what is happening, it will highlight the issue with bold red text.

The Security Information window shows that Access is Denied to the Debtor Maintenance / Customer Maintenance window. It also shows that no Alternate/Modified Forms and Reports ID has been chosen for the selected user. However, as Security is not enabled for this company, the user can access all windows as though they are a POWERUSER.

I promised that I would not name the consultant who raised this recent case..... but everyone around you can see you blushing as you read this.

Enjoy

David