Re: Re: How are GP customers "disabling" users?
Thank you for your replies! Ideally, GP would have an "inactive" status and would allow us to retain who the user was (beyond "Jdoe" transactions), what companies he had access to, and what roles were assigned to him within each company. There would also be a way to quickly determine whether a SQL level user corresponded to a GP user and whether the GP user tied to the SQL user is active or inactive. (In a perfect world we would also have a history of all changes to this security structure.)
@GoFast - thank you for the link. I'd never seen your products before.
@Sagi88 - it would be laborious to produce sufficient documentation to show that a password was changed after a user was terminated. I'd never thought of removing the DYNGRP role from the DYNAMICS database for the user. I experimented with it and it does appear to block a user from logging in. Unfortunately, the user still appears to be an active user in the application's security reports.
@Victoria - yes, it is correct that the user record is disconnected from the user transaction history and that the transaction history would be retained when the user record is deleted but there would be no descriptive record of who "Jdoe" was in the system. This would be especially bad if GP user ids were being reused on new individuals and another individual processed transactions under the same user id.
We went live with GP just a few months ago. We have based our GP user ids on our Windows network ids. I built a Help Desk security role and was writing a security manual for them when I was informed by our network admins that in the past they have recycled network ids of terminated users. (Hopefully, this will be discontinued in the future.)
In my previous postition as an IT auditor, GP was always interesting to audit because of all its caveats. Documentation had to be located describing how GP has SQL level users, the users cannot be logged into, their passwords are encrypted, and the password requirements are enforced by the domain/SQL Server. The GP SQL level users had to be separated from the non-GP SQL level users, the GP SQL level users had to be reconciled to the GP users, and all SQL level users and permissions had to be documented and approved by the client (who was generally oblivious to GP's technical workings). And that was just for ids/passwords in the database!
Share
Report
1,797
All responses (
Answers (
