Carol reminds readers of several hidden gems that help administrators manage IBM i security more effectively.
Every once in a while, I like to refresh readers’ memories about security features included with IBM i that they have forgotten about or didn’t even know existed. Let’s take a look at some of my favorites.
- Proactively Managing Temporary Profiles
Two methods exist for disabling profiles without waiting for them to go through your normal profile-aging process.
The first one can be implemented using either the User expiration date (USREXPDATE) or User expiration interval (USREXPITV) parameter on the Create or Change User Profile (CRT/CHGUSRPRF) commands. Using the USREXPDATE parameter allows you to specify a date on which the profile should be set to disabled. Using USREXPITV allows you to specify a range, such as 30 days. For example, if you are creating a profile for a temporary worker, you can use the USREXPITV parameter on the CRTUSRPRF command to set the profile to be disabled at the end of that worker’s assignment. Or, if you receive notice that a worker is leaving on a specific date, you can run CHGUSRPRF to set the profile to be disabled on the worker’s departure date using the USREXPDATE parameter.
The second method is available through one of the integrated security tools, accessed by typing GO SECTOOLS. Option 8, Change expiration schedule entry (CHGEXPSCDE), allows you to specify a date on which to disable or delete a profile. If you specify the *DELETE option, you’ll be prompted to specify the action to take on the profile’s owned objects (if any).
- Changing Your Password on Multiple Partitions
To change your password on multiple partitions at once, launch Access Client Solutions (ACS) and then choose Edit > Preferences > Passwords. Click on the partitions to be changed. Specify the old and new passwords and click Apply. Note: To change the password on multiple partitions at once, the password will have to be the same on those partitions.
Sidenote: If you manage multiple partitions, it’s likely that you have the same password on all of those partitions (even though that’s a terrible idea, from a security perspective). Look, I realize that security is a trade-off, so rather than set your password to be non-expiring (meaning you never have to change it), I’d rather have you change it regularly, especially if you have an easy-to-guess password, which is usually what happens if it’s not non-expiring and you are managing multiple partitions. Just make sure you have enabled TLS (encrypted) sessions so your user ID and password is not flowing in cleartext.
- Securing Your Navigator for i Connection
Speaking of securing connections, whether you’re using new Navigator for i or still using the old version (see previous article on staying current!), the connection is http not https, meaning that it’s not secure. In other words, anything you type, including the user ID and password used to authenticate, is sent in cleartext (not encrypted). When browsers stopped supporting self-signed certificates, IBM stopped shipping their self-signed certificate and the sessions reverted to http (cleartext). Because the vast majority of the activity performed via Navigator for i is done by an administrator, leaving this connection unencrypted allows the sniffing of powerful user ID/password combinations along with other activity. This support page provides instructions for securing the Navigator for i connection with your own digital certificate.
- Determining Which Profile’s Using a File Share
When you’re trying to determine whether a file share is in use, you can always go into Navigator for i > File system > File shares and then right-click on the share to determine whether someone is currently using the share. The problem is that this is a point in time. Using this method, you won’t see a profile that may have connected using a file share at some other time of day and is now disconnected. While seeing which profiles are currently connected is valuable information, this view in Navigator for i may not provide the entire picture.
To determine all jobs that have connected via a file share, use Authority Collection. At IBM i 7.4, IBM added the ability to determine the use of an object. In this scenario, start Authority Collection on the shared object. Let the collection go at least 24 hours and then display the collection, looking for jobs beginning with ‘QZLSFILE%’, which is the indication they have connected via a file share.
The following example uses the IBM SQL Service to display the Authority Collection of an IFS object. The first part of the WHERE clause qualifies the output to those jobs coming in via the NetServer—that is, attaching via a file share. The second part limits the output to the path_name associated with the file share you’re investigating.
SELECT check_timestamp,
authorization_name,
job_name,
path_name
FROM qsys2.authority_collection_fsobj
WHERE job_name LIKE 'QZLSFILE%'
AND path_name LIKE '/path_name_of_shared_object%';
Note that this example assumes that the shared object is in the IFS. If the shared object is in a library, you’ll need to use the qsys2.authority_collection_object service.
- Receiving Security Alerts and PTF Notifications
In my last article, I discussed the need to stay current and described the IBM Services that can help you. However, you need to be alerted to security issues as soon as they arise. If you haven’t already, I encourage you to sign up for alerts from IBM. You’ll need an IBM ID, but that’s the only requirement. If you’re not signed up, here’s a link to instructions from IBM. You can sign up for security alerts as well as notifications for other types of events, such as the release of a HIPER PTF.
Summary
I hope these features are all old news to you—that is, you know about and are already taking advantage of them. But if not, I hope you’ve found this article helpful and you’ll soon simplify your security administration by using some of these forgotten features.
LATEST COMMENTS
MC Press Online