|
It is nice that you can do this. We have several problems with that approach.* When a person is dropped, then later another person gets the job of the gone person, what IT is usually told is to setup TOM the same way we used to have HARRY setup, Harry being the person who no longer with the company. ** Obviously if Harry has been deleted, it is not possible to setup Tom the way Harry was setup. * This is if we lucky. More likely DICK is teaching TOM the ropes, and TOM signs on as DICK and IT not even know TOM is on the payroll. ** We have had multiple instances of IT being told that JOE is no longer with the company so please disable JOE password, then come to find out that MARY PETE and someone else have also been using JOE sign on for years. ** This is also how stuff is done with some PC applications. When there was changing of the guard in one dept, it was discovered that critical data the company needed, could only be accessed using the NAME of a person who had not been with the company for many years, accessed by someone signing on as that person name, who had just left us, and no one else knew the password. Which I consider to be better security than I have been accustomed to on Windoze platforms where you can abort boot up and get into MS DOS and circumvent Windoze password file. * The work that HARRY was doing ends up in reports that other people in that department need to do something with. If you delete a user profitle, it also deletes all the objects that they owned, which might not just be reports, but can be more critical stuff that we not want deleted, we want to figure out who to transfer them to.
So a person leaves, and IT gets informed, we disable their access, then we find out what problems need to be resolved, then when new person has the same access as the old person, and the problems resolved, we delete the old access person.
IT also occasionally dumps the list of users that are supported on the AS/400 for HR review to see if there's anyone no longer with us that IT had not been aware of leaving.
We also have to be careful about deleting terminated employees from the HR files because there are reports listing factory work done that show the employee name. Well if the employee # no longer in the employee name file, the reports not structured to include work done by no-such-employee, and there are people who want to see all the work done in a factory time period, irrespective of whether it was done by a now terminated employee.
We also change IT passwords occasionally.End user passwords are never changed, except when something bad happens to their stuff, and they ask me how they can change their password, and I tell them to visit menu PASS or when signing on, note the command at very bottom of sign on screen.
We have employees with same password today on current computer as they had 20 years ago, over life of several platforms, known to numerous co-workers. When the union was on strike, there were people on picket line who knew passwords of many managers, and were engaged in raids into building (e.g. for arson) and even then I was unable to persuade those managers to change their passwords.
Our auditors don't like old profiles out there, so most of the scheduled jobs run under QSYSOPR or something generic we created for the occasion. A terminated user's profile is usually deleted (not just disabled) the next workday. A scheduled job disables them the day after the termination is detected from the (PC-based) HR system.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.
midrange.com
