Microsoft Dynamics GP System Administrator: Should You Separate Accounting Controls and Duties?

[Ed. - this story has been updated to reflect Microsoft's guidance on security and administration for Microsoft Dynamics GP]

Over the years, we've had questions from larger clients about the Microsoft SQL "SA" (System Administrator) user.  The SA users, or other users attributed with system administration capabilities, are POWERUSERS inside SQL Enterprise, even to the point of enabling the editing of tables. As Microsoft's security planning guide for Dynamics GP (last updated in 2007) explains, "any user who is assigned to the POWERUSER security role will have access to everything in Microsoft Dynamics GP, with the exception of private lists."¹  That means POWERUSERS, usually SA barring other changes to user security, have access or can grant themselves access to all tables and operations in Dynamics GP.  Certain operations can only be performed by POWERUSERS, per the listing below.

DYNSA is created by Dynamics Utilities and assigned to the POWERUSER security role during the initial installation of Dynamics GP and set as the "db_owner" of the Dynamics and company databases.  If that ownership is changed prior to or during upgrades, the upgrades will fail.  As Microsoft's security documentation explains, "[i]f different owners are assigned, complications can arise when deleting user accounts and granting access to companies."²

Auditors point out that the broad access privileges of administrators like an SA user must be carefully managed and tracked. One all-powerful user with no accountability to auditors is unacceptable in view of accounting controls and separation of duties. With Dynamics GP, the accounting department must take charge of the system and invoke the typical auditing of the ERP software: balancing, testing, reconciling, and verification with outside sources.

Microsoft Dynamics GP's module Audit Trails sets up a separate SQL ...