Dynamics F/SCM Customer Experience (CRM) Dynamics GP Dynamics Business Central (NAV) Dynamics SL Power Platform Fabric Copilot

[Michelle McDonald]

Hello GPUG friends,

Our external auditors have expressed concern that several of us in Finance and Accounting have the PowerUser role/permissions in GP.  The auditors perceive that this level of permissions give us GP users too high a level of administrative access/rights.

ONLY our IT department (who are NOT GP users) has the SA permissions, which as I understand (as a layperson) is the uber administrative/security level of permissions.

Can anyone provide or point me to a written definition of the difference between the SA and Poweruser roles so that I can share this with our auditors?  Thanks in advance for any help.

Michelle

——————————
Michelle McDonald
Director of Finance
The Annenberg Foundation
Los Angeles CA
——————————

[Jo deRuiter]

Hi

‘sa’, DYNSA, and POWERUSER in Dynamics GP

Jpdavey		remove preview
‘sa’, DYNSA, and POWERUSER in Dynamics GP Updated 4/2/2015 I sometimes get questions about whether the ‘sa’ user is required for Microsoft Dynamics GP, what an alternative for ‘sa’ is, and what the POWERUSER Security Role really does. Well, I’m not a Dynamics GP developer at Microsoft, but here is what I know from what I’ve seen. View this on Jpdavey >

GPTip42day – SA vs. DYNSA – Microsoft Dynamics GP Community

Dynamics		remove preview
GPTip42day – SA vs. DYNSA – Microsoft Dynamics GP Community 1. SA is the SQL database system administrator and has full access to all databases on the SQL Server, including non-GP databases. DYNSA is the GP database administrator and has access to all GP databases only. 2. SA and DYNSA are both granted Power User roles automatically in GP Security. View this on Dynamics >

?

——————————
Kindest Regards,

Jo deRuiter
“That GP Red Head”
Advanced Credentialed Professional-Dynamics GP
Member, GPUG GP Credentialing Exam Committee
Chairman, GPUG Partner Advisory Board
“……what isn’t she up to?”
Heartland Business Systems, LLC
Senior Financial Systems Consultant
Milwaukee, WI
770-906-4504 (Cell)
——————————
——————————————-

[Jen Kuntz]

In addition to what Jo posted, I’d recommend reading this from Fastpath:

https://www.gofastpath.com/minimizing-the-use-of-sa-in-microsoft-dynamics-gp-white-paper

Long story short:

• ‘sa’ is a SQL Server login, and technically isn’t a “GP” user as it’s managed outside of Dynamics GP entirely. When used in GP, it can do anything without restriction. It is a POWERUSER with additional SQL permissions basically.
• POWERUSER is a security role in GP which effectively grants access to every resource in GP.
• The handful of things ‘sa’ can do that a “normal” GP user with POWERUSER can’t is a very short list (things like creating a new user, assigning user access).

99% of what ‘sa’ can do, a POWERUSER can do, so yes, I would agree with your auditors that there is a concern if “several” people are in a POWERUSER role. IMHO, POWERUSER should be limited to a very short list of people who require extensive access to administer your system but that’s it. Normal users should not be in a POWERUSER role. Proper role-based security is the first step in establishing proper internal controls with regards to the software functions.

This might not be what you were hoping for, unfortunately….

Jen

——————————
Jen Kuntz, CPA, CGA, Microsoft MVP (Business Solutions)
Manager, Business Solutions
Energy+ Inc.
Cambridge, ON, Canada
——————————
——————————————-

[Rob Klaproth]

Well Jen beat me to it, but I’ll second reading the Fastpath article.

Also, some of the 3rd party modules “hard code” the use of the sa user, meaning when you’re not logged in as the sa user you can’t upgrade the module or do any sort of table initialization routines because it needs special permissions in SQL to create those tables, POWERUSERS do not (although DYNSA does).

For example, Mekorma, when logged in as a regular user with POWERUSER can not run table maintenance.  However, you DO NOT need to use “sa” in Mekorma, you can use DYNSA.

So, the sa password should be for your company’s DBA only, the GP admin should use DYNSA, or read the FastPath article to give your GP admin account the permissions it needs in SQL.

Last, but not least, PSTL, aka “Technical Service Tools” is another one of those odd beasts that seem to depend on the sa account for some reason, so you may still need sa to do that as well.

——————————
Rob Klaproth
Dynamics Certified Professional
(GP Install & Configure)
Sr. GP Consultant
Armanino, LLP
San Diego, CA
——————————
——————————————-

[Beat Bucher]

Michelle,
To emphasize on what all others have replied,  POWERUSER is not a real security role in GP.. you can’t alter or delete it.. it’s part of the system and the reason behind it is that when you login into GP with a user assigned to the POWERUSER role, the code just bypasses all security access validation… It’s like jumping ahead of the line in your favorite store/boutique/restaurant 🙂

Several years ago when Microsoft moved from the “optimistic” to the “pessimistic” security model (from GP 9.0 to 10.0), they provided a tool to migrate the existing security schema from the old 9.0 release to adapt to the new role/task/resource based context.. which in return created potentially millions of records in the security tables, causing lots of grief to the end-users (I’ve witnessed login times as long as 10 minutes! when 2 users where login simultaneously into GP!)..  And that’s when the GP admin, tired of all the complains, puts the most frequent users to the POWERUSER role just to get them off the phone.. 

If that is the case, the only real cure to this is to revise completely from A to Z your GP security setup, and there the GP Power Tools can be of tremendous help.. 

There are good reasons your auditors should be worried about that situation.. 
Good luck.

——————————
Beat Bucher
Business Analyst, Dynamics GP SME
Ultra-Electronics Forensic Technology Inc.
Montreal QC/Canada
@GP_Beat http://dyngpbeat.wordpress.com/
Montreal QC GPUG Chapter Leader
GP2013R2 / MR2012 CU14
——————————
——————————————-

[Derek Albaugh]

To add to what everyone has said, which is completely correct…..

The main thing with ‘sa’ is that it is the system administrator login for SQL Server, meaning it has ALL permissions to do anything in SQL, whether to a Dynamics GP database, or other databases, processes, run scripts, SQL jobs, etc.

Just because a user is assigned the POWERUSER security role in Dynamics GP, while they do have access to everything within the GP application, they do not have access to SQL Server, necessarily unless they’re given permissions on the SQL side, to do any of the processes and/or access things on the SQL Server side like ‘sa’ can.

DYNSA is the only GP login that (other than ‘sa’), by default, is given SQL permissions to go along with its POWERUSER security role permissions. This is why, again by default, only sa and DYNSA can create users in Dynamics GP, because when doing so, you’re actually creating a login on the SQL side, which requires SQL permissions to do.

Our SecurityPlanning.pdf file, found in the Documents directory of the Dynamics GP installs and on the DVD media, goes over alternative ways to give users permissions to do various jobs, such as create new users, deleting users, granting user access, backups and restoring databases, etc.

Thanks all!!

——————————
Derek Albaugh
Sr. Support Engineer
Microsoft
Moorhead MN
——————————
——————————————-

[Mark Polino]

To add to everyone else’s comments, I have some experience with and auditors. Poweruser is not a role that grants permissions to tasks. It is a role that overrides permissions. This important because if you run reports to show who has access to specific items, say who can access vendor maintenance, users with the Poweruser role will not show up. This creates a real problem when auditors test access and find users who are not on the permission list because they have the Poweruser role. 

I’m not a fan of using Poweruser. I can make a case that no one should have it. There is nothing in Poweruser that cannot be explicitly assigned to a user. It’s also dangerous. I’ve seen someone delete their receivables table from within the GP interface because they had Poweruser access and didn’t know what they were doing. By “seen” I mean I was in the room when it happened. 

Since you’re looking for something written, I second Derek’s comment about the Planning for GP Security PDF. I’m also the author of the Microsoft Dynamics GP Security and Audit Field Manual. That’s another option if you need additional written support.

Mark

——————————
Mark Polino
Director of Client Services
Fastpath
Altamonte Springs FL
——————————
——————————————-