With the introduction of the STGADMIN.IGG.DEFINE.RECAT profile with IBM apar OA33013 we have been receiving loggings for privileged accounts on our ACF2 systems against the profile for calls that do not seem to be related. Why is this happening?

Products

• ACF2
• ACF2 - DB2 Option
• ACF2 for zVM
• ACF2 - z/OS
• ACF2 - MISC
• PanApt
• PanAudit

Issue/Introduction

With the introduction of the STGADMIN.IGG.DEFINE.RECAT profile with IBM apar OA33013 we have been receiving loggings for privileged accounts on our ACF2 systems against the profile for calls that do not seem to be related.  We have SECURITY and NON-CNCL logonids getting an enormous amount of loggings that never happened before.  Why is this happening?

 

 

 

Environment

Release:
Component: ACF2MS

Cause

Changes in the RACROUTE parameters can cause results different then what previously happened.

Resolution

The RACROUTE call to security before the IBM fixz looked like this:

SMFID= xxx TOD= hh:mm:ss TRACEID= TEST USERID= TESTID 
JOBNAME= TESTJOB ASID= 0nnn PGM= IEFIIC CURR RB= SVC026 
SFR/RFR= 0/0:0 MODE= TASK APF= AUTHORIZED LOCKS= NONE 
SAFDEF= GENAUTH INTERNAL MODE= GLOBAL 

RACROUTE REQUEST=AUTH,CLASS='FACILITY',RELEASE=1.9,STATUS=NONE, 
ATTR=READ,DSTYPE=N,ENTITY=('STGADMIN.IGG.DEFINE.RECAT'), 
FILESEQ=0,GENERIC=ASIS,LOG=NONE,MSGSP=0,TAPELBL=STD, 

 

IBM apar OA33013 changed the parameter LOG=NONE to LOG=NOFAIL.  With LOG=NONE, no violation messages or logging to SMF will happen.  With LOG=NOFAIL, if the validation fails, that is like LOG=NONE.  If the validation is allowed, that makes the parameter LOG=ASIS.  Since SECURITY and NON-CNCL ids are always allowed, then LOG=ASIS comes into play.  ACF2 always logs an access allowed if the reason was because of SECURITY or NON-CNCL.  So ACF2 will cut an SMF record in this case.  The resolution to stop the loggings would be to write an exit, write the needed rules for the SECURITY or NON-CNCL logonid, or use a MAINT logonid instead of SECURITY or NON-CNCL.