ICH408I USER (userid) GROUP (group-name) NAME (user-name) --or-- JOB (jobname) STEP (stepname) [SUBMITTER (userid)] [PRIMARY USER (userid)] [resource-name] [CL(class-name)] --or-- [VOL(volume-id)] [FID(file-identifier)] [ID(IPC-identifier)] --or-- [FROM generic-profile-name (G)] [ACCESS INTENT(intent) ACCESS ALLOWED(allowed)] [EFFECTIVE UID (nnnnnnnnnn] [EFFECTIVE GID (nnnnnnnnnn]

Explanation

This message is issued when RACF® detects an unauthorized request (a violation) made by a user or job. The user and group that is indicated in the first line of the ICH408I message are the execution user ID and group ID under which the job was to run.

If the message indicates a job and step instead of a user, group, and name, RACF cannot find a valid ACEE containing user, group, and name information. This can occur for a started task that is not defined in the RACF started procedures table (ICHRIN03), if an entry in the started procedures table has an incorrect RACF group that is specified, or if the user's ACEE is corrupted. If the submitting user ID is not the same as the execution user ID, the message includes an additional line containing the submitting user ID, group, and node.

When the message is reporting an access failure for a delegated resource using a nested ACEE, PRIMARY USER is displayed. A nested ACEE is an ACEE for a client which indicates the identity of the server or daemon that created the work unit. The client user ID is displayed as the primary user. The first line of this message identifies the server or daemon on whose behalf the resource is being accessed. You should permit the daemon to the resource rather than the client. See z/OS Security Server RACF Security Administrator's Guide for information about delegated resources and nested ACEEs. Depending on the resource name, consult the appropriate application documentation for setup requirements.

When USER(userid) contains a user ID in the form of “**nnxxxx”, such as “**01XUSR”, the user ID identifies an identity context reference, not a RACF user ID. This value, along with a password substitution value, can be used to retrieve information about an authenticated user from an identity cache. When an identity context reference is specified on a RACROUTE REQUEST=VERIFY,ENVIR=CREATE request, RACF attempts to resolve the reference to a RACF-defined user from the identity cache. If RACF cannot resolve the reference, any resulting ICH408I messages contains the unresolved identity context reference user value. Possible reasons that the identity context reference cannot be resolved include:
  • An invalid value, such as an unsupported SESSION=type value, was specified with the identity context reference on a RACROUTE REQUEST=VERIFY,ENVIR=CREATE request.
  • The identity context reference was not recognized by the identity cache. Possible reasons include:
    • The identity context reference was invalid. A valid identity context reference consists of both an 8-character user ID value and an 8-character password value.
    • The identity context reference was expired. Identity context references have a timeout interval of 1 to 3600 seconds (1 hour).
  • The identity cache contains invalid or incomplete information. This can happen if the identity cache is not configured to ensure that an identity context reference always resolves to a RACF-defined user (MAPREQUIRED=NO).
When the message is reporting an access failure for a z/OS® UNIX file, the resource name is the path name that was specified to the kernel syscall. It does not exist for the syscalls performed against open files (those in the fxxxxx format such as fchown). The FID (file identifier) is a unique 32-hex-digit identifier of the file. It is provided because multiple path names can be used to access the same file. This identifier allows matching of accesses to the same file by different names. The z/OS UNIX systems administrator can use the zfsadm command to query the settings for zFS. See z/OS UNIX System Services Command Reference for more information about file system settings.
Note: An FID might map to multiple file names if your zFS aggregate is not enabled for unique auditids. See z/OS File System Administration for more information about configuration information.

When the message is reporting an access failure for an z/OS UNIX IPC key, the resource name is the IPC key name that was specified to the kernel syscall. It is displayed as a unique 8-hex-digit identifier. The ID (IPC identifier) is a unique decimal identifier of the resource. It is provided as additional information, that might be useful during auditing, although it is dynamically allocated by the kernel. It is a numeric value between 0 and 4294967295.

The meaning of the volume serial number that is shown in the VOL field varies. For a non-VSAM data set, it means the volume on which the data set resides. For a VSAM data set, it means the volume on which the catalog containing the data set entry resides.

The phrase FROM generic-profile-name (G), if included in the message, identifies the generic profile that RACF used to check for access to the resource.
Note: If used against a DATASET resource-name, and the data set is on tape, then the FROM generic-profile-name might be a TAPEVOL profile, if the TAPEVOL class is active.

For further explanations of this message, check the message line that indicates what request was made. This is typically line 2 or 3. For example, it can be INSUFFICIENT ACCESS AUTHORITY. Find this message line among the explanations that follow for message ICH408I (arranged alphabetically), and read the explanation for that message line.

For attempts to use protected resources, the message shows the access attempted (ACCESS INTENT phrase) and the access permitted by RACF (ACCESS ALLOWED phrase). When the message is reporting an attempt to access an z/OS UNIX file or IPC key, the ACCESS INTENT (intent) is specified as RWX, representing read, write, or search/execute permission requested. More than one permission can be requested at a time. If a permission is not requested, the letter is replaced by a dash -. ACCESS ALLOWED (allowed) is specified as {OWNER/GROUP/OTHER/ACL USER/ACL GROUP/NO/RESTRICTED/FSACCESS/FSEXEC} RWX, where OWNER indicates the owner permission bits were used, GROUP indicates the group permission bits were used, OTHER indicates the other permission bits were used, ACL USER indicates that a specific user Access Control List (ACL) entry was used, ACL GROUP indicates a specific group ACL entry (or entries) was used, NO indicates that no permission bits were used, RESTRICTED indicates the OTHER bits were not used for a RESTRICTED user, FSACCESS indicates a profile in the FSACCESS class was used, FSEXEC indicates a profile in the FSEXEC class was used, and RWX represents the settings of the permission bits that were checked. ACCESS ALLOWED (NO --X) occurs if a superuser attempts to execute a file that does not have OWNER, GROUP, ACL, or OTHER execute permission. ACCESS ALLOWED (RESTRICTED –––) occurs if a RESTRICTED user only gains file access by way of the OTHER bits, but is forbidden by the RESTRICTED.FILESYS.ACCESS profile in the UNIXPRIV class. ACCESS ALLOWED (FSACCESS –––) occurs if the user does not have access to the FSACCESS profile protecting the file system that contains the resource. ACCESS ALLOWED (FSEXEC –––) occurs if the user does not have access to the FSEXEC profile protecting the file system that contains the resource.

Note that while checking for group access, the group permission bits are treated as simply another GID ACL entry, if the process GID, or one of its supplemental GIDs matches the file owner GID. Several group entries might actually be checked, and access is granted if any of them specifies the requested permissions. However, if none of the entries grants the requested access, there is no single entry that defines the access allowed. By convention, the permissions associated with the first relevant group entry encountered are displayed in the message. See the z/OS UNIX information in z/OS Security Server RACF Security Administrator's Guide for a description of the algorithm used to determine access when an ACL exists for a file or directory.

For violations occurring in the UNIX System Services environment, the user's effective UID and effective GID are displayed in the message. These ids were used to determine the user's privilege for the intended operation. Note that they might not always match the ids that are defined in the relevant RACF USER and GROUP profiles, because UNIX System Services provides methods by which another identity can be assumed.

System action

If the phrase RESOURCE NOT PROTECTED appears in the message with a warning, RACF allows the request to continue. If the phrase RESOURCE NOT PROTECTED appears in the message without a warning, RACF fails the request.
Note:
  1. When a user is denied access to a RACF-protected resource because of the return code from a RACROUTE REQUEST=AUTH installation exit routine, the user's allowed access might be inconsistent with the requested access. (For example, access allowed was ALTER, access requested was READ, but the request for access was denied.)
  2. Authority checking for users with the restricted attribute bypasses checking of some authority granting mechanisms, such as the UACC. If a LISTUSER for the user ID shows that the user is restricted, the user's user ID or group name must be on the access list to allow access to the resource. See z/OS Security Server RACF Security Administrator's Guide for additional information about restricted access user IDs.
  3. The phrase “LOGON/JOB INITIATION/initACEE” might appear during logon processing; however, the logon might be successful. When RACF is active, logon verification can produce an error during RACF processing; however, the logon can proceed using an alternate method (for example, UADS). This error occurs if the installation does not use the RACF database to store security-related information for a particular user, but it does use an alternate method (such as UADS) for the logon application (for example, TSO) to perform user verification.
  4. If the failure occurred for a z/OS UNIX System Services system function, RACF returns an error return code to the invoking system function, which returns an error return code to the application caller or causes the calling task to abend. See z/OS UNIX System Services Programming: Assembler Callable Services Reference to determine the action of the syscall functions.
  5. If you see JOB/STEP in the message instead of USER/GROUP, it indicates that a default security environment for an undefined user is assigned, instead of a normal user ID. This can happen if a started procedure is not defined correctly in the STARTED class or in ICHRIN03.
    • If you used the STARTED class, make sure that you have the correct profile or profiles defined and make sure that it was properly RACLIST REFRESHed after you added the profiles.
    • If you used ICHRIN03, be sure to IPL the system with CLPA.
    For third-party authorization checking, RACF performs the following steps:
    • If the USERID= keyword is omitted, "*" is the default.
    • If the USERID keyword is *NONE* and GROUPID is not specified, RACF checks using a default (undefined-user) ACEE.
    • If USERID=BLANKS is specified (where BLANKS is eight characters of X'40' characters) and GROUPID is not specified or specified as GROUPID=BLANKS, RACF builds an ACEE with an asterisk (*) specified as the user ID or group name. This is the same as an ACEE built by RACROUTE REQUEST=VERIFY without specifying USERID, GROUPID, or PASSWORD.

Operator response

Follow the security procedures that are established for your installation. If no such procedures are established, report the complete text of this message to the RACF security administrator.

User response

Follow the security procedures that are established for your installation. If no such procedures are established, report the complete text of this message to the RACF security administrator.

Problem determination

Detailed information about the violation is available in the SMF type 80 record that RACF produces at the same time as this message. See z/OS Security Server RACF Auditor's Guide for information about reporting on the contents of the RACF SMF records.
Note:
  1. When RACF verifies a password during logon or when a batch job begins, the message includes NAME (???).
  2. For users not defined to RACF, the job and step are indicated by jobname and stepname. JOB/STEP is used in the following conditions:
    • When there is no ACEE,
    • When the ACEE is invalid, corrupted, or missing key information, or
    • When the ACEE is a default ACEE (that is, uses the undefined user of '*').
    For batch users, stepname is blank.

Routing code

9 and 11

Descriptor code

4

This message is routed to the security console. All violations (except LOGON/JOB initiation/initACEE messages, command violations, and z/OS UNIX System Services violations) are issued as write-to-programmer (WTP) messages.

Note: A TSO/E user who is using z/OS UNIX System Services does not see the ICH408I messages.