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

Reply via email to