<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:
SBMJOB CMD(DSPUSRPRF USRPRF(*ALL) OUTPUT(*OUTFILE)
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 …)
UPSPAU LIKE ‘%SECADM%’
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?