The short answer to that question is no, but there are at least two scenarios where it makes more sense to use the Authority Collection feature added in V7R3 than the audit journal. Read on for details!

During a class I was teaching, someone asked if they should stop auditing the commands a user was running and enable Authority Collection to log users’ activity instead. Since her need was to log users’ activity to satisfy audit/compliance requirements, the answer to her question was a resounding no. That made me wonder if others have similar questions about replacing the operating system’s auditing features with the Authority Collection features. While there are two instances where I think you’ll want to use Authority Collection rather than the audit journal, there are no scenarios that justify reducing what you’ve currently configured for auditing.

Why Authority Collection is Not a Replacement for the Audit Journal

Several reasons immediately come to mind as to why the authority collection isn’t a replacement for the audit journal:

1. Authority Collection could never be a full-on replacement for the audit journal because it simply doesn’t collect all of the actions that the audit journal logs. The purpose of the Authority Collection feature is to collect access to objects—either by user or by an object itself. It doesn’t collect specific actions, such as changing a system value (logged via the SV audit journal entry) or accessing the system via FTP or ODBC (logged via the GR audit journal entry) nor does it log the “before” as well as “after” values when changing an attribute of a user profile (via a CP audit journal entry), to name a few examples.

2. Another reason is the way audit journal entries are stored. When auditing was added to the system way back in V1R3, a journal receiver (*JRNRCV) was chosen as the storage repository because it preserves the integrity of the entries. Given the design of a journal receiver, you cannot modify or remove an entry, thus ensuring the integrity of the entries, which is why you don’t need file integrity monitoring software for the audit journal on IBM i if you have to maintain compliance with the Payment Card Industry’s Data Security Standard (PCI DSS). An Authority Collection is stored in an internal object and, while not easily modified, doesn’t come with the integrity features of a journal receiver object.

3. Journal receivers are much more easily saved than an Authority Collection. If you have enabled Authority Collection on a user profile or an object, the fact that the collection has been configured is saved when you save the profile or the object, but none of what’s been collected is saved. To save the Authority Collection entries, you must select the entries and save them to a file using SQL and then save that file. This is much more cumbersome than simply saving *JRNRCV objects.

4. Finally, the authority collection doesn’t log every access; it only collects information on the first unique access. For example, if the same user accesses the same file 100 times using the same program to open that file and that program has the same authority requirements (for example, it requires *USE to the SALARY file to run successfully), only one entry will be in the authority collection for that user. This is so the collection is not flooded with duplicate entries. This is what disqualifies it as a replacement for the audit journal, especially when you have a compliance requirement. For audit and compliance purposes, every access must be logged.

When Should You Use Authority Collection Rather Than the Audit Journal?

I did say that there are two scenarios where I believe the Authority Collection is a more appropriate tool to use than the audit journal.

The first is when you’re trying to determine what authority a user requires to access an object. With the integrated audit feature of IBM i, you can enable *ALL object auditing on objects. Accessing an object with this audit configuration will result in either a ZR (object read) or ZC (object changed) audit journal entry. However, when trying to find information on a specific object, one must first “harvest” this information out of the audit journal by gathering ZR and ZC entries and then parsing out the results to find information about the accesses for the specific object you’re interested in. If you’re trying to determine who is accessing your application’s master file, the number of audit journal entries logged can become huge as users go through their normal activities. Then, if you have an extremely busy system (think casinos (pre-COVID)), simply logging that access can cause a tremendous bump in the storage consumed for all of the journal receivers storing all of even one day’s worth of ZR and AC audit journal entries. Finally, pulling all of those entries from the audit journal for all of those entries can take a long time. Let’s just say I’ve easily been able to walk down the street, order coffee, and enjoy that coffee long before that job ends! On large and busy systems, it can be a massive about of entries to process and parse through. Authority Collection on an object (added in V7R4) is a much easier way to determine who is accessing an object. Remember, only unique accesses are collected, so even on a busy system, the number of entries will be significantly reduced in comparison to what’s collected in the audit journal. In addition, although it’s obvious what authority is required when a user’s access has generated a ZR entry (that would be *USE), it’s not obvious when the access generates a ZC entry. That’s because operations such as adding a physical file member, clearing a file, and creating a duplicate object all get logged as a ZC entry, but all require more than *CHANGE authority. Authority Collection logs the exact authority required by each user so you can know exactly what authority is required. It used to be a bit of trial and error when reworking an object’s authority when the user generated a ZC entry. I’d start by granting the user *CHANGE and, if an authority failure occurred, then grant more, sometimes asking the developer what’s happening at that particular point in the application to try to eliminate some of the guesswork. No need for any of that now if you use the Authority Collection on an object.

The second scenario is when an authority failure occurs. Rather than looking at an Authority Failure (AF) entry in the audit journal, simply starting the Authority Collection on the profile and having the user re-create the failure will allow you to quickly determine what object the failure is occurring on, what authority is required, and where the user’s current authority is coming from. I’ve had cases in which a user’s authority should have been coming from adopted authority, but for some reason, the program accessing the object wasn’t adopting at all or was incorrectly owned and therefore not adopting the right profile. All of this can easily be discovered using Authority Collection—not so much if you’re attempting this via the ZR /ZC audit journal entries. All the audit journal will tell you is the object the authority failure is occurring on and the program running at the time of the failure. It takes some detective work to determine the actual cause.

Summary

While the Authority Collection is not a replacement for the audit journal, there are at least two examples where the Authority Collection can make your life significantly easier than attempting to use the audit journal. If you haven’t tried the Authority Collection feature, give it a try the next time you have one of these two scenarios I’ve described.

For more information on authority collection:

• Chapter 16, IBM i Security Administration and Compliance, Third Edition by Carol Woodbury
• Chapter 10, IBM i Security Reference

Previous articles:

New Release! What New Security Features Does IBM i V7R4 Bring Us?

• Three Ways to Use IBM i Authority Collection