CSFKEYS Security Violation for Authorized User
Article ID: 13752
Updated On:
Products
Issue/Introduction
We have a user (USERA) attempting to query a symmetric key that’s been registered to our ICSF CKDS. In prep for the query, we have established the following permissions under CSFKEYS to permit READ access for ACID USERA …
CSFKEYS = PKWKEY OWNER(DTECH )
XAUTH = PKWKEY.* ACID(USERA )
ACCESS = READ
TSS0300I WHOHAS FUNCTION SUCCESSFUL
The USERA user signed on to CICS and issued the following CICS command string to test access to a registered key in the ICSF CKDS:
CECI QUERY SECURITY RESC(CSFKEYS) RESID(PKWKEY.MF.DL.HASH) RESIDL (17)
As a result, the user receives the following error and return codes …
TSS7257E Unauthorized Access Level for CSFKEYS <PKWKEY.MF.DL.HASH>
The CICS response codes for READ, UPDATE, CONTROL and ALTER are as follows:
36 – NOTREADABLE
38 – NOTUPDATEABLE
57 – NOTCTRLABLE
53 – NOTALTERABLE
Performing a search for TSS7257E showed the following message details …
UNAUTHORIZED ACCESS LEVEL FOR RESOURCE resource
Reason:
An attempt was made to access a resource at the wrong level.
Are there additional TSS options that need to be configured to permit ACID USERA the appropriate READ access from CICS?
Environment
Component:
Resolution
TSS MODIFY FAC(CICSPROD) reveals that the NORES attribute is set for the FACILITY which prevents PERMITs for generic resource from being loaded.
Please issue a TSS MODIFY FAC(CICSPROD=RES)
If that resolves the problem, please put:
FAC(CICSPROD=RES)
in the TSS parmfile to make the change permanent.
There is no detriment going from NORES to RES.
NORES was used during a time when storage was a premium and 31bit storage didnt exist. With the abundance of stroage nowadays, it is really no longer needed and obsolete.
Feedback
