Authority Collection for Users: Objects in Libraries – Using Authority Collection to Reduce Users’ Authority

First, you must start a collection for the profile you’re going to investigate. Figure 6.1 shows the Start Authority Collection (STRAUTCOL) command. Specify the profile name and then the libraries containing the objects the profile accesses. The more you can scope down the objects for which you’re going to collect information, the better, as there will be less to analyze. But if you truly have no idea what objects the profile touches, that’s OK; specify *ALL for the library as well as leave *ALL as the default for both the Object and Object type fields. (I’ll describe your options for IFS objects in a bit.)

Figure 6.1: STRAUTCOL collection being started for the WINSVR profile for all objects in all libraries.

Once you press Enter, the collection starts with the first action the profile takes. No need to stop/restart anything or to sign off/sign on. The collection just starts. Also, you’re not going to see a job that’s collecting the information if you run Work with Active Jobs (WRKACTJOB). That’s because the collection is taking place below the MI (in SLIC) and is invisible to the operating system itself in much the same way that auditing is invisible.

Once you know that the profile has had some activity, start looking at the results. You may want to run the collection longer (perhaps over month end), but I recommend that you look at it sooner rather than later to start to get a feel for the type of information that’s being collected and to start to understand how to read and interpret it.

Authority Collection information is viewed by running SQL against the QSYS2.AUTHORITY_COLLECTION view. I recommend that you start by looking at all of the entries that have been generated. Run the following, where XXXX equals the name of the service account you’re investigating.

Scroll to the right. focusing on the column headings to see all of the information that’s available and not so much on the actual results. Because you’re analyzing a profile with *ALLOBJ, you’ll notice that all entries list the authority source as *ALLOBJ, underscoring the fact that *ALLOBJ is the first thing checked in the authority-checking algorithm. See Figure 6.2 for an example. Once you remove *ALLOBJ, you’ll see other sources, such as PUBLIC, GROUP PRIVATE, USER OWNERSHIP, etc.

Figure 6.2: Authority source will always be USER *ALLOBJ when analyzing a profile with *ALLOBJ special authority.

Most of the information provided is invaluable, but I have to say that, in my opinion, IBM went a bit overboard and didn’t need to include some of it because it only confuses the results. I’ll explain as we go along. Let’s start analyzing the results.

This may sound strange, but when I look at a profile’s collection for the first time, I just kind of stare at it for a bit to try to get a big picture of what it’s telling me. It will tell me what I’m interested in as well as what I can start filtering out.

One of the first sets of entries I filter out are the entries that indicate that the operating system’s adopted authority will be used for the profile to gain access once the profile’s *ALLOBJ is removed. You may not realize it, but much of the operating system adopts its owner (QSYS). That’s so operating system tasks can be performed without the user profile requiring authority. Once a profile’s *ALLOBJ is removed, the operating system’s adopted authority will be used. So I want to remove those because you can be assured that access will be successful since the operating system will be taking care of the access. In fact, the following statement eliminates all program adoption because you also don’t want to include programs you may have written that adopt authority or vendor products that adopt.

The next set of entries to eliminate are the ones where the process is checking to see if the process has any authority to an object before proceeding to further access the object. I know the operating system does this, and I’ve also seen vendor products take this approach. The problem with the Authority Collection entries representing this check are the values shown in the Required Authority and Detailed Required Authority columns. Stating that the required authority is *ALL and listing all authorities, including *OWNER, in the detail field is incredibly misleading. See Figure 6.3. The system doesn’t care what authority the user has; they are simply required to have one of the authorities. This is one of those entries that IBM (again, in my opinion) shouldn’t have included in the collection. It’s worthless information and, worse, is very confusing, so I’m going to eliminate that and reduce the confusion.

Figure 6.3: Checking for “ANY AUTHORITY” produces a highly misleading entry in the Authority Collection.

Now you have a list of objects that the profile (in my case, WINSVR) is accessing where, once you remove its *ALLOBJ, access may be denied. Your next task is to determine where the profile’s authority is going to come from once *ALLOBJ is removed. At this point, it may help to take a look at the job information provided with each entry. That information is toward the end of the entry, just before the path (IFS) fields. You may find, for example, that the profile is making an ODBC connection to access several database files. In this case, you could either grant the profile a private authority to those files or create an authorization list, secure the files with it, and grant the required authority to the list. Or you could make the access via an *SQLPKG, which could be configured to be owned by and adopt the profile that owns or is authorized to the database files.

If you have a service account whose purpose is not clear—that is, it’s been overloaded and performs multiple tasks representing multiple roles—now may be the time to create more profiles and split up the tasks between new, single-purpose service accounts. When taking this approach with my clients, I’ve found that after the profile “break up,” they all appreciate the fact that it’s much easier to debug job failures as it’s much more obvious which job has failed. It’s also easier to grant only the access required and not over-authorize when a service account has a singular purpose.