First if you have not done so, you might want to join the CICS or RACF Lists.
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
