IRR421I

Explanation
RACF® detected an ACEE that was modified since its
creation. This could be the result of an intentional, non-malicious update by an authorized
application. However, this could also indicate the presence of malware on your system.

The user ID (user-id) is taken from the modified ACEE, which could be a
task-level ACEE, an address space-level ACEE, or an ACEE explicitly passed to a RACF service. The address space is identified by the ASID
(addrspace-ID), the user ID from the address space-level ACEE
(addrsp-user-id) and the job name (jobname). The job name will
appear as "-None-" if there is no job name associated with the address space.

The currently running program is displayed as program-name.
Racf-function is the RACF module name that
detected the modified ACEE.

A hexadecimal reason code (formatted as 0xnnnnnnnn) is displayed in rsn. It
might be followed by reason-list, which describes specific changes detected to
the ACEE. Reason-list is displayed as a list of attributes and values, each
enclosed within parentheses. For example, if the SPECIAL bit was turned on, and the user ID was
changed from MICHAEL to IBMUSER, reason-list is displayed as "(ACEESPEC is ON)
(ACEEUSRI: expected MICHAEL, actual IBMUSER)."

For any combination of user-id, program-name and
addrspace-ID, RACF only issues IRR421I once per 5-second interval. The variable
error-count indicates how many times a modification for this combination was
detected since IPL.

Next, additional information is displayed that either identifies the RACF command that detected
the function, or, if the detection occurred during an authorization check, identifies the class name
and resource name being accessed.

Before issuing IRR421I, RACF will check the ACEECHK class
to see if the message should be suppressed for certain programs. However, if the execution
environment is dirty (uncontrolled), then exceptions are not honored. If this is the case, the
following sentence appears in the message: "Profiles in the ACEECHK class were ignored because the
execution environment is not clean." Stated another way, if this sentence appears, then an existing
exception profile would have resulted in suppression of IRR421I if the environment were clean.
Additional messages may follow IRR421I that indicate the reason the environment became dirty. For
details on program control and clean environments, see the
Protecting programs in z/OS Security Server RACF Security Administrator's Guide.

Finally, the call chain of programs is displayed, starting
with the currently running program and ending with the job step program. The list contains all the
programs under the current task (TCB), and the first program for each parent task, up to the job
step task.

System action
RACF proceeds with the request.

Routing code
9

Descriptor code
4

RACF Security Administrator Response

If program-name and the call chain can be associated with a known application,
contact the provider of the application and ask if any of the identified programs are expected to
modify the ACEE.

The program names identified in IRR421I provide information about which programs are involved in
the current chain of execution. These program names are displayed to provide some insight into the
execution environment and to possibly help identify the provider of the software currently running.
It is possible that this information can help determine whether the behavior is expected. IRR421I
cannot identify which program actually modified the ACEE. In fact, it is possible that the modifying
program is not even in the call chain.

If it can be determined that the behavior is expected, consider adding the appropriate program to
the exception list in the ACEECHK class to suppress IRR421I for this application. See the
z/OS Security Server RACF Security Administrator's Guide for information on the ACEECHK class.