Troubleshooting
Problem
This document describes the process of trying to determine what a deleted user profile may have owned.
Resolving The Problem
If an administrator deletes a profile and also accidentally deletes the owned objects, it is possible to track what objects may have been deleted if security auditing is already being used at that time with QAUDLVL set with type *DELETE.
In the following example, user SMOHAMED deletes user profile COCO04 with the following command:
At the time it was deleted, the user profile owned a number of objects including job queues COCO401 through COCO405.
Using security auditing, it is possible to create an output file containing the deletes using the following commands:
Step 1: Create a file based on the correct field description file for DO journal entries:
Step 2: Create an output file from the appropriate journal entries. In this example, I also narrowed down the search with specifics for date and time.
Step 3: Look at the resulting file with the following command:
As you can see, it does not reference the owner of the deleted objects (COCO04) in each entry. However, in the three tests I made, the owned objects were listed immediately above the deletion of the profile. Therefore, the entries are not a definitive answer but at least give a list of everything the administrator deleted immediately before the actual deletion of the profile. Unless the administrator deleted objects right before going on to delete the profile, the list should be fairly accurate.
Appendix F of the Security Reference Manual contains tables that give the values for every field in the above file.
In the following example, user SMOHAMED deletes user profile COCO04 with the following command:
DLTUSRPRF USRPRF(COCO04) OWNOBJOPT(*DLT)
At the time it was deleted, the user profile owned a number of objects including job queues COCO401 through COCO405.
Using security auditing, it is possible to create an output file containing the deletes using the following commands:
Step 1: Create a file based on the correct field description file for DO journal entries:
CRTDUPOBJ OBJ(QASYDOJ4) FROMLIB(QSYS) OBJTYPE(*FILE) NEWOBJ(COCODELETE)
Step 2: Create an output file from the appropriate journal entries. In this example, I also narrowed down the search with specifics for date and time.
DSPJRN JRN(QAUDJRN) FROMTIME(083106 0730) ENTTYP(DO) OUTPUT(*OUTFILE)OUTFILFMT(*TYPE4) OUTFILE(COCODELETE)
Step 3: Look at the resulting file with the following command:
WRKF FILE(COCODELETE)
The following is shown:
Press F20 one time to get to the following screen:
Press F20 one time to get to the following screen:
As you can see, it does not reference the owner of the deleted objects (COCO04) in each entry. However, in the three tests I made, the owned objects were listed immediately above the deletion of the profile. Therefore, the entries are not a definitive answer but at least give a list of everything the administrator deleted immediately before the actual deletion of the profile. Unless the administrator deleted objects right before going on to delete the profile, the list should be fairly accurate.
Appendix F of the Security Reference Manual contains tables that give the values for every field in the above file.
For a report generated using the SQL Service QSYS2.DISPLAY_JOURNAL() refer to the following document:
[{"Type":"MASTER","Line of Business":{"code":"LOB68","label":"Power HW"},"Business Unit":{"code":"BU070","label":"IBM Infrastructure"},"Product":{"code":"SWG60","label":"IBM i"},"ARM Category":[{"code":"a8m0z0000000CHyAAM","label":"Security"}],"ARM Case Number":"","Platform":[{"code":"PF012","label":"IBM i"}],"Version":"All Versions"}]
Historical Number
425529717
Was this topic helpful?
Document Information
Modified date:
04 October 2024
UID
nas8N1014786