How to set up ACF2 user to change PASSWORD, PSWD-VIO, and all other fields in the ACF2 logonid record

Products

• ACF2
• ACF2 - z/OS
• ACF2 - MISC

Issue/Introduction

How can a help desk user be setup to unsuspend users and change PASSWORD, PSWD-VIO, and any other logonid fields in ACF2?

 

 

   

Resolution

Beginning with R15.0, ACF2 was enhanced to allow end users who do not have any special logonid privileges to issue the ACF CHANGE subcommand in TSO/E or batch (including ACFBATCH) to change certain user related fields if they have the proper access to the ACFCMD.USER.fieldname resource in the CASECAUT class.

An end user can only change user related fields for other end users.  An end user is a user who does not have SECURITY, ACCOUNT, AUDIT, LEADER or CONSULT which are special ACF2 logonid privileges.  This is described in the ACF2 documentation section Review Logonid Privileges.

Here is a list of lid fields that can be changed and the resource name that is validated:

PASSWORD       ACFCMD.USER.PASSWORD
PWPHRASE       ACFCMD.USER.PWPHRASE
PWP-VIO        ACFCMD.USER.PWP-VIO
PSWD-VIO       ACFCMD.USER.PSWD-VIO
PSWDCVIO       ACFCMD.USER.PSWDCVIO
KERB-VIO       ACFCMD.USER.KERB-VIO
CANCEL         ACFCMD.USER.CANCEL
SUSPEND        ACFCMD.USER.SUSPEND

To implement the CASECAUT validations: 

1. Add AUT to the INFODIR:
   
   TSO ACF
   SET CONTROL(GSO)
   CHANGE INFODIR TYPES(R-RAUT) ADD
   F ACF2,REFRESH(INFODIR)
   
   
2. Write the resource rules:
   
   $KEY(ACFCMD) TYPE(AUT)
    USER.PASSWORD UID(uid string of user) ALLOW
    USER.PSWD-VIO UID(uid string of user) ALLOW
   
   
3. After you compile the records, load the new rules into storage:
   
   F ACF2,REBUILD(AUT)      

Note that a user with authority to the CASECAUT resource can only change other users at the same level or lower which means that a user with ACCOUNT authority can only modify users with ACCOUNT or lesser authority (e.g.  ACCOUNT, AUDIT, LEADER, or CONSULT will be needed).

There should always be at least two un-scoped security administrators defined in an ACF2 database so that there is always someone available that can change an un-scoped security administrator if needed. 

Additional Information

New PTFs changed this process.

SO09757    Release: 16.0

 PROBLEM DESCRIPTION:
 Prior to fix SO05978, we accidently allowed logonids with
 SECURITY, ACCOUNT, AUDIT, LEADER, or CONSULT go through the
 rule checking for CASECAUT to see if they were allowed to update
 the password related fields in the logonid. Fix SO05978 updated
 the code to work as it was intended when the support was put into
 the product where rule checking for CASECAUT was only to be done
 for common users. Any user with any of the five authorities bypassed
 the resource rule checking of CASECAUT support.
 It has been decided that there is no reason to limit CASECAUT to
 just common users. This apar will allow the following authorities
 to go through the rule checking for CASECAUT - ACCOUNT, AUDIT,
 LEADER, or CONSULT.
 For instance, this will allow a user with LEADER to still go through
 the rule checking for CASECAUT to see if they are allowed to change
 the password related fields being updated.
 
 SYMPTOMS:
 A user with any of the five authorities bypasses CASECAUT processing.
 
 IMPACT:
 It does not allow a user to be given something like AUDIT to list
 the logonids before they are given access to update the logonid.

The following PTF opened up CASECAUT to all fields defined in the ACF2 logonid record.

SO10166     Release: 16.0

 ENHANCEMENT DESCRIPTION:
 Through CASECAUT resource checks, ACF2 allows delegation of selective
 administrative authority to a general user without needing to give him
 logonid privileges that may be more than needed to help perform admin.
 This is based on rules for the CASECAUT Class and Resource names of
 ACFCMD.USER.<fieldname>.
 
 This is supported for the ACF CHANGE subcommand for the following
 LIDREC field names:
 PASSWORD, PWPHRASE, PSWD_EXP, PSWD-VIO, PSWDCVIO, PWP-VIO, KERB-VIO,
 SUSPEND and CANCEL
 
 This enhancement will open up the support to include any modifiable
 LIDREC field name defined in the ACFFDR via @CFDE.