Admin Alert: The Right Way To Delete User Profiles, Part 2

August 8, 2012 Joe Hertvik

Last issue, I introduced a two-part article discussing techniques for deleting user profiles. Part one focused on prepping a user profile for deletion. In part two this week, I discuss how to determine whether the user is a critical user and what to do about it, and I demonstrate three techniques for deleting users. After reading both articles, you will have a good template for creating an IBM i user deletion procedure in your organization.

The Five Steps Of User Deletion

Last issue, I introduced a template that determined the best way to deal with terminated IBM i 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.

I covered steps 1 through 3 in the first part of this article, which constituted the prep work needed for deleting a user. This week, I’ll finish the template by looking at steps 4 and 5, which are the actual mechanics for deleting a user profile.

Step 4: Determining if the user is a critical user, who needs special handling upon termination.

Some users are more difficult to delete than others. This is because certain user profiles can become so deeply integrated with an IBM i partition that it’s hard to know what will happen when they are deleted. Here are a few examples of critical users that you need to take special care with when removing their user profiles.

A programming manager who is the only one authorized to run certain necessary functions.
An administrator who has set up all automated batch jobs to run under his user profile.
A system operator who’s been around so long that no one is sure what IBM i objects are dependent on his user profile being active on the system.

I call these types of profiles “ghost” users. They don’t live on the system any more, but they haunt the system, and they must be excised before they can be put to rest.

Dead User Walking

You can’t simply delete critical users without first removing their presence from all critical functions they enable on the system. In one shop, I found all the automated batch jobs run under the user profile of one user. If that user is ever deleted without first modifying their scheduling entries, the shop’s batch environment will literally stop working.

To prevent disruptions, many shops leave critical user profiles active on the system until they can review and assign all of the profile’s critical functions to another user. Such a review can take a long time or never occur, which is why you sometimes see disabled ghost users on a system for months or years after they have left the company. It’s not the correct way to handle deleting these users, but it’s one way to keep partitions running without disruption.

So another critical step is to determine whether the user you’re trying to delete is a critical (ghost) user who needs to be carefully removed from the system, if they are removed at all. Here’s my checklist for evaluating and dealing with ghost users.

The user profile should immediately be disabled as discussed last issue to prevent anyone from signing on as that particular user.
Determine if this user is a critical user. A majority of ghost profiles are IT users. This is especially true for administrators or high-level programming staff who frequently set up system functions to run under their profiles. These people are more likely than most to be critical users.
If this isn’t a critical user, go to the next step and delete their user profile.
Examine any critical applications that are keyed to the critical user. Check out any batch jobs that are dependent on running under that specific profile. Critical users can also be referenced in command parameters, in third-party software configurations, or in other unexpected places. They can even serve as group profiles that transfer specific authorities to other users. The key here is to review your system for the extent to which this user is interwoven into processing. Make a list of all functions that are dependent on this user.
Determine which user profile, if any, can take the critical user’s place in performing the functions listed in the previous step. Don’t substitute another employee’s user profile for the critical user, as you will be creating another ghost profile that will be difficult to delete later on, if that user leaves the organization. This means you shouldn’t use the heir apparent user I talked about last week. Don’t use the QSYSOPR, QSECOFR, or any other IBM Q user profile for the service profile, as IBM may change or replace the Q profiles during a system upgrade or technology refresh. You may also have to change the service profile’s library list or other parameters, so you want the service profile user to be its own entity. Your best bet is to use or create a generic service user profile that can live forever on your system and control critical system functions, but isn’t attached to any one organizational user.

Creating And Testing A Service User Profile

Use or create your chosen generic service user profile for critical functions and reassign those functions to that profile. The service profile should not be allowed to sign on to the system (user profile password = *NONE) and as a result, it can be set up to never expire (password expiration interval = *NOMAX). This profile should have all the capabilities of the critical user it is replacing.

Once the service user is created, start integrating it into the system by performing the following steps:

Create and test the service profile on one function that the soon-to-be terminated user profile is currently used for. Transfer the rights/responsibilities for that function to new user. This will ensure that the new profile is fit for service before you roll it out to other functions.
After you ensure the new profile works as a substitute for the terminated user profile, start phasing it into your system. Use the list created above to start replacing the terminated user in its critical functions. Go slow here and just modify a few functions at a time until you run through the whole list.
After you run through the entire dependent functions list, continue on with the next user deletion step. But be on the lookout in case there are other functions the old profile was used for that you may have missed.

Step 5: Wait an agreed upon time before deletion and then delete the profile.

In many shops, there is a process for when to delete a user profile from the system. Your organization’s procedures may call for you to disable the user profile (step 1 from last issue) and then wait 30, 60, 90, or more days before deleting it from the system. So the first task in this step is checking the calendar to make sure that you’re clear to remove this user from the system. Wait any necessary minimum amount of time before deleting the user profile.

After the waiting period expires, run the following Delete User Profile (DLTUSRPRF) command to remove your user.

DLTUSRPRF USRPRF(user_name) OWNOBJOPT(*CHGOWN 
heir_apparent) PGPOPT(*CHGPGP heir_apparent)

Where user_name equals the name of the user profile you’re deleting and heir_apparent is the name of the user profile who will inherit any objects and group ownership that the deleted profile had. If you’re replacing a critical user as defined in step 4, use the name of the service user profile for the heir apparent.

Deleting the user profile this way does the following things.

It transfers ownership for any objects the deleted user owned to the heir_apparent or service user profile. The profile listed in the Owned object option (OWNOBJOPT) parameter becomes the new owner of any objects the deleted user formally owned.
If the deleted user profile is a group profile, it changes the primary group parameter for any user profiles that were pointing to the terminated user to the heir_apparent or service user profile. The profile listed in the Primary group option (PGPOPT) parameter becomes the new primary group for those users.

At this point, the deletion process is over and the user profile is removed from the system.

Automatic Deletion

If you don’t want to manually delete the user profile, you can set up the profile to automatically be deleted on a specific date. You can do this by using the Expiration Schedule in the green-screen Security Tools menu. Simply type in GO SECTOOLS from a command line and you’ll see a screen that looks like this.

(Click graphic to enlarge.)

You can enter an expiration schedule entry that will run a DLTUSRPRF command on the designated date, by using “Option 8 = Change expiration schedule entry” from this screen. The Change Expiration Scd Entry (CHGEXPSCDE) command that appears has all the same parameters as the DLTUSRPRF command, except that it will also allow you to enter an expiration date for the terminated user profile.

(Click graphic to enlarge.)

Enter all the relevant parameters for the user to be terminated, including the expiration date (the date when the system should delete the user), *DELETE in the Action (ACTION) parameter and the same Owned object option (OWNOBJOPT) and Primary group option (PGPOPT) that you put into the DLTUSRPRF command above. When the user’s expiration date arrives, the system will automatically delete the user profile for you and you won’t have to worry about deleting the user on the correct date.

The expiration schedule is a fairly old feature that has been in the operating system for many years. To learn more about how to use the expiration schedule, check out this article on Automatically Disabling or Deleting OS/400 User Profiles.

User Profile Deletion–OpsNav Style

To delete a user profile in System i Navigator (OpsNav), open the Users and Groups→All Users node. This will show a list of all the users on the system. Right-click on the user profile name that you want to delete. Select Delete from the pop-up menu that appears. You’ll see a screen that looks like this.

(Click graphic to enlarge.)

Click on “Transfer objects to another user” to assign the user’s owned objects to another user upon deletion, the same as happens with the DLTUSRPRF command shown above.

As far as I know, there is no equivalent OpsNav functionality to automatically add a user to the expiration schedule as there is with Option 8 of the Security Tools menu listed above. There also isn’t an option to reassign group profile status from the deleted user to the replacement user; so if you need to automatically reassign any attached group profiles, use one of the green screen methods instead.

A Perfect Deletion Process?

This ends my two issue journey into IBM i profile deletion. If you follow this template, you’ll have a good process for how to delete terminated users with minimum system disruption while adhering to organizational needs. If you have any suggestions for how to improve this template, feel free to email me at joe@joehertvik.com, and I may print your ideas in a future column.

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.