Open Forum

 View Only
  • 1.  Sys Admin Security

    Posted Feb 06, 2019 04:34 PM
    We have new auditors who are asking a familiar question:  How can the financial system admin have back end access to Dynamics GP and be part of the accounting team.  To them, this breaks every separation of duties rule:  If your GP Admin is part of the accounting team instead of IT, how do you split responsibilities with IT and how do you mitigate security risk?  Does your admin do upgrades, repair data, and administer security?  I know the general principals but I'm wondering how GPUG members manage this in practice.

    Lou Spevack
    Systems Accountant | Dynamics Credentialed Professional
    American Council on Education
    Washington DC

  • 2.  RE: Sys Admin Security

    Posted Feb 07, 2019 09:31 AM
    I was in a similar situation.  I'm a CPA and my background is corporate accounting and I slowly moved into a systems role that reported up through the accounting umbrella.  We use FastPath to track changes to key data/configurations and it can also track changes made to the databases outside of the application.  We also use a different software (Change Tracker Pro) for monitoring the files at a server level.  With a strong change management process, we were able to keep the organization as is.  Although I've moved to reporting up through IT, it doesn't change the organization or process of our changes.  Weekly, we have a change meeting where we match our change management tickets (internal process using Zendesk) to the changes found by Change Tracker Pro to be sure that the proper testing/approvals were made by the business side.  Furthermore, FastPath kicks out monthly reports that are routed to the appropriate accounting manager to review any changes made to key data and/or configurations.  Sooooo..... in summary, with the proper change management process in place, the fact that the system admin reports up through accounting shouldn't be an issue.

    Kimberly Lomax
    Manager, Financial Systems
    Wildlight FL

  • 3.  RE: Sys Admin Security

    Posted Feb 07, 2019 09:38 AM
    Hi, @Lou Spevack,

    I've only worked for companies with a small number (< 10) of GP users. Not only do I do Admin tasks, but I'm the go-to guy for Management Reporter, Report Writer, Word templates, refexes, SmartLists, etc. I've also created custom SQL routines to load batches with complicated overhead and finance charge records.

    In small companies, I don't see how separation of duties could be anything other than very broad. There's cross-training for every role since people do take vacations!

    I purchased @Mark Polino's book, "Security and Audit Field Manual," and I intend to use its recommendations as much as feasible. We also have @David Musgrave's GP Power Tools which has simplified the tweaking of Security Tasks.

    But I don't claim that our security is without large holes. E.g., there are a couple users in the higher reaches of the Finance dept. that requested SuperUser capability. It's better than it was when I started a year ago... where everyone was a POWERUSER!


    "Sparkly" Steve Erbach - Green Bay, WI
    Co-Chair, GPUG WI (Green Bay) Chapter

    Excel Webinar List

  • 4.  RE: Sys Admin Security

    Posted Feb 11, 2019 08:32 AM
    As mentioned there is software that helps with this and the tracking of these entries. Rockton also has tools to help with this.
    As Steve had mentioned, you need to be a large organization to have true separation of duties that meets auditors requirements, based on roles.
    As always, you need to have correct accounting controls to manage all system... I will leave that to CPAs with Audit experience.

    Now from a systems and SQL perspective, my area of expertise...

    No Dynamics GP User should have PowerUser status or anything equivalent. (All roles assigned)
    In both Dynamics GP and SQL you need to create different 'users' logins to handle the two different tasks.
    In Dynamics GP, have the normal finance duties assigned to the users actual AD account correlation. Now create a second Dynamics GP user with the different permissions to be used when needed to complete the administration tasks.

    In SQL, you do the same thing. The Dynamics GP users ONLY belong to the DYNGRP. NEVER EVER give them SYSADMIN DBOwner or any other roles.
    If the user needs any other access to SQL, from anything other than Dynamics GP, then create a domain user account for that user with that access.

    By creating and forcing these restrictions, you are enabling a better audit trail, system reporting trail, for these NON regular work duties.

    It is not a true separation, since the same person has access to this, but from the SYSTEM, it is a separation of duties, thus accounting controls can now be applied more easy.

    Kerry Hataley
    CEO & President
    Nanook Software, Inc

  • 5.  RE: Sys Admin Security

    Posted Feb 11, 2019 09:48 AM
    Hi Lou,

    In our company IT creates the users and assigns security but doesn't "set security" - i.e. make changes to tasks or roles. We use FastPath so they don't even log into GP to do this. Technically they use 'sa' to do this, in the FastPath window they left the 'sa' login credentials saved which I would prefer to get rid of and have them use windows auth but haven't made the change yet. That would require they have sysadmin or accessadmin/securityadmin on the right dbs in SQL instead.

    In GP I've don't the following:
    • I've set up the IT desktop installers (2 people usually + a coop student) with a GP login, and NO security. They have company access but no roles inside the company. In SQL they are a sysadmin on their GP login so during install they can launch GP Utilities and have permissions for it to do what's necessary and launch GP to see that it's fine and select a company but then do absolutely nothing but log off.
    • The one guy who traditionally does user setup, I've set up a role in GP "IT USER ADMIN" and that role has access to User Setup, User Access and User Security only. If for some reason he can't use Fastpath or decides to log into GP, he can't see anything else. There is another guy who was involved in setting up security originally (although he won't touch it now that I'm in-house permanently), so as backup, I've set a role up for him that only allows access to security setup ("IT SECURITY ADMIN"). No user assignment side tasks.
    • For myself, I'm currently the one who has too much access (POWERUSER) and the plan for me is to figure out what support non-admin role I might need to play with my regular GP user in terms of day to day Finance support and grant appropriate access and then I have an admin login when I access servers and that login could have more privileges in GP in order to fully support the product like our VAR would, including installs and upgrades. My regular user doesn't need that access so I need to remove it from my day to day login at some point. The challenge is figuring out what I "need" for quick support questions vs. what I really should be logging in with my "admin" hat on instead. I answer so many different things each day it's hard to narrow down where that line is!

    Currently we have one more set of users with POWERUSER that I am working on re-defining security to remove. They had several when I started and I've gradually weaned the users off POWERUSER into their own properly defined role. That simply takes time.

    I hope this helps a bit in how someone else does it? The only time we use our VAR is upgrades since they have some customizations that I don't have access to the code to upgrade myself. Otherwise I usually work with IT but they leave the things like tax updates to me to handle and they just deal with adding users.


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

If you've found this thread useful, dive deeper into User Group community content by role