At my former customer, we created several RACF groups. To name a few: LBSYST to control LOGONBY to various users by system programmers LBOPER for the operators' group SYSALL to permit the system programmers to link to most MDISKs When there is a new system programmer: RAC CONNECT theNewGuy GROUP(SYSALL) SPECIAL RAC CONNECT theNewGuy GROUP(LBSYST) SPECIAL For a new server: RAC RDEFINE SURROGAT LOGONBY.server RAC PERMIT LOGONBY.server CLASS(SURROGAT) ID(LBSYST) ACCESS(ALTER) For a new system SW minidisk: RAC RDEFINE VMMDISK xxxxxx.vvvv RAC PERMIT xxxxx.vvvv CLAS(VMMDISK) ID(SYSALL) ACCESS(ALTER)
In general: work with groups, and give permissions to groups, not to individual people. 2011/3/9 Richard Troth <vmcow...@gmail.com> > You've gotten several excellent responses along the common theme: "logon > by". > > I like to translate VM concepts into Unix/Linux/POSIX concepts for the > sake of your peers. Think "sudo". If your auditors fear that word > (they should not), then remind them that you have RACF in place, so > z/VM will only do this under control of the security tool. (It *can* > do logon by w/o RACF, but config is different.) > > In Unix/Linux land, many admins increasingly require: sign on with > your own credentials, then 'sudo' as needed. It's good hygiene. You > get a better audit trail and yet can still do all the work you need > to. The difference on z/VM is that you're using virtual machines > instead of just processes, so you have to do it from the logon screen > ... > > logon maint by wvogtman > > Ahhh... Enjoy! > > -- R; <>< > Rick Troth > Velocity Software > http://www.velocitysoftware.com/ > > > > > > > > > On Wed, Mar 9, 2011 at 11:28, Vogtmann, Wallace B <wvogt...@tcfbank.com> > wrote: > > We're new to zVM. Have the system operational with standard IBM supplied > > User/Guest definitions. For example, we've implemented RACF, DIRMAINT, > > & PERF TK (soon Omegamon XE). > > > > Our security folks don't really like us logging in as MAINT, TCPMAINT, > > RACMAINT, etc. to do our changes - can't really tell who is doing what. > > Plus it's hard to have good/secure passwords when need to have multiple > > real users login to multiple guests, etc. > > > > Is there any examples of what would be good definitions for (1) standard > > system programmer guest accounts and (2) standard service machines? What > > RIGHTS and ACCESS definitions should be standard. We only plan on running > > Linux guests and standard IBM/3rd party tools, so just need a few > > Users/Guests > > that have the appropriate access for SysProg support, etc. > > > > Basically, we have the system in and operational, but NOW how should we > > REALLY > > have it setup to run/manage it securely and effectively. Any RedBooks? > > I've looked, but don't see any that fit the bill. > > > > Thx > > - Wally Vogtmann > > - Technical Services > > - wvogt...@tcfbank.com > > ----------------------------Disclaimer---------------------------- > > This email may contain privileged and/or confidential information that > > is intended solely for the use of the addressee. If you are not the > > intended recipient, you are strictly prohibited from disclosing, copying, > > distributing or using any of the information contained in the > transmission. > > If you received this communication in error, please contact the sender > > (“Company”) immediately and destroy the material in its entirety, > > including all electronic and hard copies. > > > > This communication may contain nonpublic personal information about > > consumers which is subject to restrictions under the Gramm-Leach-Bliley > > Act and the Sarbanes-Oxley Act. You may not directly or indirectly reuse > > or disclose such nonpublic personal information for any purpose other > than > > to provide the services for which you are receiving the information. > > > > There are risks associated with the use of electronic transmission. The > > sender of this information does not control the method of transmittal or > > any service providers and the sender assumes no duty, liability, or > > obligation for the security, receipt, or any third party interception of > > this transmission. > > > > The Company reserves the right to amend statements made herein in the > event > > of a mistake. Unless expressly stated herein to the contrary, only > agreements > > in writing signed by an authorized officer of the Company may be enforced > > against it. > > > -- Kris Buelens, IBM Belgium, VM customer support
