We're using Vanguard ez/Token, SecurID product. We have a single Firecall userid, that can be "checked out" by any authorized person. Without having that userid assigned its own token/pin I'm not sure how to crack this nut.
Mark Jacobs > Chicklon, Thomas <mailto:thomas.chick...@53.com> > December 8, 2017 at 11:48 AM > 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 > > > Mark Jacobs - Listserv <mailto:mark.jac...@custserv.com> > December 7, 2017 at 3:12 PM > 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 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