How about appl class? If the user is not authorized to the cics applid, he can't login.
Btw, why (and how) is their password different on cics? If racf recognize they have the special attribute, it seems this is the same racf... ITschak בתאריך יום ב׳, 27 ביולי 2020, 23:40, מאת Lizette Koehler < stars...@mindspring.com>: > 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 > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
