We have recently had an external audit in which the auditors have recommended that we "lock down" or disable the QSECOFR user account on our iSeries. We are running SAP R/3 on the box. We have argued back and said that certain procedures (per IBM and SAP documentation) require the use of the QSECOFR account and not just an account which is a copy of QSECOFR. They have gone back to their roots and have yet to come back with a suitable counter argument. Can you please advise if it safe to disable the QSECOFR account and, if so, how to get around not using it when documentation directs you to. I understand, from a security perspective, that the account should not be shared, but in our case the account is managed solely by myself.
You ask if it is "safe" to disable QSECOFR. That's one of those "it depends" questions. Certainly it is allowed by OS/400. And you can always sign on to the console as QSECOFR even though it's *DISABLED (assuming, of course, you know the correct password.) That said, there are certainly times when you are instructed -- either in IBM documentation -- or by third-parties to sign on as QSECOFR and you may not be doing this at the console. Many of my clients have one person hold the QSECOFR password (typically a security officer or someone whose responsibility it is to monitor security events), then when it is needed it's given out and the reason logged. Once the task has been completed, the password is immediately changed. However, since you are the only one using this password, I would suggest that you turn on *CMD auditing for QSECOFR (using the Change User Audit (CHGUSRAUD) command to log all command strings entered. I would also recommend changing the password frequently (e.g., monthly) so that if it is somehow compromised, the duration would be relatively short. Hopefully one of these ideas will work for your situation and satisfy the auditors.
Dig Deeper on iSeries system and application security
Related Q&A from Carol Woodbury
Before changing password levels and upgrading operating systems on the AS/400, ensure the clients connecting to the NetServer do not need the old ... Continue Reading
Look in the audit journal (QAUDJRN) on the AS/400 for an authority failure message with the name of the library as the object name. Use the ... Continue Reading
When error messages arise concerning attempts to use a permanent system object without authority, find the source of the issue by looking for an AF ... Continue Reading