Added SUBAUTH to an ACF2 LID with RESTRICT and the logonid is still being used by non APF jobs

Products

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

Issue/Introduction

A change was made to an ACF2 LID to have SUBAUTH, yet this change did not seem to prevent this LID from running some jobs with programs from non-APF authorized programs. The ACFRPTJL report shows that this is occurring, but why are some jobs being secured as expected and others are not?

Environment

Release : 16.0

Component : ACF2 for z/OS

Resolution

Verify how the ACF2 RESTRICT logonid is being specified for the jobs. The difference between running jobs via ACF2 inheritance vs. specifying the LOGONID within the job will determine whether SUBAUTH processing is to occur. SUBAUTH processing will not take place if the logonid is inherited (meaning when the submitter of the job and the logonid to be used for the job are the same and LOGONID is not specified in the job). To remedy this, all jobs that use the RESTRICT id need to have //LOGONID specified within every job it submits, or VLDRSTCT needs to be specified on the RESTRICTed LID record.

These types of jobs will show in the ACFRPTJL report and show that the programs were not APF authorized. However, these jobs will not show up in an LL report with the UPDATE parameter specified as the processing is not the same as a standard JESx logon/validation.

From the ACF2 Documentation section Logonid Record Fields:

VLDRSTCT|NOVLDRSTCT
Indicates that PROGRAM and SUBAUTH are to be validated even when this restricted logonid is inherited. (Bit field)
Logonid Record Section: Privileges