IBM Support

Problem: Is it possible to audit who enables profiles on the NetServer?

How To


Summary

This technote describes how to find who might have enabled a disabled NetServer user.

Steps

NetServer only audits invalid connection attempts as documented here: Security Auditing Data Not Logged for NetServer Profiles
If you believe NetServer requires auditing enhancements, we highly recommend to follow this link and make a request: Enhancement Requests for IBM i   
To audit and track which user might have enabled a user on the NetServer, we need to understand how auditing and the NetServer operate on IBM i. 
The NetServer server job, QZLSSERVER keeps a list in memory of disabled users. By default, when the NetServer is started, all users are enabled. To disable a user, the NetServer must receive QMAXSIGN consecutive incorrect login requests. To enable a disabled user, there are a few options such as using the GO NETS Menu, Navigator for I, restarting the NetServer or making a call to the QZLSCHSI API. Because IBM i is an object-based architecture, you can only audit objects on the system. There is no object to audit in this instance, only a list in the memory of a job. 

You can, however, audit the QZLSCHSI program which is used to enable disabled users. To do so we must first check to see if the QAUDJRN exists. Use the DSPSECAUD command to make sure security journal QAUDJRN exists is set to YES and you are tracking for Object Auditing operations *OBJAUD. It looks like this:
Security journal QAUDJRN exists . . . . . :  YES    
Current QAUDCTL system value  . . . . . . : *AUDLVL *OBJAUD
To turn on auditing on the QZLSCHSI program, we can use the command: 
CHGOBJAUD OBJ(QSYS/QZLSCHSI) OBJTYPE(*PGM) OBJAUD(*ALL)

When calls are made to the QZLSCHSI API, the information will be audited and recorded to the QAUDJRN. To see the results of who is calling the program, use the SQL statement: 
SELECT ENTRY_TIMESTAMP,                                             
       JOB_NAME,                                                    
       JOB_USER,                                                    
       JOB_NUMBER,                                                  
       ENTRY_TYPE,                                                  
       ENTRY_TYPE_DETAIL,                                           
       ACCESS_TYPE,                                                 
       ACCESS_TYPE_DETAIL,                                          
       OBJECT_NAME,                                                 
       LIBRARY_NAME,                                                
       OBJECT_TYPE,                                                 
       MEMBER_NAME                                                  
    FROM TABLE (                                                    
            SYSTOOLS.AUDIT_JOURNAL_ZR(STARTING_TIMESTAMP => CURRENT 
TIMESTAMP - 7 DAYS)                                                 
        )                                                           
    WHERE OBJECT_NAME = 'QZLSCHSI' 
This SQL statement can be run in interactive SQL or Run SQL Scripts. The results look something like this: 
 image-20250322001742-2
As shown previously, there are a few limitations. By auditing the program, we can see the User and the timestamp when they made a call to the QZLSCHSI API. However, we are unable to see the parameters set in the program call so we cannot figure out details such as which user was enabled. Additionally, the QZLSCHSI API is used to used for other functions on the system so you may see entries unrelated to enabling IDs.

Document Location

Worldwide

[{"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":"a8m0z0000000CLSAA2","label":"Integrated File System-\u003ENetServer"}],"ARM Case Number":"","Platform":[{"code":"PF012","label":"IBM i"}],"Version":"All Versions"}]

Document Information

Modified date:
04 April 2025

UID

ibm17228796