NTAC:3NS-20 Our people are also working with the vendor (same vendor) to get Reflections working so that logon's can occur automatically. For now have a workaround and can log in using Reflections manually. What will really complicate matters is that all of the systems programmers have multiple logonids to log on to multiple systems simultaneously. Management is not going to like the additional troubleshooting time that will be incurred if we have to go check out an ID for each system we want to log on to.
-----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Steve Sent: Wednesday, November 23, 2016 9:09 AM To: [email protected] Subject: Re: Mainframe systems programmer ID 'vaulting' Once we have CyberArk being a useful tool, all daily work will be done with TN3270 under CyberArk. That will not happen for a while but it is coming. Welcome to how the FED is going to work and you MUST have a CAC/PIV to even get through the firewalls Steve Beaver ------------------------------------------------------------------------ -------- This electronic mail (including any attachments) may contain information that is privileged, confidential, and/or otherwise protected from disclosure to anyone other than its intended recipient(s). Any dissemination or use of this electronic email or its contents (including any attachments) by persons other than the intended recipient(s) is strictly prohibited. If you have received this message in error, please notify us immediately by reply email so that we may correct our internal records. Please then delete the original message (including any attachments) in its entirety. Thank you -----Original Message----- From: "James Peddycord" <[email protected]> Sent: Wednesday, November 23, 2016 10:03am To: [email protected] Subject: Re: Mainframe systems programmer ID 'vaulting' NTAC:3NS-20 We have a FIRECALL process now, but it's automated. The vaulting process has taken the place of this FIRECALL process for most applications teams. The systems programmers don't need to get a FIRECALL ID to update SYS1 datasets. We only need them when working with datasets that we don't ordinarily have access to, such as the datasets that come in a service pack that have HLQs that we don't have dataset rules for. We are currently vaulting a pool of logonids with god-like power for systems programmers to check out. When this is complete we will retire our old FIRECALL process. It's the next step, where our daily use TSO IDs may be vaulted, that scares us. Jim -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Lester, Bob Sent: Tuesday, November 22, 2016 4:04 PM To: [email protected] Subject: Re: Mainframe systems programmer ID 'vaulting' For a while, about 15 years ago, we had "firecall" IDs. When you logged in, it prompted you for information that, in turn, updated RACF with Name, expiration, etc. These IDs were kept in paper form, in the Data Center Manager's office. Of course, you had to jump thru the flaming hoops of Change Management first! BobL -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Charles Mills Sent: Tuesday, November 22, 2016 2:25 PM To: [email protected] Subject: Re: Mainframe systems programmer ID 'vaulting' [ EXTERNAL ] Isn't this a violation of PCI DSS? "10.1 Implement audit trails to link all access to system components to each individual user." Charles -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Bigendian Smalls Sent: Tuesday, November 22, 2016 7:37 PM To: [email protected] Subject: Re: Mainframe systems programmer ID 'vaulting' This is something I hadn't heard much about, but a couple questions come to mind - for anyone who has thought about or implemented this: 1) If you have a pool of IDs, then are you losing granularity with which you might want to assign privelages? Meaning you now have to have IDs that have exactly the same permissions - if they are user-agnostic (among some class of users obviously, like DEVs or SYSPROGs or whatever) - Seems like that is back to the old, "Create a new id. What perms to give him? Dunno, just build it like Chad's, they have the same job." Which has kind of gone out of style for obvious reasons (though still prevelant in practice). ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN This e-mail transmission may contain information that is proprietary, privileged and/or confidential and is intended exclusively for the person(s) to whom it is addressed. Any use, copying, retention or disclosure by any person other than the intended recipient or the intended recipient's designees is strictly prohibited. If you are not the intended recipient or their designee, please notify the sender immediately by return e-mail and delete all copies. OppenheimerFunds may, at its sole discretion, monitor, review, retain and/or disclose the content of all email communications. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
