User Profiles Specified in a Job Description- Moving to a Higher Security Level
J entries, as I said, indicate the use of a job description that specifies a user profile. Most of the time, job descriptions are created so that the person using the job description is the profile under which the job runs. But the USER parameter can be specified with the name of a user profile. In this case, when the job description is used, the job runs as the profile specified in the USER parameter. The problem with this and the exposure it causes at QSECURITY levels 20 and 30 is that, at these levels, the user only needs authority to the job description, not the user profile named in the job description. Therefore, if you have a job description that names a powerful profile, people can use the job description and elevate their authority. Vendors will often ship job descriptions that name powerful profiles (that is, profiles that have all special authorities) with their products. If those job descriptions are not *PUBLIC *EXCLUDE, they’re an exposure if your system’s not at QSECURITY level 40 or 50. (At levels 40 and 50, attempting to use a job description that names a user profile to which you don’t have *USE authority will fail.) But it’s not just vendors that do this. I’ve also seen client-created job descriptions that specify a profile.
So what do you do if you encounter J entries? Part of your challenge will be to determine which job description caused the audit entry. One would think that would be in the audit journal entry, but it’s not. What’s listed is the user profile named in the job description. The easiest way to get the list of job descriptions that specify the user profile in the AF-J entry is to use the QSYS2.JOB_DESCRIPTION IBM i Service as follows (obviously substituting the profile named in the audit journal entry for XXXX).
If it’s not obvious which job description is causing the issue (often looking at the job description’s last used date will make it obvious), you can start Authority Collection on the job descriptions to determine who and which processes are using them. But I’ve never had to go to that length to figure it out.
What do you do once you’ve identified the offending job descriptions? I’ve found that, in most cases, either the job description no longer has to be used or it’s preferred that the job run as the actual user, so the USER parameter is changed back to the default of *RQD or it’s switched out to another job description. The absolute last resort that I use to resolve this issue is to set the profile to *PUBLIC *USE. It’s the last resort because it allows the profile to be specified, not just in job descriptions but also on a Submit Job (SBMJOB) command. And I would take this step only if the profile had no special authorities and did not own the application (or anything else important).
I have not seen an application or system that cannot be moved to QSECURITY level 40 (or 50) in ages. Most of my clients have had no changes to make and can IPL to level 40 without issue. Obviously, you’ll want to audit to make sure that’s the case for you, but even if you discover something that needs to be changed, it’s unlikely that it will be a major change.