Once you've got your system backed up, including all of the security information, what's the best way to make sure that all of that security information is restored correctly when you have to do a full system restore? Missing something or getting things in the wrong sequence could result in your objects being restored without the security configuration that you want.
First, you will need to plan the sequence of events in your restore operation. For security to come out right, you should always restore your saved user profiles first. The second task is then to restore the objects to your system. Lastly, once the profiles and objects have all been restored, you should restore the private authorities to objects.
Let's take a look at how to accomplish each of these steps in a way the makes certain that your security settings are all preserved. As a safeguard, make sure you have access to the password for the QSECOFR profile on the system being restored. You should have access to the current password and the password being restored. If you have any serious security issues during the restore, you may have to logon as QSECOFR as a recovery option, so having access to these passwords may become critical.
First, to restore your saved user profiles, use the Restore User Profiles (RSTUSRPRF) command. If you are restoring all user profiles, you should be aware that all settings for each profile will be based on the saved version of that profile. If any changes have been made to a profile and you are restoring to the same system, those changes will be lost. Also, make sure that the user profile being used to do the restore has both all object (*ALLOBJ) and security administrator (*SECADM) special authorities. Otherwise, any profiles being restored with *ALLOBJ special authority could have that authority stripped during the profile restore operation. This will not affect critical IBM Q profiles, in case you're worried.
Once your user profiles are successfully restored, the next step is to get your objects restored. You can use any of the following commands to restore objects on your system:
Restore Library (RSTLIB)
Restore Object (RSTOBJ)
Restore Configuration (RSTCFG)
Restore Object (RST) - for objects in the IFS
Restore Document Lib Object (RSTDLO) - for objects in shared folders (QDLS)
When restoring objects, be careful how you use the "Allow object differences" (ALWOBJDIF) parameter. If you attempt to restore an object that already exists on the system and the object being restored is owned by a different profile than that being restored, the allow object differences command setting of *NONE will result in the object not being restored. If you use a value of *ALL, then the object will be restored and the system owner will be preserved.
Also, you need to be aware that there are special considerations for public authority and authorization list values during object restores. Generally, if an object is being restored that already exists on the system; the current object settings are preserved rather than applying those from the saved object. For objects secured by authorization lists, the ALWOBJDIF parameter can result in objects not being restored when there is a difference between the current value and that being restored. There is a thorough discussion of what is restored and not restored in the Security Reference Manual, Chapter 8. Check on the issues of private authorities, object auditing, authority holders and more for these considerations.
To restore authorities, it is recommended that you run the Restore Authority (RSTAUT) command after all objects have been restored. This will rebuild the object authorities in the user profiles. Your restore will not be complete until this step is done.
---------------------------
About the author: Rich Loeber is president of Kisco Information Systems Inc. in Saranac Lake, N.Y. The company is a provider of various security products for the iSeries market.
