By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
But, have you given thought to how your security policies are stored on your system and how they figure into your backup process? If not, you might be in for a rude awakening when you need to restore your system following a catastrophic system loss. Let's take a look at how the various pieces of your security implementation are stored on your System i processor. A future tip will then look at how your can make sure that your security setup can be restored successfully.
Your security configuration is stored in three different places on your System i server. You should be familiar with these storage locations and how they relate to your security implementation.
Some security information is stored with individual objects. These include things such as public authority settings, who owns the object, what the owner's authority to the object is, group authorities to the object, the name of any authorization list that applies to the object along with private authority information.
In addition to the security information stored with each individual object, there is also a wealth of security information stored with your user profiles. This information includes user profile attributes, the profile's UID (User Identification Number) and GID (Group Identification Number), private authority information to objects, object ownership information, group profile information, profile auditing information and information about registered functions for the profile.
Lastly, there is security information stored with existing authorization lists on your system. This includes a list of objects secured by the list along with other normal authority information to be considered for objects secured by the list.
When you save the objects on your system, only part of the security information is getting backed up to tape. In order to get a complete backup of your system, including all of the current security information, you must not only save the objects, you must also save the security information. This requires using the Save Security Data (SAVSECDTA) command. This command will backup the user profiles, authorization lists and any authority holders that you have in your security configuration. Only when both the objects and the associated security data for your system are saved will you get a full backup of your security implementation.
There are some restrictions on the use of the SAVSECDTA command, so if you introduce it into your save/restore plan now, make sure that you understand those restrictions and accommodate them. Of special concern is the PRECHK parameter and the possibility that it could abnormally terminate your backup operation. See the HELP text associated with the SAVSECDTA command for more information.
If you have specific questions about this topic, e-mail me at firstname.lastname@example.org. All e-mail messages will be answered.
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.