OK, got ya, I don't know that's possible, but I'm limited in my experience with MFA, I'm a Top-Secret shop, MFA is supported by TSS I believe, but we're are not actively pursuing it.
sorry can't be more help Carmen Vitullo ----- Original Message ----- From: "Mark Jacobs - Listserv" <mark.jac...@custserv.com> To: IBM-MAIN@LISTSERV.UA.EDU Sent: Thursday, December 7, 2017 2:12:24 PM Subject: Re: Fire-call, emergency RACF userid 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 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
