How to identify what GP Security Role is needed to access a particular window

David Musgrave posted a very useful walkthrough on using the Support Debugging Tool to see which Roles a user would need to be assigned to in order to access a particular window.  As David pointed out, this is just one of the many uses of the tool and just one example of why I’m installing the tool on all new GP installs and upgrades. 

Managing Dynamics GP without using sa login

Managing GP security without sa user – other options exist, these steps use the most secure options for each task

1. Create new user in GP to use as the GP administrator

2. Grant access to all companies

3. Make user member of POWERUSER role

4. In SQL Server, assign user to securityadmin server role

5. To be able to create new users, must be member of db_accessadmin and db_securityadmin roles in DYNAMICS database

6. To be able to delete existing users, must be member of db_accessadmin role in all company databases

7. To be able to grant/remove access to companies, must be member of db_securityadmin role in all company databases

8. To backup databases, must be member of db_backupoperator role in database

9. Only sa user is allowed to restore databases due to risk of data damage

10. To manage business alerts, user must be member of sysadmin server role

11. To perform SQL maintenance in GP, user must be member of sysadmin server role or DYNSA (db owner) login will work

12. To delete companies, user must be member of sysadmin server role or DYNSA user

Alternate GP Admin user may be assigned sysadmin server role to be able to do all the tasks above, with the exception of restoring databases.  Security concerns may make steps above necessary rather than giving user sysadmin server role.

How to avoid using sa user

From Accolade newsletter

Eliminating the SA User from GP

No, you can't.  Now most of you don't care or are not concerned but with so much SO Madness (that's Sarbanes Oxley, the law that will cost the American public more than Enron ever did) people are asking how to get rid of this master user id.  And, while you can't eliminate it, you can restrict it and use a different user id with the same rights.

SA is a MS-SQL user id that is adopted by Dynamics GP.  To restrict its use in Dynamics, remove access to companies for the SA user.  You will, however need a replacement.

In Version 10, any user id can be assigned to the poweruser role.  This will give that user most of the rights of the SA user ID.  For the remaining few tasks that only SA can perform, use the DYNSA user.  This user also has all of the rights of SA but is a Dynamics GP constructio

Another updating to GP10 security post

GP 10 Security Upgrade Helpers

By Mark on System

Ok, you should know by now that upgrading security in GP 10 from 8.0 or 9.0 has been a less than pleasant experience. The new security model is considerably better but has introduced pain into the upgrade.
Here's a small roundup of tips:

• SP1 seems to have helped the process go from nada to something
• Consider rebuilding security despite a working upgrade. You ultimately wont' be happy with the results long term results of the upgrade but it will get you live. Resist the urge to put a security rebuild in the terminally delayed Phase 2. Stick in the upgrade plan!
• Turn on activity tracking for failed access to windows and reports. This will at least give you an indicator of what access failed post upgrade.
• Update: I missed one! From Jim on our IBIS help desk, there is a TASK (not a role) a TASK called defaultuser. Out of the box, the defaultuser task has rights to enter and edit accounts in the chart of account. We've seen cases where folks are setting up roles and adding tasks. They add the defaultuser task not realizing that it has chart of account modification priviliges.
• Update: Ok I missed two! There's no security settings import/export so you can't build your dream security in test and easily migrate it to live. At least not that I've seen yet.

I have a couple more but they've either come from priviledged sources or I need to verify more info.

Cindy Mikeworth was kind enough to pass along some of this info from the GP Private Newsgroup. I'm careful about what I post from there but her information was generic enough to be useful without violating any agreements. Thanks Cindy!

GP10 Upgrading Security

Security Upgrade to GP 10 - Upgrade Security or Set Up Security from Scratch?

By Jivtesh Singh

A recent discussion in the forums about upgrading security went like this -

http://www.microsoft.com

Brad (Customer): Does anyone know if there is a tool or utility to convert Advanced Security in GP 8 to the new security model in GP 10. Lots of time and effort went into setting up security in 8 and would hate to redo it.

David (from Microsoft) : There is a security conversion tool which can be used during the upgrade of the DYNAMICS database.

Before you use the tool, you should be aware of how it works and what the consequences of using the tool are.

In the new model, each user can be assigned multiple security roles. Each role is made up of tasks and each task is made up of operations. Operations are the actual access permissions as shown in v8 Security (Standard or Advanced).

When you use the conversion tool, it will create a new security task and matching security role for each user/company combination.

While this will provide the same access you had in v8, it will not leverage the role based model at all. Also, maintenance would need to be handled on a individual user/company combination as there are no classes or
multi-selection in v10.0.

My personal opinion is to promote this as a perfect opportunity to redo security using the new more powerful and flexible role based pessimistic model.

Brad (Customer) : Thank you very much for your answer, I understand the added granularity that
the new security model allows, unfortunately our Sarbanes auditors aren't as flexible.

Now I totally understand what Brad is saying - It takes a lot of time and effort to set up Security. Making sure each user has access to what they are required to do, not more, not less - is work. And if you have something working - you generally don't want to break it.

At the same time I can understand David's pain - The security architecture in GP 10 is miles ahead of the security in GP8/9. Its in a different generation altogether! And as he points out correctly - in the longer run - it would be difficult to maintain the upgraded security. Maintaining GP 10 Tasks and Roles are much more easy.

I guess there is no simple answer to this. What I decided to do was - to do some tests and show how security upgrades. Perhaps, that would probably make it a little easier for people to make a decision.

If you have any inputs or suggestions, do let me know.

Security in GP 9

I created a test company in GP 9 and added 6 users in it.

1. I created 3 classes.

2. I assigned 3 users - to a class "AP Clerk".

3. One user was given a class - "Accounting Manager".

4. The two remaining users - were not given a class - I set up security for them independently

Users Created in GP 9

How the Security upgraded to GP 10

In GP 10

1. Each Class was translated to a task.

2. Each "User/Company" Security permissions was translated to a Role. This role - had one task - which in turn had the permissions.

3. All Users were assigned their own individual "User/Company" Role. None of the users was assigned to the common class.

A Task was made for each Class

A Task was made for each User/Company Combination

The User was given access to the new Role specific to that User

A Task Broken down into Operations

A Alternate Modified Reports ID was made for each User and Class.

Maintenance Problems - When you use Upgraded Security

Having a Role for each User, is a maintenance nightmare. You would have to make a change in 50 places for 50 users.

If you have to make a change to the class "AP Clerk" - that is not possible immediately. You would have to

a) Make a role which maps to each task created from a GP 9 class

b) Assign all the three users access to the new role.

Now when you make a change to that role, all users would pick it up.

This looks kind of ugly, because each Role just has one task, which as the permissions. In a way the Role is just a pseudo role. It sits there as a proxy, looking at what's going on feeling useless about its existence.

However, it's the best that can probably be done in migrating to a completely new architecture.

Now if you were to set up the same security in GP 10
. Here's how you would probably do it. You would create a role AP Clerk, and all relevant users would be assigned that role. You would have relevant tasks in that role. Then, when you make a change in the role - all users would pick up the change.

Additionally you could use Tasks to further break down your security architecture. Roles, Tasks and Operations in GP 10 offer a far greater potential to plan security in comparison to Classes and Operations in GP 9.

Knowing what's possible with GP 10 security - I would feel uneasy, in just migrating security and using it the way it migrated. Everything would probably work - but it is just not the way it is supposed to work.