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.zos.v2r1 > > >.icha700/icha700_Steps_for_delegating_the_authority_to_reset_passwords_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.zos.v2r1 > > >.icha700/icha700_Steps_for_delegating_the_authority_to_reset_the_password_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 > > ---------------------------------------------------------------------- > 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
