How can a user be setup to change PASSWORD, PSWD-VIO, and all other fields in the ACF2 logonid record?
Article ID: 38251
Updated On:
Products
Issue/Introduction
How can a help desk user to be setup to unsuspend users and change PASSWORD, PSWD-VIO, and any other fields?
Environment
Component: ACF2MS
Resolution
Beginning with Rel 15.0 CA-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, special ACF2 logonid privileges. This is described in the CA-ACF2 documentation set (https://techdocs.broadcom.com/) in section, "Identifying Who Can Maintain Logonid Records".
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...
Step 1. Add AUT to the INFODIR:
TSO ACF
SET CONTROL(GSO)
CHANGE INFODIR TYPES(R-RAUT) ADD
F ACF2,REFRESH(INFODIR)
Step 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
Step 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 would mean 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 unscoped security administrator if needed. .
Additional Information
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.
Feedback
