Command Access Can Bring Unexpected Consequences

Does this sound familiar? You recently experienced an “unplanned outage” after an administrator inadvertently issued a PWRDWNSYS command while mentoring a new operator. While the administrator was authorized to perform this type of system task, there certainly was no desire to run it in the middle of the workday with the IBM default of RESTART(*NO)!

Is there a way to enforce restrictions on users who typically are authorized to run commands?

Commands = Power

Commands are objects, and you can grant and revoke authority to them much the same as any application object. Some commands require that the person executing them have certain special authorities. (In the case of the embarrassing PWRDWNSYS command, the user needed *JOBCTL special authority.) Unfortunately, once these requirements are met, the operating system does nothing additional to oversee execution of the command. This means that a user who is authorized to a command has total control of when and how it’s executed.

Control Command Use with Powertech Command Security for IBM i

Powertech Command Security for IBM i is a rule-based security solution that’s designed specifically to audit and control commands. To configure Powertech Command Security for IBM i, you start by selecting which commands you want to monitor. Then, specify the conditions under which the command should be controlled. Finally, define the actions to take when those conditions are met. Conditions can be based on a value specified on a command parameter, the name of the requesting user or group profile, the calling program, the requester’s IP address, or a number of other powerful and flexible filters. If a condition is met, Powertech Command Security for IBM i performs the actions you’ve defined. Actions can include overriding a parameter (like the RESTART parameter!), sending a message, or even preventing the command from executing.

While there are endless ways to use Powertech Command Security for IBM i to control the command use on a system, consider the following common, and simple-to-configure, scenarios:

And last, but certainly not least:

1. Permit security administrators to run the CHGUSRPRF command, but only if they’re listed on a specific “change-allowed” authorization list.
2. Notify the high availability administrator whenever someone creates a new library to determine if it should be a candidate for replication.
3. Prevent any user from deleting an audit journal receiver.
4. Block the use of DFU (STRDFU, UPDDTA) and STRSQL commands on critical files.
5. Prevent programmers from using CRTRPGPGM or CRTCLPGM commands to compile directly into a production library
6. Reject a Power Down System command from anyone but QSECOFR, if it’s between the hours of 8 a.m. and 5 p.m., the RESTART parameter is set to *NO, and the command was issued from an interactive command line.

For many companies, managing their most powerful users is a constant struggle. Powertech Command Security for IBM i lets you add an extra level of security to your commands, without preventing critical users from performing their jobs.