Random Thoughts from the GP Security Manual

Views (392)

mpolino

Like(0)

Report

I’m re-reading the Microsoft Dynamics GP Planning for Security manual as I work on a GP security book. It’s a great read. I laughed, I cried, and I pulled out some quotes that really stood out for me.

“Single sign-on provides two main security benefits. For a user, the use of a single password or smart card reduces confusion and improves work efficiency. For administrators, the amount of administrative support required for domain users is reduced, because the administrator needs to manage only one account per user.” Page 16Except of course that GP doesn’t offer Windows-based single sign on. Can you say Fastpath Config AD? Anyone? Bueller?

“When the system administrator (“sa”) logs into Microsoft Dynamics GP Utilities, the application checks to see if the password for DYNSA is either <blank> or ACCESS. If either of these is true, the user must enter a new DYNSA password before continuing with the upgrade.” Page 31, context Upgrading from a new releaseThis made me laugh. As an old consultant “access” was a convenient password that you could type with one hand. Apparently it was so convenient that they had to hard code a check for it.
“User accounts must be created within the Microsoft Dynamics GP application to ensure that security is applied to all Microsoft Dynamics GP windows and reports. Microsoft Dynamics GP encrypts the password during the user creation process before it is passed to Microsoft SQL Server. For example, if a user account is created with a password of ‘1234,’ before the user account is created in the Microsoft SQL Server, that password passes through the Microsoft Dynamics GP encryption process and is changed to something like ‘ABCD.’ When this happens, only the Microsoft Dynamics GP application and other applications that use the Microsoft Dynamics GP encryption process have the ability to translate the user’s password before sending it to Microsoft SQL Server.

If a user tries to access the Microsoft SQL Server from outside the Microsoft Dynamics GP application, the attempt to log in will be denied because the passwords will not match. For improved security, Microsoft Dynamics GP does not allow a user to change their password to blank or unencrypted.” Page 33

This is really frustrating to explain to DBA’s and network security managers in the context of giving non-sa users rights to add users in GP as explained on Page 35. Chapter 7 (starting on Page 35) is really the holy grail for managing users without using ‘sa’.