Resolving problems when access is allowed incorrectly

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 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 Security for 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, check that the SECURITY attribute on the TSMODEL resource definition is set to YES.
  • 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.