|
||
August 15, 2012 - Vol 2, Issue 15
|
||
|
||
|
Feature Article
Fixing your Restore Inconsistencies in Private AuthoritiesBy Dan Riehl How often have you found yourself bewildered when restoring a production library to a test or backup system only to find that the authorities on the test system don't match the authorities on the production system? I can't tell you the number of times I've received a call from a client trying to figure out why their authorities are not consistent between the two systems. Restoring objects from one system to another and trying to keep all the security-related attributes and authorities intact can be challenging process. There are numerous rules that come into play, depending upon how the objects are saved and how they are restored. IBM made a very nice enhancement to the Save(SAVxxx) and Restore(RSTxxx) commands in IBM i version 5.4 that can ease the pain of trying to get the authorities right on your restored objects. You still need to be aware of the rules and restrictions of saving and restoring objects, but this new support will be the answer to many of your restore difficulties. The ProblemBefore delving into the enhanced support provided in 5.4, let's consider an example of how Save/Restore operations work in relation to object private authorities. The only object authorities that are saved and restored with an object are the object Owner's authority, the *PUBLIC authority, and the Object Primary Group. These authorities are stored within the object and are therefore saved with the object; however, all of an object's private authorities are not stored within the object. They are stored within the user profiles of the users who have a private authority to an object. So, If Joe has an authority of *CHANGE to the PAYROLL library, and Joe is not the owner of the library, Joe's "private authority" is not saved, and thus cannot be restored with the object… It's just gone on the restore side. Prior to the 5.4 enhanced support, these object private authorities were only saved when user profiles were saved, using the Save Security Data (SAVSECDTA) or Save System (SAVSYS) commands. |
|
In This Issue
Quick Links
Thank You! To Our Great Sponsors
Platinum Sponsor |
IBM i Security and Audit ResourcesIBM i Security Videos from SecureMyi.com SecureMyi Newsletter Home and ArchivesSearch Security Site for IBM i and i5/OS IBM i Security Reference - IBM i 6.1 IBM i Security Reference - IBM i 7.1 QAUDJRN Audit Types By AUDLVL 6.1 QAUDJRN Entry Type Record Layout 6.1 RedBook - Security Guide for IBM i 6.1 PCI SSC Data Security Standards |
|
IBM i Security News Bytes
Linoma Announces Outlook 2010 Plugin for GoAnywhere IBM i Security Calendar of Events
|
|
|
|
||
|
||
Security Shorts -
By Dan Riehl I always encourage administrators to use or create a special "owner" profile to own all of our production objects/ For example, instead of the Distribution application programs and files being owned by a conglomeration of programmers and other IT people, the objects should be owned by a special owning profile, like DSTOWNER. DSTOWNER is not a group profile, and it has no password, so it cannot be used to sign on. I also advise that certain system objects that we create, like User Profiles, be owned by QSECOFR. It might requires an extra step to assign the ownership to QSECOFR, but doing so avoids the problem of these objects being owned by IT staff members, who, sadly, come and go. Creating a New UserWhen a new user must be created on your system, it is usually rather straightforward. However, if you have fallen into the trap of assigning object authorities at the user profile level, it becomes much more difficult to create the new user. Let's say that you have a new system administrator and this new user needs to have the same authorities as an existing system administrator. You can easily copy the existing user profile to the new one. The Copy User profile option is available as Option 3 from the WRKUSRPRF(Work with User Profiles) display. But, copying a user profile in this way does not copy the private authorities of the original user. For example, if the existing user owns a collection of libraries or files, that existing user has *ALL authority to those objects. How do we grant *ALL authority to the new user. If the original user has private authorities, or ownership of 50 commands, 10 libraries, 200 files and a few job descriptions, you will need to grant all those same authorities to the new user. IBM has provided the tool to copy these authorities using the command GRTUSRAUT(Grant User Authority). When using the command GRTUSRAUT, make sure you are signed-on as QSECOFR or as an *ALLOBJ user, otherwise, certain objects or authorities may be skipped. Copying the AuthoritiesHere is a command that will copy the private authorities(including those granted through ownership) from OLDUSER to NEWUSER. GRTUSRAUT USER(NEWUSER) REFUSER(OLDUSER) When you run this command, it would be best to submit it to batch, since it may take a log time to run. So use the command SBMJOB CMD(GRTUSRAUT USER(NEWUSER) REFUSER(OLDUSER)) Here is the IBM Documentation on GRTUSRAUT command. |
Sponsored Links
IBM i, iSeries and AS/400
|
|
|
||
Send your IBM i Security Related News and Events! Advertise in SecureMyi.com Security Newsletter Copyright 2012 - SecureMyi.com, all rights reserved SecureMyi.com | St Louis MO 63017 |