ca.portal.admin

R15 CVs CICS Transactions Coming From R16 CIYUH/CICSB to R15 CV

Discussion created by ca.portal.admin on Jul 24, 2006
Latest reply on Jul 26, 2006 by ca.portal.admin
HWIDMSSA/HWIDMSB Abending in RACF

Hello,



We just upgraded a couple of CVs recently from R150109 to R16 SP3. We
are experiencing various problems.

This is one of them.



1. When we execute a CICS application program from a CICS region that
is using Release 16 CINT/INTC interface

and the program attempts to connect to a R15 CV we receive a 1469 abend
following this USER(PUBLIC) GROUP(EXTERNAL)

revoked user access attempt.

2. The same CICS application from a CICS region that is using R15
CINT/INTC interface and R15 CVs is not having the problem

3. Tthe same CICS application from a CICS region that is using R16
CINT/INTC interface and R16 CVs is not having the problem.


HELP!

ICH408I USER(PUBLIC ) GROUP(EXTERNAL) NAME(WEB SERVER SAMPLE ID) 616


LOGON/JOB INITIATION - REVOKED USER ACCESS ATTEMPT


+IDMS DC201006 V61 T1 CV-Status  BE-TaskID Pri FE - ID1 FE - ID2 FE
+TaskCD
FE Us

+IDMS DC201006 V61 T1 ABRT SNON        380 100 CCUHBULK LTERM001 U163
PUBLI

ICH408I USER(PUBLIC ) GROUP(EXTERNAL) NAME(WEB SERVER SAMPLE ID) 885


LOGON/JOB INITIATION - REVOKED USER ACCESS ATTEMPT


+IDMS DC201006 V61 T1 CV-Status  BE-TaskID Pri FE - ID1 FE - ID2 FE
+TaskCD
FE Us

+IDMS DC201006 V61 T1 ABRT SNON        381 100 CCUHBULK LTERM001 U163




Multiple item definitions exist for this item
<<<<<<<<<


************************************************************************
****
*

ICH408I USER (userid) GROUP (group-name) NAME (user-name) or JOB


(jobname) STEP (stepname) {SUBMITTER (userid)} {resource-name}


{CL(class-name)} or {VOL(volume-id)}


{FID(file-identifier)} {ID(IPC-identifier)} or {FROM


generic-profile-name (G)} {ACCESS INTENT(intent) ACCESS


          ALLOWED(allowed)} {EFFECTIVE UID (nnnnnnnnnn} {EFFECTIVE GID


          (nnnnnnnnnn}





Explanation: This message is issued when RACF detects an


unauthorized request (a violation) made by a user or job. The
user


and group indicated in the first line of the ICH408I message
are


the execution user ID and group ID under which the job was to
run.





If the message indicates a job and step instead of a user,
group,


and name, RACF could not find a valid ACEE containing user,
group,


and name, RACF could not find a valid ACEE containing user,
group,


and name information. This could occur for a started task that
is


not defined in the RACF started procedures table (ICHRIN03), if
an


entry in the started procedures table has an incorrect RACF
group


specified, or if the user's ACEE has been corrupted. If the


submitting user ID is not the same as the execution user ID,
the


message includes an additional line containing the submitting
user


ID, group, and node.





FWhen the message is reporting an access failure for an z/OS
UNIX


file, the resource name is the pathname that was specified to
the


kernel syscall. It will not exist for the syscalls performed


against open files (those in the ""fxxxxx"" format such as
fchown).


The FID (file identifier) is a unique 32-hex-digit identifier
of


the file. It is provided because multiple pathnames can be used
to


access the same file. This identifier will allow matching of


accesses to the same file by different names.





When the message is reporting an access failure for an z/OS
UNIX


IPC key, the resource name is the IPC key name that was
specified


to the kernel syscall. It is displayed as a unique 8-hex-digit


identifier. The ID (IPC identifier) is a unique decimal
identifier


of the resource. It is provided as additional information, that


may be useful during auditing, although it is dynamically


allocated by the kernel. It is a numeric value between 0 and


4294967295.





The meaning of the volume serial number shown in the VOL field


varies. For a non-VSAM data set, it means the volume on which
the


data set resides. For a VSAM data set, it means the volume on


which the catalog containing the data set entry resides.





The phrase FROM generic-profile-name (G), if included in the


message, identifies the generic profile that RACF used to check


for access to the resource.





For further explanations of this message, check the message
line


that indicates what request was made. This is usually line 2 or
3.


For example, it could be INSUFFICIENT ACCESS AUTHORITY. Find
this


message line among the explanations that follow for message


ICH408I (arranged alphabetically), and read the explanation for


that message line.





For attempts to use protected resources, the message shows the


access attempted (ACCESS INTENT phrase) and the access
permitted


by RACF (ACCESS ALLOWED phrase). When the message is reporting
an


attempt to access an z/OS UNIX file or IPC key, the ACCESS
INTENT


(intent) is specified as ""RWX,"" representing read, write or


search/execute permission requested. More than one permission
can


be requested at a time. If a permission is not requested, the


letter is replaced by a dash ""-."" ACCESS ALLOWED (allowed) is


specified as ""{OWNER/GROUP/OTHER/ACL USER/ACL
GROUP/NO/RESTRICTED}


RWX,"" where OWNER indicates the owner permission bits were
used,


GROUP indicates the group permission bits were used, OTHER


indicates the other permission bits were used, ACL USER
indicates


GROUP indicates a specific group ACL entry (or entries) was
used,


NO indicates that no permission bits were used, RESTRICTED


indicates the OTHER bits were not used for a RESTRICTED user,
and


""RWX"" represents the settings of the permission bits that were


checked. ACCESS ALLOWED (NO --X) occurs if a superuser attempts
to


execute a file that does not have OWNER, GROUP, ACL, or OTHER


execute permission. ACCESS ALLOWED (RESTRICTED ---) occurs if a


RESTRICTED user could have only gained file access via the
OTHER


bits, but the RESTRICTED.FILESYS.ACCESS profile in the UNIXPRIV


class has forbidden this.





Note that while checking for group access, the group permission


bits are treated as simply another GID ACL entry, if the
process


GID, or one of its supplemental GIDs matches the file owner
GID.


Several group entries may actually be checked, and access will
be


granted if any of them specifies the requested permissions.


However, if none of the entries grants the requested access,
there


is no single entry that defines the access allowed. By
convention,


the permissions associated with the first relevant group entry


encountered are what will be displayed in the message. See the


z/OS UNIX information in the z/OS Security Server RACF Security


Administrator's Guide for a description of the algorithm used
to


determine access when an ACL exists for a file or directory.





For violations occurring in the UNIX System Services
environment,


the user's effective UID and effective GID are displayed in the


message. These ids were used to determine the user's privilege


for the intended operation. Note that they may not always match


the ids defined in the relevant RACF USER and GROUP profiles,


since UNIX System Services provides methods by which another


identity can be assumed.





System Action: If the phrase RESOURCE NOT PROTECTED appears in


the message with a warning, RACF allows the request to
continue.


If the phrase RESOURCE NOT PROTECTED appears in the message


without a warning, RACF fails the request.





Notes:





1. When a user is denied access to a RACF-protected resource


because of the return code from a RACROUTE REQUEST=AUTH


installation exit routine, the user's allowed access may be


inconsistent with the requested access. (For example,
access


allowed was ALTER, access requested was READ, but the
request


for access was denied.)





2. Authority checking for users with the restricted attribute


bypasses checking of some authority granting mechanisms,
such


as the UACC. If a LISTUSER for the user ID shows that the
user


is restricted, the user's user ID or group name must be on
the


access list to allow access to the resource. See z/OS
Security


Server RACF Security Administrator's Guide for additional


information on restricted access user IDs.








3. A user who has ALTER access authority to a DASD volume can


scratch a data set on that volume even if the user does not


have the required ALTER access authority to that particular


data set. In this case, on systems without always-call,


message ICH408I is issued even though the data set is


scratched; on systems with always-call, the message is not


issued.





4. The phrase ""LOGON/JOB INITIATION/initACEE"" may appear during


logon processing; however, the logon may be successful. When


RACF is active, logon verification can produce an error
during


RACF processing; however, the logon can proceed using an


alternate method (for example, UADS). This error occurs if
the


installation does not use the RACF database to store


security-related information for a particular user, but it


does use an alternate method (such as UADS) for the logon


application (for example, TSO) to perform user verification.








5. If the failure occurred for a z/OS UNIX System Services
system


function, RACF returns an error return code to the invoking


system function, which will return an error return code to
the


application caller or will cause the calling task to abend.


See z/OS UNIX System Services Programming: Assembler
Callable


Services Reference to determine the action of the syscall


functions.





6. If you see JOB/STEP, it indicates a default security


environment for an undefined user. This can happen if a


started procedure is not defined correctly in the STARTED


class or in ICHRIN03.





o If you used the STARTED class, make sure it was
properly


RACLIST REFRESHed after you added the profiles.





o If you used ICHRIN03, be sure to IPL the system with
CLPA.





User Response: Follow the security procedures established for


your installation. If no such procedures have been established,


report the complete text of this message to the RACF security


administrator.





Operator Response: Follow the security procedures established
for


your installation. If no such procedures have been established,


report the complete text of this message to the RACF security


administrator.





Problem Determination: Detailed information about the
violation


is available in the SMF type 80 record that RACF produces at
the


same time as this message. See z/OS Security Server RACF
Auditor's


Guide for information about reporting on the contents of the
RACF


SMF records.





Notes:





1. When RACF verifies a password during logon or when a batch
job


begins, the message includes NAME (???).





2. For users not defined to RACF, the job and step are
indicated


by jobname and stepname. For batch users, stepname is
blank.





Destination: Descriptor code is 4. Routing codes are 9 and 11.


This message is routed to the security console. All violations


(except LOGON/JOB initiation/initACEE messages, command


violations, and z/OS UNIX System Services violations) are
issued


as write-to-programmer (WTP) messages.





Note: A TSO/E user who is using z/OS UNIX System Services does


not see the ICH408I messages.


************************************************************************
****
*
Multiple item definitions exist for this item
<<<<<<<<<

************************************************************************
****
*
















Carol McLaughlin
Employment Development Department
Information Technology Branch
Production Operations Management Division Database Group Integrated
Database Management System (IDMS) Team
"
IDMS Public Discussion Forum
IDMS-L@LISTSERV.IUASSN.COM
SMTP
IDMS-L@LISTSERV.IUASSN.COM
IDMS-L@LISTSERV.IUASSN.COM
SMTP








Normal

Normal
Re: R15 CVs CICS Transactions Coming From R16 CIYUH/CICSB to R15 CV HWIDMSSA/HWIDMSB Abending in RACF
"Hi everyone,

CA let our system's DBAs know what the problem was and it is now resolved.
It had to do with our Thank you Steve for showing me where the information
is regarding the USER PUBLIC in the R16 Security Administration manual. The
solution below fixed our problem.

Below is the e-mail from our system's DBA:

John K. and Carol,

I talked with Bob from CA this morning.

The release 15 IDMS CICS interface to release 16 IDMS region is not
supported. The Release 16 IDMS CICS interface to Release 15 IDMS region is
supported.

To track down the RACF issue he would like us to convert all the interfaces
that run against the R16 loadlib to R16. The user ID is not getting passed
to IDMS R15 when the R15 interface is run from the R16 loadlibs. So, IDMS
assigns the user ID public. This user is then trying to access a protected
resource. Then we get the RACF error.

Back to me here:

So our systems' DBA relinked the R15 INTCs to R16 and this problem
disappeared.

Outcomes