Re: Fire-call, emergency RACF userid
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" > 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
Re: Fire-call, emergency RACF userid
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" > 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
Re: Fire-call, emergency RACF userid
> On Dec 7, 2017, at 1:37 PM, Mark Jacobs - Listserv > wrote: > > 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, AT one place I worked the sealed ID's were in the DC supervisor’s office. It was a joke every month or two they would find a need for them. NOT one was reasonable. I was on the group that did a day after run through and it was a joke, but we couldn’t figure a way around it. As long as the DC looked the other way it was a risk that management went along with. If we had had a auditor that knew what he/she was doing we could have cut it way back. You really really need an auditor that goes after violations like a mad dog, IMO. Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Fire-call, emergency RACF userid
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" 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" > 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
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" > 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
Re: Fire-call, emergency RACF userid
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" 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
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