How are GP customers "disabling" users?

(0) Share

Report

Posted on by Devin

1,797

How are customers "disabling" users since there is no disable function within GP?

A user is established through the steps of 1) create a user, 2) grant access to a company(ies), and 3) assign a role(s). Disabling a user would involve undoing one and/or more of these steps. Deleting a user would involve undoing all three.

I would argue that a user should never be deleted in GP so that 1) audit can recall who created transactions under the “Jdoe” username and 2) IT doesn't assign the “Jdoe” username to another user and it become impossible to distinguish between the two individuals' transactions.

So, this leaves us with removing the user's assigned role(s) and/or access to company(ies). Is there a best practice out there amongst customers? Thanks!

*This post is locked for comments

I have the same question (0)

All responses (13)

Answers (0)

GoFast 200 on at

Like (0)

Report

Hi Devin,

The best way that we have found for this is by revoking the company access for a user. This is best practice from a security and audit perspective.

We utilize this method in our Config AD application so that when a user is disabled in Active Directory, it is automatically disabled in GP. See the demo of that here: http://www.gofastpath.com/DemoRoom/FastpathConfigADforGP.aspx

Was this reply helpful? Yes No
Sagi88 2,250 on at

Like (0)

Report

Hi Devin.

Some quick work arounds I have used in the past.

First option - change user password to a secure password in GP.

Second option - with SQL in the server logins security you can select the specified user and and goto the databsae acess.

Select the DYNAMICS database remove the DYNGRP from the user's Permit Role for the database.

Hope this helps

Was this reply helpful? Yes No
Victoria Yudin 22,769 on at

Like (0)

Report

Devin,

To add to the answers you've already gotten:

- If you delete a user from GP you will not lose any 'audit trail' as far as what user ID created or posted a transaction. Those are stored in the transaction tables as strings in GP and are not in any way tied to the user list.

- Re-using a GP user ID for a new user is not something I would recommend. I prefer to use the same user IDs in GP as you do for Windows logins, even if there is no integration between them.

Was this reply helpful? Yes No
Devin 1,797 on at

Like (0)

Report

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!

Was this reply helpful? Yes No
Richard Whaley 25,195 on at

Like (0)

Report

A "Disable" function, while it would be nice, is broad. It would disable the user from all companies. (Hey, why don't you just remove company access for the user?) OK, I'm having a wacky day, yes that was suggested and is the best option. Plus, it allows you to keep information for audits and potentially to reinstate the employee.

Be careful deleting the user. I have not tested this in 10 or 2010 but in prior versions if you deleted user FRED (even after wiping out access, etc) and re created a new user ID FRED for a different FRED, the new fred inherited all of the short cuts of the old Fred. Imagine the surprise if the old Fred was in accounting and the new Fred is in shipping!

Was this reply helpful? Yes No
MG-16101311-0 26,225 on at

Like (0)

Report

Richard has a good point, because removing a user's access from a company in V10 and V2010 just got a whole lot better since the security is now role based. So in theory, as long as a user belongs to a security role (security class in versions prior to v10) he/she should not loose the access to objects that they had access to prior to being removed access from the company.

Was this reply helpful? Yes No
Imtiaz Ahmed - Axone 45 on at

Like (0)

Report

If you set up a user with "no access rights", you can copy that user over to an existing user in GP 2010 using the new copy function.

Was this reply helpful? Yes No
MG-16101311-0 26,225 on at

Like (0)

Report

As I said before, if your users are assigned to specific roles, there is no need to copy a user security, even in 2010. The purpose of roles and tasks is to preserve security settings.

Was this reply helpful? Yes No
L Vail 65,271 on at

Like (0)

Report

Just thought I would add my vote.

I'm for disabling user access to the databases. Retains the user information and is easy. I like easy. Oh, and it requires no additional purchase.

Kind regards,

Leslie

Was this reply helpful? Yes No
Devin 1,797 on at

Like (0)

Report

Mariano, should removing company access from a user, then reinstating that same company access also restore their previous role(s)? In my experimentation I found that the user's previous roles are lost when the company access is reinstated.

Was this reply helpful? Yes No