AS/400 security: remove backdoor to changing user profile rights

5 pts.
AS/400 Permissions
AS/400 security
how do i find a program which is a backdoor which allows user to change his authority to qsecofr or *secadm? We have changed his profile and he keeps changing it back. And yes we have changed the security officer password numerous times.

Answer Wiki

Thanks. We'll let you know when a new response is added.

<pre>Years ago (another job in the past) we had a CL program that was compiled by SECOFR *OWNER that called command line (QCMD or QCL).
Only a few in development knew about it, but it was an emergency “back door” in case we needed SECOFR access to the prod system.

Once you called that pgm you could do almost whatever you needed.
It might be something like that…?

After you determine which profiles have the authority to CHGUSRPRF, use the DSPPGMADP for each account for a list of programs which adopt authority. When you find the program which updates profiles, verify if it is legitimate (for your environment) and who has authority to the program else delete.

You can also DSPJRN of your QAUDJRN to view who or what has updated that user profile. Check your sysvals for QAUDCTL and QAUDLVL to verify it is activated, if not change the value(s). Then CHGOBJAUD for the user profile and whenever it is changed, the audit journal will catch it.


Shouldn’t someone tell this person that they are violating the orgs security rules and that a repeat of the issue will result in termination. I would think you need to disable this person’s log-in until they agree.

The history log would, I believe, give some information on this change.

1. Determine who has qsecofr or *secadm authority
2. Get a list of all program object owned by these id’s
3. Reduce the list to just the programs that use owner authority
– either one of these contains the code
– one of these calls a program with adopted authority that changes contains the code

<– this could include a command line within a screen that uses QCMDEXEC provide again that the program has
object owner authority and is owned by an id with the authoritys.

4. This command could be issued from navigator but only by an id with that level of authority.


You make it sound as if the user is intentionally changing his/her authority.
Not a programmer, operator, sysadm, database administrator, auditor but a user?
They don’t generally have this skill, knowledge or the reason.
They generally do what they’ve been told.

If this is an intentional action by the user, then we, your loyal advisors, have a consensus:
1. You shouldn’t have to search for their method of breaking the security.
2. The user should tell you what he/she did.
3. The user should be given a time-out and forced to sit in the corner with a pointed hat.
At first we had a harsher penalty, but in cases like this the death sentence has been ineffective.

Of course, the user might be innocent and a program he/she is running is doing this.



They may be using another profile that has the same authority as QSECOFR signing on as that user and changing their own profile.
You can create a file of the current user profile data and use Query to see if there is a profile or profiles may be using.

First create a file that will contain current user profile information:


Now you can query the “PROFILES” file created to find unused profiles, under-secured profiles and other profile problems.

Now Query the file (WRKQRY) to see which profiles have the SECADM special authority.
This record selection will display all user profiles with SECADM:

Field Test Value (Field, Number, ‘Characters’, or …)

You may also want to look at all profiles with *ALLOBJ. On a secure system basic users should have *NONE.

We believe we’ve given you useful technical and policy advise.
Have we given you what you need?

Discuss This Question: 8  Replies

There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when members answer or reply to this question.
  • Kevin Beaver
    I wouldn't just keep playing this cat and mouse game. This sounds like an issue that management needs to get involved in before you have a security incident on your hands.
    27,520 pointsBadges:
  • DanD
    Your company must not be in an audited or regulated environment. Even so, you should have a company security policy that would make it easy to fire the person doing this, and set up basic system security. First, if this is a user and not a programmer, they should be lmtcpb *yes and not have access to a command line. Any user that has a command line should be security audited and the audit journal reviewed regularly. Programs that adopt owner authority should be reviewed, and jobds with a user profile specited should be secured. You need a security specialist before you loose data due to malicious intent or even an accident.
    2,865 pointsBadges:
  • Littlepd
    Totally agree. This person should be fired.
    1,130 pointsBadges:
  • Yorkshireman
    This just arrived As a last resort, if you can't pry all object authority away from a user profile, then you should at least be journaling activity for each programmer user profile that has this authority granted. While this will provide after-the-fact reporting, at least you will have a track record of events. To set this up, security journaling must be active. Then you can use the "Change User Auditing" (CHGUSRAUD) command to configure what you want to track for the user profile in question. For more information on how to set this up, refer to this tip on monitoring your System i super users. Even if you are able to remove all object authority for most of your programming staff, I'd recommend taking this approach for every user profile on your system that has full access to the system. from here,289483,sid3_gci1363560_mem1,00.html?track=NL-180&ad=719431&asrc=EM_USC_8905756
    6,085 pointsBadges:
  • Yorkshireman
    the link to the source got lost this is it and in text !,289483,sid3_gci1363560,00.html?track=NL-180&ad=719431&asrc=EM_USC_8905756&uid=7813368
    6,085 pointsBadges:
  • graybeard52
    IMHO, Yorkshireman has the right answer. With security auditing, you will know where, who, when, and how it got changed. With that evidence, you could then take whatever steps are needed.
    3,115 pointsBadges:
  • WoodEngineer
    Perhaps this will help. We added an exit point program that runs after a user profile is changed. It sends me a message of the user profile that was changed and the user who made the change. I believe the program came from IBM. We added a little code to send the message. It may be possible to trap that someone is changing their level of authority. Exit Exit Point Point Format Registered Text QIBM_QSY_CERT_APPS CERT0100 *YES Applications using certificat QIBM_QSY_CHG_PROFILE CHGP0100 *YES Change User Profile - after change
    8,225 pointsBadges:
  • Kevin Beaver
    These are all great technical tips. You still need to get management involved if you're going resolve this issue long term.
    27,520 pointsBadges:

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

To follow this tag...

There was an error processing your information. Please try again later.

Thanks! We'll email you when relevant content is added and updated.


Share this item with your network: