Authority Collection was added to IBM i in V7R3. Carol discusses three practical applications of this powerful feature.
The new Authority Collection feature is very easy to use, but how a security administrator can use it might not be obvious. In this article, I discuss three scenarios and the way you’d use Authority Collection to solve each.
Profiles with Too Much Authority
This scenario may apply to end users, but the example I’m going to use is a service account, SERVICE1. Over the years, I’ve seen many service accounts that have been granted *ALLOBJ special authority because it’s a mystery as to what authority is actually required. Authority Collection will help you solve that problem.
The first step is to turn on the Authority Collection for the service account by using the Start Authority Collection (STRAUTCOL) command. While you can turn on the collection for every object the service account is going to access, for this example I’m going to narrow down the collection and only log the access of *FILE objects in the library PROD1. (You would typically start the collection for all objects accessed only if you have no idea what the profile is used for.)
Figure 1: Log the access of *FILE objects in the library PROD1.
In the example, this service account is used for running a batch job that does something with files in the production library. But it’s unknown whether it’s opening the files as read-only or for update. After starting the collection, I’ll let the nightly process run, and then I’ll examine the collection that’s taken place. The collection is in the AUTHORITY_COLLECTION view in the QSYS2 library. To get the information I’m looking for, I use the Run SQL Scripts feature of Access Client Solutions (ACS).
If you’re not an SQL guru or you’re not exactly sure of the syntax, use one of the great things IBM has provided with ACS: the examples. To insert an example, launch the Run SQL Scripts, and then click on Edit and choose Insert from Examples.… This produces a list of examples to choose from. Click on Security – Authority Collection, and then click the Insert button. While this may not be the exact logic you want to use to get the information, you may find it easier to start with the example, rather than attempt to remember all of the fields.
Figure 2: Run SQLScripts example.
From this query, I can see that SERVICE1 accesses the INVENTORY file and the authority required is *OBJOPR and *READ (or *USE). It also accesses the PRICING file with the authority required being the equivalent of *ALL. Once I grant SERVICE1 these authorities, I can remove *ALLOBJ and know I’m not going to break anything.
Authority Failure Occurs
You may run into a situation where a user is receiving an authority failure. You can look at the AF entry in the audit journal to determine what object the user’s job is failing on, but the audit journal won’t list what authority is required. Enter the Authority Collection. Start the Authority Collection for the profile whose job is receiving the authority failure. Since you know the object you want to collect information on, go ahead and limit the collection to that object. Have the user repeat the action causing the authority failure. Now you can examine the collection to determine what authority is required. Using the results shown in Figure 3, you can see that the user needs the equivalent of *CHANGE authority to the data area.
Figure 3: Determine what authority is required.
Determining Where Authority Is Coming From
The final scenario is a situation where you thought you secured an object but users are able to access it anyway. You’ve looked but can’t determine where the users are getting their authority. Because the Authority Collection includes the source of a user’s current authority, this is the perfect utility to help you debug this issue.
Start the collection on one of the profiles gaining access to the file. As described in the last example, you can limit the collection to just that file. Once the user has accessed the file, examine the collection. For this example, I’m including the Adopting_Program_Name field because, in this case, the user’s authority is coming from adopted authority as shown in Figure 4.
Figure 4: Find the source of a user’s current authority.
This example is a situation I’ve seen where a menu is adopting authority and also presents a command line. The adopted authority provides sufficient authority for users to take application menu options even though the application objects are *PUBLIC *EXCLUDE. Unfortunately, the adopted authority also flows out to the menu’s command line. The way to correct this issue is to change the program displaying the menu so that it doesn’t adopt, and then change the programs being called by the menu options to adopt authority.
It’s very helpful when a client’s IBM i systems are running V7R3. The Authority Collection opens up many options for reducing authority. And while my examples used objects in libraries, the Authority Collection feature can be used on objects in directories as well.
I hope these examples have helped you understand ways in which you can use the Authority Collection feature in your own environment.