Programmers absolutely do not need *ALLOBJ special authority to perform their normal job functions. However, there are times when more "power" is required. This article describes your options for providing additional capabilities when the situation demands it.

What Constitutes an "Emergency"

The production application has bombed, the manufacturing line is down, and debugging the program reveals that the last enhancement caused an unexpected error. An incoming transmission dies and corrupts a production data file, so the data must be corrected "by hand" through a file editor. The programming staff doubles as the operations staff and is on call on a rotating basis. These scenarios probably sound familiar to you, and all of them constitute the need for programmers to have more authority and capability than they should normally have.

You need the ability to temporarily provide these capabilities rather than give programmers *ALLOBJ all the time.

Why not give *ALLOBJ special authority to programmers all the time? This is not a good idea for several reasons, and one reason is because *ALLOBJ allows programmers to bypass any change management software that you have in place. Another reason is that there is no way to keep programmers from accessing production data if both development and production occur on the same system--as is the case in many iSeries shops. Both of these issues raise data integrity concerns, and auditors are becoming increasingly intolerant of the practice of allowing programmers to permanently retain *ALLOBJ authority. However, I recognize (as do the majority of auditors) that some circumstances require "emergency access"--that is, more power than programmers traditionally have.

Giving and Removing *ALLOBJ

Several methods exist for giving users temporary *ALLOBJ authority if *ALLOBJ is absolutely required:

• One method is for someone with sufficient authority to modify the programmer's profile and give *ALLOBJ special authority. I am not in favor of this method because inevitably there will be a time when the administrator forgets to remove the *ALLOBJ. If this method is used, an automated process needs to be put into place that will automatically remove the *ALLOBJ. For example, a job could be scheduled to run at midnight that removes all programmers' *ALLOBJ.
• Some administrators prefer to provide two profiles for programmers--one without *ALLOBJ and one with *ALLOBJ. Both profiles are enabled, and the programmers are advised that they are only allowed to use the "powerful" profile in case of emergencies. Well, we all know what happens in this case. The administrator never keeps track of when the powerful profile is used, so the powerful profile is the only one programmers ever use! This option rarely works.
• Taking off on the method described above, the administrator provides the programmer with two profiles, but the only time the powerful profile is enabled is when the programmer is on call or when an emergency occurs. This is a far superior option to having the powerful profile enabled at all times, but it still requires that the administrator remember to set the profile to *DISABLED status when the programmer goes off call or the emergency is over.

Swapping to Another Profile

Some tools on the market allow programmers or administrators to "swap" to a powerful profile when they need additional power. These tools make use of the profile swap APIs, which change the profile that the process is running under. For example, Joe signs on and calls a program that has implemented the profile swap APIs. The program is coded to swap to QSECOFR. OS/400 changes the job so that the job is now running under the QSECOFR profile. Now, when Joe performs a task, he is doing so as QSECOFR, not Joe. The problem with this approach and the reason I don't recommend it is because it's difficult to track. The job name stays the same. As you probably know, part of the job name includes the user under which the job started. If the profile swap APIs are run, even though the process profile changes, the user portion of the job name doesn't. So if you're using Work with Active Jobs (WRKACTJOB) to display the status of active jobs, it appears that the job is still running as the original user. This issue flows into the audit entries produced. The user field that you normally monitor will now be QSECOFR instead of JOE. While you can find the user that is actually performing the task in the audit entry, it will cause you to look at the audit journal entries in a way that you are not used to and will absolutely cause you to re-work your queries and any audit journal reporting software that you might have.

Setting a New Group Profile

One technique that is very powerful yet seldom implemented is using the qsysetgid() APIs to change a user's group profile. Using the qsysetgid() APIs is similar to using the swap profile APIs. The difference is that the swap profile APIs swap in all of the user information--the user itself as well as the user's groups. The qsysetgid() APIs change only the user's first group profile and only for the current process. In other words, the user's group is changed only in the current job information, not in the user's profile. This method allows you to make the profile a member of the profile that owns the application that needs to be debugged. Simply call the API during the profile's initial program.

This method is very powerful because the profile is a member of the owning profile only during the time the profile is signed on. For example, the user's initial program is never run when the profile is used for FTP or ODBC. Therefore, if programmers try to use the profile outside of debugging the application, they will only have their own authority, not the authority of the owning group. I prefer this method to giving the programmers *ALLOBJ special authority or swapping to another profile.

Activating Emergency Access

Whatever method you use to give the programmer additional authorities, you have to decide how the emergency access will be "activated."

One method is to have an automated process that creates an emergency access profile "on the fly." I saw an implementation in which the programmer must fill out a Lotus Domino form that includes the justification for requesting the profile access. The form is forwarded to the Security Administration team, where the person on call approves the form. Once approved, the form kicks off a job on OS/400 that creates a profile. When the programmer signs off, the emergency access profile is deleted within an hour by a job monitoring for use of these profiles.

Another method is to have the profile created but always set to PASSWORD(*NONE) so it can't be used. Upon receiving the programmer's request and approving it, the administrator gives the profile a password and then changes it back to *NONE when the programmer is through. Or, better, an automated process can be put into place to automatically reset the password back to *NONE after a prescribed period.

For small shops with only a handful of programmers and one or two administrators, the emergency access process needs to be simple. One method that can be used is for the administrator to create an emergency access profile for each programmer. The profile can be configured to have a password that is placed in a data area for that profile. The data area is set to *PUBLIC *EXCLUDE and is authorized for access only by the particular developer. (All programmers would have their own profiles and data area combinations.) This solution is simple, but it has a couple of problems. The obvious issue is that the password is in cleartext. The way around this issue is through a bit of programming. Using the validation list APIs, tools can be written for the administrator to set the password and for the programmer to retrieve the cleartext password. To ensure that one programmer cannot retrieve the password of another programmer, a separate validation list is used for each programmer. The programmer is only authorized to the validation list containing the password for his or her emergency access profile.

The other issue that needs to be addressed is shutting off the programmer access to the profile. In other words, if the profile's password never changes, the programmer can use the profile indefinitely. To address this issue, you can turn on object auditing. Then, use message handling/monitoring software that monitors QAUDJRN audit journal for an audit journal entry that indicates that the validation list has been accessed. The next day, the administrator can reset the password and populate the validation list with the new password. Or, once again, you can implement an automated process that the administrator would kick off after being notified that a validation list had been accessed.

Monitoring What They Do

Despite the fact that the programmer has extra "power" only occasionally, you will want to monitor what the programmer does during this time. I recommend that you use the Change User Audit (CHGUSRAUD) command to turn on *CMD and *PGMADP auditing after the profile is created. *CMD causes all command strings run during an interactive sign-on session to be logged to the audit journal. Turning on *PGMADP causes an audit entry to be generated if adopted authority is the authority used to access an object. This will help you detect whether adopted authority is used inappropriately.

While logging the emergency access profile's actions is good, auditors are going to expect that a security administrator is reviewing and monitoring the logs--both the log that is kept for the emergency access requests as well as the activity logs generated. Depending on the organization, these tasks can be quite time-consuming. You may want to determine the inappropriate activities that you want to look for and write some queries to assist you in monitoring the activity.

There is no one right way to allow temporary emergency access for programmers. I hope this article has given you some ideas about what will work best in your environment.

Carol Woodbury is co-founder of SkyView Partners, a firm specializing in security consulting, remediation services and security assessments, including the risk assessment product, SkyView Risk Assessor for OS/400 and i5/OS. Carol has over 13 years in the security industry, 10 of those working for IBM's Enterprise Server Group as the AS/400 Security Architect and Chief Engineering Manager of Security Technology. Look for Carol's second book, Experts' Guide to OS/400 and i5/OS Security.

Carol can be reached at This email address is being protected from spambots. You need JavaScript enabled to view it..