There could be many reasons why a user might have access to a protected
resource, even when you think that the user should
not have
that access. Here are some checks that you can make to investigate this kind
of situation:
- Confirm which userid the user is signed on as. (Make sure the user has
actually signed on and is not acting as the CICS® default user.) You can ask the user
to sign off, then sign on again. You can also ask the user to issue EXEC
CICS ASSIGN or EXEC CICS INQUIRE TERMINAL, which can be issued with the CECI
transaction (or a user-written transaction).
- Make sure that the SEC system initialization parameter is SEC=YES for
the CICS region the user is signed on to.
If SEC=NO is specified, users
can access any resource.
- If the user is running a transaction that communicates with other regions
such as application-owning regions (AORs) or file-owning regions (FORs), make
sure that the SEC system initialization parameter is SEC=YES for those regions.
- Is prefixing correct?
- Has the CICS JOB been submitted by the correct USER?
- Is SECPRFX set correctly?
- Has an installation-written SAF exit been used to return a different CICS
region userid when RACROUTE=EXTRACT has been specified?
- Depending on the resource, make sure that RESSEC(YES) is specified for
each transaction that might access that resource.
- Is the appropriate Xname CICS system initialization parameter correctly set?
For example, if it is a file control request, is XFCT=YES or XFCT=value specified?
If the Xname parameter specifies a value other than
YES or NO, does the value show the correct installation-defined class name?
- Is the transaction exempt from transaction security? (For information
on transactions that may have been defined in this way, see Category 3 transactions.)
- Does the transaction have the correct RESSEC and CMDSEC options?
- Check that the RESSEC setting on the MIRROR transaction is correct.
- If the resource is temporary storage, are you using the correct TST? Check:
- The DFHTST TYPE=SECURITY entry in the TST
- That TST entries are in the correct order
If you are using TSMODEL resource definition, check the SECURITY option
of the model.
- If intersystem communication is involved, check the following:
- Is a SECURITY REBUILD required (on this or on the remote system)?
- If ATTACHSEC=LOCAL is specified, does the SECURITYNAME userid have access
to the resource?
- Is ATTACHSEC=IDENTIFY specified?
- Is link security being bypassed because the link userid matches the local
region userid?
- Is the remote system using the same RACF® database?
- Do you have any RACF installation exits?
- To check the profile that you think protects the resource, use the checklist
provided in the z/OS Security Server RACF Security Administrator's Guide.