If XYZ need the authority, why shouldn't he get them directly? This way you will know who is using the resource, not a generic user that you have to investigate who used his access authorities. It is exactly like putting ABC's password on a paper near the keyboard or terminal.
I wouldn't give surrogate to users but applications (like a job scheduler). Itschak -----Original Message----- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Chase, John Sent: Monday, February 12, 2007 4:02 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: RACF Surrogate Authority > -----Original Message----- > From: IBM Mainframe Discussion List On Behalf Of R.S. > > Jacky Bright wrote: > > Hi, > > > > I have 2 TSO Users (ABC and XYZ) > > > > ABC has high level access privileges. > > > > XYZ do not have any such access. > > > > I am trying to submit 1 job from XYZ userid which require access > > privileges from ABC. > > > > In case I define XYZ user as surrogate user for ABC then is that going > > to work. > > > > what implications it will have at system side ? security issue ? > > It depends. > However surrogate means, XYZ can do everything (*) that ABC can. More precisely, "surrogate" in RACF context means that XYZ can submit work using ABC as the user ID. IOW, XYZ must "tell" the system that he is pretending to be ABC. -jc- ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
