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?
Changes in the RACROUTE parameters can cause results different then what previously happened.
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.