|
Admin Alert: The Right Way To Delete User Profiles, Part 1
Published: July 25, 2012
by Joe Hertvik
To most people, deleting user profiles on an IBM i partition is an easy process that doesn't warrant much thought. However, your user deletion process can be complicated by several different items, including compliance requirements and special handling needed for user profiles that are critical to system functioning. This issue and next, let's look at some dos and don'ts for profile deletion and outline a procedure for deleting user profiles.
A Common Procedure For Anyone Who Leaves Your Organization
IMHO, the best way to deal with terminated users is to perform the following five steps:
- Know and follow organization specific procedures, particularly if your computer systems must meet compliance requirements for Sarbanes-Oxley (SOX), the Health Insurance Portability and Accountability Act (HIPAA), or Payment Card Industry (PCI) compliance.
- Immediately disable the terminated user's profile.
- Identify the nearest user who will inherit all of the IBM i objects that the soon-to-be terminated user owns (the heir apparent).
- Determine if the user is a critical user, who needs special handling upon termination.
- Wait an agreed upon amount of time before deleting their user profile.
This issue and next, I'll discuss each of these steps in detail, using green screen commands or System i Navigator commands. I'll cover steps one through three today. Next issue, I'll discuss steps four and five. By the time I'm finished, you have an excellent overview of what you can do with user deletion procedures on an IBM i partition.
Step 1: Know and follow company procedures.
If you are subject to any kind of IT compliance standards such as SOX, HIPAA, or PCI, then you probably have additional termination requirements that need to be followed. You may have to keep evidence of when notice was given for user termination, when the user was actually terminated from the system, and you may even have to keep screen shots documenting your actions. Keep your own additional requirements in mind when reviewing or implementing the advice given here and add them to these procedures as you see fit.
Step 2: Immediately disable the terminated user's profile.
As an administrator, you should immediately disable a terminated user profile the minute you know that user has left the company. And disable their password, too. This should be an automatic action for any terminated user. In many organizations, there are just too many ways that users can connect to IBM i partitions both inside and outside the firewall. You don't want to leave open the risk that a disgruntled user will log in and either damage or steal company data.
The mechanics of disabling IBM i profiles and changing their passwords are incredibly simple. Green-screen oriented users can use the following Change User Profile (CHGUSRPRF) command to disable a user profile.
CHGUSRPRF USRPRF(USER_NAME) PASSWORD(*NONE) STATUS(*DISABLED)
This command provides these critical functions when disabling a user profile.
- Through the Status (STATUS) parameter, it disables the profile so that the user cannot sign on to the system again.
- It changes the user profile so that it no longer has a password. User profiles without passwords cannot log on to the system, even when enabled. You need to remove the password in addition to disablement because if the user is accidentally re-enabled for system access, no one will be able to sign on with that user profile.
System i Navigator (also known as Operations Navigator in earlier iSeries Access for Windows versions, or by its old familiar nickname, OpsNav) lets you disable profiles by opening the Users and Groups→All Users node. This provides a list of users on your partition. Highlight and right-click on the user name you want to delete. Select Properties from the pop-up menu that appears. You'll see a User Properties screen that looks like this.
The fields you should change to disable a user are marked with red ovals in this picture. Click on the password dropdown box and select "No password (sign-on not allowed)" to modify the profile so that it cannot sign on. To disable the user from any kind of interactive or remote processing, uncheck the "Enable user for processing" check box. When finished, click on the OK button and the user will not be able to sign on again.
At this point, your user profile will be disabled from most system processing by using either method. The system will, however, still be able to submit batch jobs that run under this user profile (more next issue).
There are two good reasons for first disabling a terminated user profile rather than immediately deleting it. For positions that will be replaced, it's helpful to have the old profile handy as a model to copy when creating its replacement user. Also note that in addition to copying the profile itself, you will also want to copy any third-party configuration settings from the disabled user to the replacement user. It's not enough to just set up a new user with the same user profile settings as the old user it's replacing; it's just as important to set up the replacement user with the same primary application software settings as the terminated user.
Next and I haven't seen it happen too often, sometimes a user resigns and then changes their mind or is lured back to the company. In that case, it's helpful to have their user profile still available for reactivation, at least until an agreed upon period of time elapses (see step 5, next issue).
Step 3: Identify the heir apparent for the terminated user.
Before you can delete a user profile, you need to determine what to do with any IBM i objects that the user owns. This is important because the operating system will not delete any user profile until all its owned objects are either deleted or assigned to a new owner.
To identify if the user owns any objects, you can run the following Work with Object Owner (WRKOBJOWN) command from the green screen.
WRKOBJOWN USRPRF(user_name)
This will show you all the objects the soon-to-be terminated user owns. To look for owned objects in OpsNav, once again open the Users and Groups→All Users node, right-click on the soon-to-be terminated user profile, and select User objects→Scan for owned objects from the pop-up menu that appears. You'll see a Scan for Owned Objects screen that looks something like this.
Clicking on OK on this screen will also show you a listing of all the objects this user profile owns.
If the profile to be deleted owns any objects, you'll need to identify an heir apparent user profile for the terminated user. Most times, this will either be the terminated user's boss or a co-worker who will be picking up that user's duties. At deletion time, you can change the settings on the Delete User Profile (DLTUSRPRF) command or Delete User OpsNav screen to automatically transfer ownership for the user's owned objects to the heir apparent profile. If necessary, determine who the heir apparent user is, find their profile name, and file it with the deletion request.
Next Steps, Next Issue
At this point, you've disabled the user profile from further system use and determined what if anything to do with any objects the soon-to-be terminated user profile owns. Next time, we'll discuss how to deal with critical (ghost) users who are about to be deleted and look at the mechanics of deleting a user profile. See you then.
Follow Me On My Blog, on Twitter, and on LinkedIn
Check out my blog at joehertvik.com, where I focus on computer administration and news (especially IBM i); vendor, marketing, and tech writing news and materials; and whatever else he come across.
You can also follow me on Twitter @JoeHertvik and on LinkedIn.
Joe Hertvik is the owner of Hertvik Business Services, a service company that provides written marketing content and presentation services for the computer industry, including white papers, case studies, and other marketing material. Email Joe for a free quote for any upcoming projects. He also runs a data center for two companies outside Chicago. Joe is a contributing editor for IT Jungle and has written the Admin Alert column since 2002.
 Post this story to del.icio.us
 Post this story to Digg
 Post this story to Slashdot
|
