Why a DB2 Violation Is Written To The AUDIT file On Behalf of the SECONDARY Authid?


Article ID: 50106


Updated On:


CA Cleanup CA Datacom CA DATACOM - AD CA CIS CA Common Services for z/OS CA 90s Services CA Database Management Solutions for DB2 for z/OS CA Common Product Services Component CA Common Services CA Datacom/AD CA ecoMeter Server Component FOC CA Easytrieve Report Generator for Common Services CA Infocai Maintenance CA IPC Unicenter CA-JCLCheck Common Component CA Mainframe VM Product Manager CA Chorus Software Manager CA On Demand Portal CA Service Desk Manager - Unified Self Service CA PAM Client for Linux for zSeries CA Mainframe Connector for Linux on System z CA Graphical Management Interface CA Web Administrator for Top Secret CA CA- Xpertware CA Top Secret CA Top Secret - LDAP CA Top Secret - VSE



A DB2 violation is written to the AUDIT file, because it has no permission to a DB2 table.

However, the violation is written on behalf of the SECONDARY Authid.

Without a DB2 TRACE, there is no way to determine the primary AUTHID involved.


CA Top Secret for DB2, similar to DB2, performs security based on the Authid the check occurs under and not the Primary Authid.

If a successful check or failure occurs against a Secondary Authid it, will be this id the event will be logged against.

In the CA Top Secret for DB2 documentation, there are numerous references to the disadvantages of using Secondary Authids.

One of the largest disadvantages is the loss of individual accountability.

The CA Top Secret DB2 Installation Guide section 'What Are Some of the Benefits?' documents the following:

With CA Top Secret Option for DB2 you do not need secondary authorization IDs. In fact, they can obscure the lines of individual accountability.

In the current design of the product there is nothing that can be done to alter this process.

Our recommendation would be to define TSS profiles to contain the permissions required from each of the Seconday Authids in the shop.
Then these profiles can be attached to the user who require the access and the Secondary Authids can be removed.

Below is an example of what the administration could look like this:

TSS CRE(XXprof) NAME('profile for XX resources') TYPE(PROFILE) DEPT(deptxxx)
TSS ADD(acidxx) PROF(XXprof)    

Once this setup is in place, then the SET CURRENT SQLID could be removed from the SQL and the Secondary Authid would no longer be required.
The resource check for this table would be satisfied on the check against the Primary Authid.


Release: TOPSDB00200-1.3-Top Secret-Security-Option for DB2 UDB