With Halloween upon us I wanted to tackle one of the scarier areas of Microsoft Dynamics GP – security. What better way to do that than with a look at 5 myths and legends of GP security.
1. GP is insecure because the Admin password isn’t encrypted.
This myth made the rounds a few years back and it’s as false as those bigfoot sightings in Washington state. The admin password isn’t encrypted, it’s merely obscured in the database, but the admin password is a secondary security measure designed as a hedge in cases where you might have given someone too much security access. It’s not a primary security item. If the user can’t get to a window, the admin password never comes into play and if a user is so deep in SQL that they could figure out the Admin password, it’s too late for you anyway.
2. You must be ‘sa’ to add users to GP.
This legend is like the walking dead. It’s everywhere. You don’t need to be ‘sa’ to add users or do much beyond install GP. All you need to do is add a user to the SYSADMIN security role in SQL and give them the appropriate permission in GP. The folks at Fastpath have a fantastic write up around this.
3. You must be ‘sa’ to use the Professional Service Tools Library (PSTL).
Like the myth around adding users, this no more than swirling mists and shadows. Most of the tools in the GP 2010 version and all of the PSTL tools in GP 2013 don’t require the ‘sa’ user. Again some tools require the GP user to be a member of the SYSADMIN role in SQL.
4. Adding GP users to the SYSADMIN role in SQL gives them full control over the SQL server.
Assigning a SYSADMIN role to GP users is a headless horseman that continues to needlessly haunt administrators. The GP login is encrypted. It can only be used to access GP. Adding the SYSADMIN role to a GP login does not… click here to read the rest of the article