I think we're asking the wrong question. These folk just make an ordinary fat fingered typo now and then. If that happens on TSO, the user is hung up but the system runs along fine. Apparently in CICS, the whole shebang goes into a wait. I've seen this for other non-CICS products.
. . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-543-6132 Office ⇐=== NEW robin...@sce.com -----Original Message----- From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On Behalf Of Itschak Mugzach Sent: Monday, July 27, 2020 2:03 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: Keeping TSO users our of CICS CAUTION EXTERNAL EMAIL CICS does not require a CICS segment, so if you do not block the user at the APPL, the default user CICS segment inherented to the user. Still don't understand why the helpdesk users password authentication fails if it works under TSO. ITschak *| **Itschak Mugzach | Director | SecuriTeam Software **|** IronSphere Platform* *|* *Information Security Continuous Monitoring for Z/OS, zLinux and IBM I **| * *|* *Email**: i_mugz...@securiteam.co.il **|* *Mob**: +972 522 986404 **|* *Skype**: ItschakMugzach **|* *Web**: www.Securiteam.co.il **|* On Mon, Jul 27, 2020 at 11:57 PM Clark Morris <cfmt...@uniserve.com> wrote: > [Default] On 27 Jul 2020 13:40:48 -0700, in bit.listserv.ibm-main > stars...@mindspring.com (Lizette Koehler) wrote: > > >First if you have not done so, you might want to join the CICS or > >RACF Lists. > > While I am at least 20 years out of date, it used to be that someone > had to be set up in each CICS region they were allowed to access. So > far as I know access to TSO does not automatically get you access to > CICS and having access to CICS test does not mean access to CICS > production or even CICS test for a different region. > > Clark Morris > > > >I think the IRR profiles can avoid the use of SPECIAL and OPERATIONS, > >but you would need to research that > > > > > >I think the RACF List may be more helpful > > > >CICS http://www.listserv.uga.edu/archives/cics-l.html > >RACF http://www.listserv.uga.edu/archives/racf-l.html > > > > > >Next I think here are IRR profiles that can be used to reset > >passwords. I am not very familiar with it, I think this > > > > > https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zo > s.v2r1 > > >.icha700/icha700_Steps_for_delegating_the_authority_to_reset_password > >s_by_gr > >oup_tree.htm > > > > > >Steps for delegating the authority to reset passwords by group tree > > > >Before you begin: > > > > Make sure the ALTUSER command issuer does not have similar access > > to > the > >IRR.PASSWORD.RESET resource in the FACILITY class. > > Ensure that list-of-groups-checking (SETROPTS GRPLIST) is enabled. > > > >Perform the following steps to limit the authority of a general user > >or group to resume user IDs and reset passwords and password phrases > >based on the scope of a group tree. > > > > Define the following generic profiles in the FACILITY class, if > >not already defined. Doing so ensures that an existing generic > >profile does > not > >inadvertently prevent you from successfully limiting this authority. > > Example: > > > > RDEFINE FACILITY IRR.PASSWORD.RESET.** UACC(NONE) > > RDEFINE FACILITY IRR.PWRESET.** UACC(NONE) > > RDEFINE FACILITY IRR.PWRESET.EXCLUDE.** UACC(READ) > > > > If you use UPDATE or CONTROL access for any IRR.PWRESET profile, > >as described in Table 1, specify the higher level (UPDATE or CONTROL) > >with > the > >UACC operand for the IRR.PWRESET.EXCLUDE.** profile instead of the > >UACC(READ) option shown in this example. > > Define a profile to protect the IRR.PWRESET.TREE.owner resource > >in the FACILITY class, where owner is the group that is at the top of > >a group > tree. > > Example: > > > > RDEFINE FACILITY IRR.PWRESET.TREE.GROUP1 UACC(NONE) > > AUDIT(FAILURES(NONE) SUCCESSES(READ)) > > > > > > > https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zo > s.v2r1 > > >.icha700/icha700_Steps_for_delegating_the_authority_to_reset_the_pass > >word_fo > >r_any_user.htm > > > >Steps for delegating the authority to reset the password for any user > >Perform the following steps to authorize a general user or group to > >use > the > >ALTUSER command to resume a revoked user or reset a user's password > >or password phrase. > > > > Define a profile to protect the IRR.PASSWORD.RESET resource in > >the FACILITY class. > > Example: > > > > RDEFINE FACILITY IRR.PASSWORD.RESET UACC(NONE) > > AUDIT(FAILURES(NONE) SUCCESSES(READ)) > > > > ______________________________________________________________________ > > Authorize the general users or groups. > > Example: > > > > PERMIT IRR.PASSWORD.RESET CLASS(FACILITY) ID(HELPDESK USER19) > >ACCESS(READ) > > > > See Levels of authority for restrictions and details about > >authority based on the access level to IRR.PASSWORD.RESET. > > > > ______________________________________________________________________ > > Activate the FACILITY class if not already active. > > Example: > > > > SETROPTS CLASSACT(FACILITY) > > > > If the FACILITY class is already active and RACLISTed, refresh > >the FACILITY class profiles. > > > > SETROPTS RACLIST(FACILITY) REFRESH > > > > > > ____________________________________________________________________ > > __ > > > >You have now authorized a general user or group to use the ALTUSER > >command to resume the user ID or reset the password or password > >phrase for any > user, > >excluding protected users and users with the SPECIAL, OPERATION, or > AUDITOR > >attribute. > > > > > >-----Original Message----- > >From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On > >Behalf > Of > >McCabe, Ron > >Sent: Monday, July 27, 2020 1:32 PM > >To: IBM-MAIN@LISTSERV.UA.EDU > >Subject: Keeping TSO users our of CICS > > > >Hello IBM Listers, > > > >Got an interesting problem that I would like to know how we can avoid. > Our > >Help Desk users TSO accounts have the SPECIAL ATTRIBUTE so they can > >reset passwords and define new users. These TSO accounts are not > >defined to > CICS > >but every once in awhile one of them will try to login to CICS using > >their TSO account and after messing up their password 3 times the > >system puts > out > >an ICH302D message asking if we want to REVOKE them or let them try > >again (we REVOKE), this message waits for a reply and while it is > >waiting CICS hangs until a reply is given. We thought about defining > >their TSO > accounts > >to CICS but that does not help if they actually do mess up their password. > >We thought we could do it with RACF but RACF doesn't check any > authorization > >until "after" the user successfully signs on so we would still get > >the ICH302D message. > > > >Does anyone else run into this problem? Is there a way we can get > >around this problem? We thought about having MSGTABLE do an > >automated response > but > >there could be times when we don't want to have the user REVOKED. > > > >Thanks, > >Ron McCabe > >Manager of Mainframe/Midrange Systems Mutual of Enumclaw > > > > > >Confidentiality Notice: This e- mail and all attachments may contain > >CONFIDENTIAL information and are meant solely for the intended recipient. > It > >may contain controlled, privileged, or proprietary information that > >is protected under applicable law and shall not be disclosed to any > >unauthorized third party. If you are not the intended recipient, you > >are hereby notified that any unauthorized review, action, disclosure, > >distribution, or reproduction of any information contained in this e- > >mail and any attachments is strictly PROHIBITED. If you received this > >e- mail > in > >error, please reply to the sender immediately stating that this > transmission > >was misdirected, and delete or destroy all electronic and paper > >copies of this e-mail and attachments without disclosing the > >contents. This e- mail does not grant or assign rights of ownership > >in the proprietary subject matter herein, nor shall it be construed > >as a joint venture, partnership, teaming agreement, or any other formal > >business relationship. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
