Admin Alert: The Right Way To Delete User Profiles, Part 2
August 8, 2012 Timothy Prickett Morgan
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:
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.
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.
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:
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.
At this point, the deletion process is over and the user profile is removed from the system.
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 email@example.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.
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.