What are you using for MFA? CA's relatively new Advanced Authentication Mainframe product will let you map a Top Secret user ID to a different ID for RSA authorization. I used this set up for initial testing of the product- log on to the mainframe using a test ID that is mapped to my real ID's RSA pin and token.
If you can do this, seems you can have a set of fire-call IDs that all map to the secret pin and token that are both sitting in the safe. After use, Info Sec changes the pin and the new pin and token go back into the safe. Tom Chicklon -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Mark Jacobs - Listserv Sent: Thursday, December 07, 2017 3:12 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Fire-call, emergency RACF userid **CAUTION EXTERNAL EMAIL** **DO NOT open attachments or click on links from unknown senders or unexpected emails** The way our MFA solution works is that we associate the RACF userid to an Active Directory userid, and use our existing RSA SecureID Token infrastructure as the second authentication factor. I'm not seeing how I can tie the shared userid to a single AD Userid/RSA Token. Mark Jacobs > Carmen Vitullo <mailto:cvitu...@hughes.net> December 7, 2017 at 2:58 > PM Hey Mark, the last two places I worked we had fire-call ID's that > were 'suspended' (inactive) and after each use (DR) mostly ,secadmin > would change the password, store the password in an envelope on a lock > box in the computer room, this was before MFA, only MFA experience we > have is windows, LAN ID's I suspect with MFA, you don't need to > suspend the ID, since you'd need a password and a PIN to be valid? > > > > > > > Carmen Vitullo > > ----- Original Message ----- > > From: "Mark Jacobs - Listserv" <mark.jac...@custserv.com> > To: IBM-MAIN@LISTSERV.UA.EDU > Sent: Thursday, December 7, 2017 1:37:43 PM > Subject: Fire-call, emergency RACF userid > > We have an emergency use userid with it's password "locked in a safe", > which can be used by authorized people when/if needed. How do other > organizations better control something like this? I'm asking since > we're implementing MFA for "special" userids, and I don't know how to > fit this shared userid into the MFA framework. > -- > > Mark Jacobs > Time Customer Service > Global Technology Services > > The standard you walk past is the standard you accept. > Lt. Gen. David Morrison > > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, send > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, send > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > > Please be alert for any emails that may ask you for login information > or directs you to login via a link. If you believe this message is a > phish or aren't sure whether this message is trustworthy, please send > the original message as an attachment to 'phish...@timeinc.com'. > > Mark Jacobs - Listserv <mailto:mark.jac...@custserv.com> December 7, > 2017 at 2:37 PM We have an emergency use userid with it's password > "locked in a safe", which can be used by authorized people when/if > needed. How do other organizations better control something like this? > I'm asking since we're implementing MFA for "special" userids, and I > don't know how to fit this shared userid into the MFA framework. -- Mark Jacobs Time Customer Service Global Technology Services The standard you walk past is the standard you accept. Lt. Gen. David Morrison ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN **CAUTION EXTERNAL EMAIL** **DO NOT open attachments or click on links from unknown senders or unexpected emails** This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
