IBM has externalized some of the system configuration options found in System Service Tools (SST) as well as the service tool ID configuration options by making them CL commands. This is in direct response to requests from organizations running large numbers of IBM i partitions that need to perform remote management rather than having to sign in to each instance separately.

You can now Create, Change, and Delete a Service Tool ID using the appropriate command (CRT/CHG/DLTSSTUSR). Using the Display or Change SST Security Attributes (DSP/CHGSSTSECA) commands, you can display or modify the system configuration settings, such as the ability to lock system values, the password rules for the SST service tool ID, and more.

Before you ask whether this is opening up security for SST, never fear. You still have to have some special authority. The exact authority is documented in the Service tools command section in Appendix D of the V7R4 Security Reference manual. In addition, required parameters of the commands demand that you provide a valid service tool ID and password that has enough authority within service tools to perform the task.

If you've heard me talk about the Authority Collection feature that was added in V7R3, you'll know that I'm a huge fan of this feature. Simply put, it takes the guesswork out of securing your system. You don’t have to wonder what authority is required—simply start the authority collection and find out what’s required. When the Authority Collection feature was added in V7R3, you could only turn on the collection based on a specific user profile. You could scope what was being collected by object, but you had to know what users were accessing an object to be able to gather information about the required authority.

In V7R4, IBM enhanced the authority collection feature to allow you to turn it on by object. You can turn it on for a specific object or all objects in a specific library or directory. What’s collected is all of the users that are accessing these objects, together with the details of the authority that’s required to access the object(s), the authority they currently have to the object, and where it’s coming from (*PUBLIC authority, a private authority, one of their groups, an authorization list, or adopted authority). Again, this is so incredibly helpful if you’re trying to set objects to more restrictive settings but are scared you’re going to break something by doing so. Using the authority collection feature allows you to have confidence that you have given the authority required to access the object (but no more than is necessary) and that you won’t break something in the process.

When should you use Authority Collection by user vs. by object?

Using the Authority Collection feature in V7R3 has proven to be incredibly helpful when helping our clients reduce the amount of authority a specific user or set of users have. For example, service accounts are often created with *ALLOBJ. We have successfully removed that *ALLOBJ special authority by turning on the Authority Collection for that service account, determining what it’s accessing, and authorizing that profile with the authority required to access those objects. With Authority Collection by object, I anticipate using it to help clients reduce the overall access control setting to a specific file or to reduce access to an entire application. It's a slightly different approach, but both methods have the goal of removing unnecessary access or reducing access to just the amount required—that is, implementing the principle of least privilege access.