Dont Rely on Microsoft Dynamics GP's Secondary Controls

During my time as a consultant, and even as a controller, I’d long been a fan of making reporting as broadly available as possible. This included granting users broad access to data, with Payroll as an obvious exception. The benefits to self-service reporting, dashboards, and analytics are so great, I believed, that limiting the ability to report on company data felt like limiting the organization’s potential. Indeed, most arguments around reporting boiled down to selecting the best tool for a specific job, not worrying what data should be made available.

But as I get older and spend more time with security, I’m changing my mind, especially with Microsoft Dynamics GP. The problem is that Dynamics GP uses shared functional passwords for certain critical accounting operations and these passwords are stored in plain text in SQL tables. More importantly, some of these functional passwords are used by organizations as primary controls. GP’s functional passwords are insecure enough that is hard to make a case to rely on them.

For example, many organizations grant broad access to post GL transactions and then require a password to post a GL batch as a control. Not only is that password shared (everyone uses the same approval password), it stored in the SY2300 table in plain text and it may be the only control in place within the posting process to prevent posting GL transactions. Frankly, that feels woefully inadequate to prevent fraud and manipulation.

GP’s secondary security controls stand in stark contrast to the software’s primary security controls – user and role-based permissions – which are very secure when setup correctly. GP ...