Why Is RESOURCE DB2(DSNR..) Bypassing Being Reported As OK+A In The TSSUTIL Report?

book

Article ID: 50368

calendar_today

Updated On:

Products

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

Issue/Introduction

Description:

Why was the security check for the resource DB2(DSNR...), which was granted access through the NORESCHK bypass attribute being reported as OK+A instead of OK+B in the TSSUTIL report?

Solution:

The 'DSNR.' resources need special code to be handled correctly. The security call comes in as a class of DSNR and CA Top Secret converts it to a class of DB2 with 'DSNR.' being appended to the beginning of the original resource name.

Because of the way the special code was implemented, the normal mechanisms CA Top Secret uses to communicate on internal security calls cannot work properly.

CA Top Secret is able to determine that the security call is supposed to be written to the audit file, but CA Top Secret can't determine whether it is supposed to be an OK+A event or an OK+B event.

The event will be recorded as OK+A even though access was granted through the NORESCHK attribute.

Environment

Release:
Component: AWAGNT