Carol describes five IBM i security settings that eliminate exposures and can be changed with very little risk of breaking anything.
I know that many of you feel handcuffed. You want to make changes to improve your IBM i security posture, but your organization is so risk averse that it’s almost impossible to make changes that have the possibility of breaking a production process. While I can’t guarantee that these changes will not cause an issue, it’s unlikely that they will.
Service accounts—those profiles that are used for making connections to and from your IBM i via ODBC, FTP, DDM, etc.--are typically configured to not be allowed for sign-on. That is, the profiles are configured with Initial Program (INLPGM) *NONE and Initial Menu (INLMNU) *SIGNOFF. With these attributes set, interactive sign-on is not allowed—or so you think. If you have left the Limited Capability (LMTCPB) at the default of *NO and you haven’t removed the Program/procedure and Menu fields from the 5250 emulation sign-on screen, someone with knowledge of the service account’s password could log on simply by specifying QCMD in the Program/procedure field or MAIN in the Menu field. You can prevent this from happening by specifying LMTCPB(*YES). If the service account is used for FTP and it uses the FTP remote commands, set LMTCPB(*PARTIAL). *PARTIAL prevents overriding the sign-on fields but still allows the profile to enter commands. (FTP is a server that recognizes the limited capability attribute. See my article on the topic.) If you want to make absolute certain that nothing breaks, set the value to *PARTIAL.
Now you’re thinking you’re done with service accounts, right? Wrong. Another adjustment that you’ll want to make is to set the Attention Program (ATNPGM) to be *NONE. Most organizations leave the Attention Program at the default. When the Attention Program is invoked—typically by pressing the Escape key—the default is to display the Operational Assistant Menu, which has menu options allowing you to run commands such as Work with Printer Output and Work with Jobs, both of which have a command lines. I realize you’re wondering what this has to do with service accounts. Once again, if someone knows the service account password and they enter it on the sign-on display, they’ll receive a message that the profile cannot be used for sign-on, but when that message appears, if the Attention key is quickly pressed, the Attention Program is run and the service account now has access to the aforementioned menu. If the service account’s LMTCPB setting is either *NO or *PARTIAL, commands can be entered and run. The issue is compounded because many of the service accounts that I see on our clients’ systems have been created with *ALLOBJ special authority. This exposure can be totally eliminated—without fear of breaking a thing (except for people signing on and abusing the profile!)—simply by specifying ATNPGM(*NONE) in all of your service accounts.
Profiles Used Only for Batch Processing
Some organizations create a profile that runs all of their scheduled jobs. Like service accounts, batch profiles are typically not intended to be used for sign-on. When that’s the case and because they are not used to establish a connection, these profiles can safely be set to PASSWORD(*NONE) and STATUS(*DISABLED). Yes, jobs can run using a profile that is disabled. While you’re changing the batch profiles, any profile that doesn’t have a password can be set to Password Expiration Interval (PWDEXPITV) *SYSVAL. Since the profile doesn’t actually have a password, the system never examines the password expiration attribute. Why have a profile without a password unnecessarily show up on the list of profiles with never-expiring passwords?
Password Level (QPWDLVL)
Most organizations can safely move their IBM i systems to password level 1 without issue. Moving from password level 0 to 1 does not change the maximum length or the character set of the password like moving to level 2 or 3 does. Moving to QPWDLVL 1 removes a version of the IBM i password that has been encrypted with an old and very weak Microsoft encryption algorithm. This version of the password is only used when connecting to the NetServer using a workstation running Windows 95, 98, or ME or connecting to NetServer using Windows 2000 Server. The vast majority of you are no longer using this old technology or it’s used for other purposes than connecting to the NetServer. When that’s the case, it is safe to set QPWDLVL to 1. The change will take effect with your next IPL.
Inactive Profiles That Remain on the System
When profiles must remain on the system for an extended period of time (more than 90 days) due to policy or regulation, most organizations set the profile to be status of *DISABLED. But you might consider also setting the password to *NONE. I’ve seen all profiles on a system be re-enabled after getting disabled. This most often occurs when organizations use High Availability (HA) replication solutions, but it is not limited to this system configuration. If you set the password to *NONE, even if the profile is re-enabled, it will not be able to be used by someone else. (In the rare occurrence that the person actually needs the profile after an extended time, what’s the chance that they would remember the password? They would quite likely have to have the password re-set anyway.) I’ve seen organizations take even more steps to “neutralize” the inactive profile. These include removing the profile’s group(s) and special authorities. The only caution I would take prior to removing the special authorities is to make sure that it doesn’t own programs that adopt (the User profile attribute of the program is set to *OWNER) and that are in use. The program may be relying on the owner having these special authorities to run successfully. In this case, do not remove the special authorities.
Remove *SAVSYS Special Authority
*SAVSYS stands for “Save the System,” and it gives the user to whom it’s been granted the ability to save or restore anything on the system, regardless of whether they have authority to the object. I believe there’s a misconception that you need *SAVSYS to be able to save anything, but that’s not true. If you have *OBJEXIST authority to an object, you can save it. So, for example, you can always save objects you own. *SAVSYS special authority should be given only to those in an operator or system administrator role. Examine the profiles outside of those roles that have been granted *SAVSYS, and if they aren’t supposed to be saving objects to which they aren’t authorized, remove the special authority from their profile.
I’ve tried to provide you with some steps you can take with little fear of breaking a production process. If you still have concerns or want a 100% guarantee that none of these changes will break anything, then you need to forget that you ever read this! But, hopefully, these suggestions will help you make progress on improving your IBM i