User Profiles and the Audit Journal – User Profiles

It’s one thing to analyze profiles at a point in time (which is what I’ve been describing so far), but many organizations need to understand user profile configurations over time. For example, some organizations have a requirement to track all profiles created so an auditor can look at a report and determine if the appropriate change request was in place to justify the profile being created. Or perhaps the requirement isn’t for all profiles created. It may be for profiles created with a special authority, especially those created with or changed to have *ALLOBJ. I’ve also had clients who needed to track when profiles were deleted so there was proof that profiles were removed on a timely basis, especially when the individual was let go from the organization. Let’s take a look at how the audit journal can help document your user profile processes.

Creation of Profiles with a Special Authority

The following SQL will provide you with a report of changes to profiles, so this will list profiles either created or changed to have *ALLOBJ when they didn’t have that previously.

Obviously, if you have requirements to track the addition of other special authorities, you can replace the ALLOBJ fields with each of those special authorities (but only one special authority at a time).

Another consideration is when a user is added to a powerful group. The following code looks at profiles where either the group or supplemental group fields were changed in the last 7 days and one or the other includes one (or more) of the powerful groups named (ADMINGRP, SUPERGRP, and QSECOFR). Obviously, you’ll want to modify this to match your powerful group list. Note that you may get a false-positive result with this report because it’s going to list the audit journal entry if there’s any change to the supplemental group list. So if the supplemental group list contains one of your powerful profiles, it will be listed in the report, even if the change was to add or remove a different group. Unfortunately, IBM doesn’t provide the previous group or supplemental group list in the audit journal entry, so I couldn’t do a comparison like I could for the *ALLOBJ addition in the previous example.

Finally, let’s take a look at the profiles that have been deleted in the last month.

A reminder about the timestamp arithmetic: This example looks back one month, but if you don’t have audit journal receivers on your system for the last month, the SQL can only bring back the entries for the receivers currently on your system. For example, if you only have audit journal receivers on your system for the last two weeks, this example will only report on activity for the past two weeks.

Enter a new IBM i Service that will help you with this! Shipping with IBM i 7.5 and available with IBM i 7.4 TR 6, QSYS2.JOURNAL_RECEIVER_INFO provides you with the journal receiver attach day and time so you can determine how far back your audit journal entries go.

(Many thanks to Scott Forstie for this example.)

The takeaway: Make sure you set up your reporting schedule to match what you have on your system so you don’t miss activity!