Not mentioned yet. If using RACF, when you define the user as LOGONBY, it can by default no longer be logged on to with its own password (what is normally what you'd want). But, with an extra command you can restore that possibility: 1. Define VMUTIL as LOGONBY RAC RDEFINE SURROGAT LOGONBY.VMUTIL UACC(NONE) 2. Reset the PERMIT RACF created for the command issuer RAC PERMIT LOGONBY.VMUTIL CLASS(SURROGAT) RESET 3. Allow users/groups to use this LOGONBY to VMUTIL RAC PERMIT LOGONBY.VMUTIL CLASS(SURROGAT) ID(user/group) ACCESS(READ) 4. (optional) Make it possible to logon to VMUTIL with its own password RAC PERMIT LOGONBY.VMUTIL CLASS(SURROGAT) ID(VMUTIL) ACCESS(ALTER)
I never set tis up for a user like VMUTIL, but only to be able to logon to my colleague's userid with my password when he was on vacation (and a alike for my user when I was on vacation). 2008/9/23 Graves Nora E <[EMAIL PROTECTED]> > > And it makes it easy to revoke privileges from a user: just remove the > LOGONBY authority. This is handy in an environment where roles change > frequently. And if the person leaves or retires, deleting the User ID > takes care of all access, without scrambling to remember which > seldom-used accounts that the person may have used occasionally. > > > Nora Graves > > -----Original Message----- > From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On > Behalf Of David Boyes > Sent: Tuesday, September 23, 2008 8:35 AM > To: IBMVM@LISTSERV.UARK.EDU > Subject: Re: LOGONBY > > > So the only thing you are buying here is that you keep TCPMAINT > password > > secret is that the whole idea behind LOGOnBY? So then you only add > > certain user ids to do LOGONBY for this user id correct? > > Think of it more as a role: you are assuming the role of TCPMAINT, using > your own login credentials to validate your claim to the role. > > The idea is minimum privilege; shared ids should not be directly logged > into, because you lose the audit trail of who did what. You give > individual ids minimum privilege (essentially with the combination of > LOGINBY and PROP, there's rarely a real reason for any individual id to > have more than class G), and they authenticate to the shared ID when > they need to do something more powerful, or an extended string of things > that require privileges or access to files w/o having to jump through a > lot of maintenance-intensive hoops. -- Kris Buelens, IBM Belgium, VM customer support
