[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
