It happens because racf is a single task. This is why other users can't login until the wtor is replied.
ITschak בתאריך יום ג׳, 28 ביולי 2020, 0:13, מאת Jesse 1 Robinson < jesse1.robin...@sce.com>: > 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 > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
