I had the luxury of having the password expiration time set to match the existing MVS times. The removal of expired users was triggered by a once a year userid reconcilliation. But still lots of expired userids were allowed to remain. The threat of having to pay for disk space never materialized. One tactic that encouraged the reconcilliation staff to remove more expired userids is an automation of the PURGE process where I archived the target userid's directory entry, minidisks, OfficeVision mailbox and calendars. Being able to restore a userid within a business day gave them more freedom to purge userids when the owner did not know when they might possibly need it again.
/Tom Kern On Tue, 3 Jan 2006 00:08:51 -0800, Richard Schuh <[EMAIL PROTECTED]> wrote: > ...snipped... >The question was more to the point of idle userids - idle in the sense >that they have not logged on for some period of time. How long should >they be left in a condition that they can log on? How long after that >should they be kept available so that they can be reinstated? What about >those ids belonging to someone on long term leave? Are there exceptions >for them? An example of this latter would be a person who will be on >medical leave for several months but will be returning. He will be >returning to the same group as before, and resuming most of his former >responsibilities. Should his ids be held in limbo until he gets back? > >How to handle users who terminate their relationship with the company is >another aspect; one about which I have struggled for years to get some >reasonable policies and procedures. We are finally making some headway. >It the past, there was an unwritten policy that the people responsible >for overall systems administration were not allowed to be notified when >a person left. Then, the InfoSec people would do 1 of 3 things - they >would put the person's ids on hold, they would delete them, or they >would do nothing with them. Sometimes, if the person had more than one >id, it would be a combination of the 3. I have finally convinced them >that their ways actually present security exposures, are misguided, and >need overhaul. They never took into account that (1) the data on the >user's disks was company property and might be needed by their project >or work group, (2) the user may have authorizations for things outside >the realm of the ESM, (3) there must be some method of preventing the >reissue of an id as long as there is data in the backup/archive system >belonging to that id. We are making headway in that area but still have >details to work out. >=========================================================================
