Top Secret

 View Only
Expand all | Collapse all

CICS transactions

  • 1.  CICS transactions

    Posted Jun 14, 2018 05:59 PM

    I'm from the RACF world trying to learn TSS.   I'm trying to find the TSS dataset profile that is denying me from accessing hlq ABCD.   I listed all TSS dataset profiles and evaluated the 'mask' profiles and none seem to fit ABCD.   the command I used to list:  TSS LIST(ALL) DATA(ALL) TARGET(=).     let me know how to go about...regard, bobby



  • 2.  Re: CICS transactions
    Best Answer

    Broadcom Employee
    Posted Jun 14, 2018 06:17 PM

    Bobby,

     

    Issue a TSS WHOHAS DSN(ABCD) which will show you all  PERMITs  for datasets that starts with the prefix 'ABCD'. That should help you locate the PERMIT you are looking for.

     

    Regards,

     

    Joseph Porto - CA Level 1 Support



  • 3.  Re: CICS transactions

    Posted Jul 13, 2018 01:18 PM

    Bobs, I had to go the other way, from TSS to RACF.  If you don't mind a little background, part of the problem is that in RACF a "profile" is any object in the database: a user profile is the definition of an ID, a group profile is the definition of a group, a dataset profile is a definition of access to one or more datasets, etc.  In TSS, a profile is a collection of permissions; these permissions can be assigned as a unit to one or more user ACIDs.  In this way a TSS profile is sort of like (but not exactly like) a RACF group.

     

    Another important difference is that RACF stores its permissions with the resource; you see who has access to a dataset by listing the relevant dataset profile, and if you want to go the other way, to see what resources a particular user or group has access to, you have to explore.  Probably easiest to load the DBU into DB2 and do a query.  In TSS, on the other hand, the permissions are stored with the user ACIDs and profiles; you list an ID (and its profiles) to see what access it has, but to see who has access to a dataset you do a WHOHAS as Joseph said, and the WHOHAS command does the exploring for you.

     

    One of my biggest problems learning RACF (I did it from the manuals rather than in a class, and it was a frustrating experience I wouldn't recommend) was not understanding how RACF uses the word "profile"—also "group" and a few others, for that matter.



  • 4.  Re: CICS transactions

    Posted Jul 13, 2018 03:25 PM

    BobB and JoePorto! appreciate your time!

     

    In RACF a profile is any security record…userid, group, dataset, opercmds, cics trans, jes, nodes, mq, etc.  they all have a profile and an accompanying access list (ACL) and a UACC (default access for users not on the access list).

     

    I notice in TSS there are groups and profiles comprising a userid.  I have 1 group and 5 profiles, why not use one or the other?

     

    As for my original question, I did the TSS WHOHAS DSN(xxxx) and got the following.

     

    TSS0318E  RESOURCE NOT FOUND IN SECURITY FILE

    TSS0301I  WHOHAS   FUNCTION FAILED, RETURN CODE =  8

     

    A bunch of datasets under this HLQ exists, so there must be some “default” TSS dataset security being used?   I am getting access denied and don’t know where to look.

     

     

     

    Bobby Sagami

    HNA Mainframe Platform security

    Tel:  310-781-4060



  • 5.  Re: CICS transactions

    Broadcom Employee
    Posted Jul 13, 2018 04:45 PM

    Bobby,

     

    A PROFILE is TSS is a grouping of resources.

    You ADD that PROFILE to a user and that user has access to the all the resources withing that PROFILE.

     

    GROUPs in TSS, hold the OMVS group which contains the GID.

     

    Can you do a TSS WHOOWNS DSN(xxxx), to see if that resource you are doing a TSS WHOHAS is defined as a TSS protected resource to TSS.

     

    Please be careful the security information you paste in the ticket since this is an open forum. Try to user generic names if possible. If this is not possible, please open a ticket and we can pursue your question in a much more secure manner.

     

    Regards,

     

    Joseph Porto - CA Level 1 Support

     



  • 6.  Re: CICS transactions

    Posted Jul 14, 2018 04:19 PM

    meaning a user that does not need OMVS don’t need be defined with a group?   TSS allows a userid to be created without a group, profiles only?

     

    Bobby Sagami

    HNA Mainframe Platform security

    Tel:  310-781-4060



  • 7.  Re: CICS transactions

    Posted Jul 14, 2018 05:37 PM

    Right.  Put right out of your head the idea that a GROUP in TSS is a collection of users (as it is in RACF); it is simply the holder for an OMVS GID.  The GROUP is then added to one or more users (like a profile), who then have the authority to use that GID while they're logged on to OMVS.

     

    As far as I know, that's the purpose of a GROUP.  You can't PERMIT resources to a GROUP, and as I discovered just now you cannot connect more than one GID to a GROUP either.  (When I tried, using the ADD command, it didn't add the GID, it replaced the previous GID with the one I "added".)

     

    In addition to GROUP, there's also DFLTGRP.  The documentation says that if the user doesn't specify which GID to use at logon then, and there's a DFLTGRP, that GID is applied.  If the user doesn't specify a GROUP at logon and there is no DFLTGRP, TSS uses '*' as the GID and the logon continues.  That's what the documentation claims, but in fact I usually find that a GROUP isn't sufficient for the user to do his business inside OMVS—apparently the DFLTGRP is necessary, even if the user has only one GID.

     

    However, most of the above is subject to correction by folks who really know what they're talking about, because I don't do much with Unix myself.  I've read The Cuckoo's Egg several times, and have started looking up things in the USS command reference, but I'm really pretty ignorant.  The above are factoids I've collected over the years.



  • 8.  Re: CICS transactions

    Broadcom Employee
    Posted Jul 16, 2018 10:28 AM

    Bob,

     

    From a CA Top Secret standpoint, CA Top Secret doesnt require an OMVS segment (UID, GID, GROUP, DFLTGRP, HOME...etc), but USS does.

     

    CA Top Secret just holds the OMVS Segment information and passes it when USS requests it. It really doesnt do anything with it. Its USS that requires it.

     

    Its USS that will look at the OMVS segment information, validate, verify it and complain if its doesnt like something or if something is missing and not CA Top Secret.

     

    Joe



  • 9.  Re: CICS transactions

    Posted Jul 13, 2018 08:42 PM

    Bobby, Joseph can correct me if I get this wrong, but when I see that message here's what I think:  There is no specific rule governing access to it.  In that case, if the resource is "defined" to TSS (ie if there's an owner for it) then it's inaccessible.  If no owner has been assigned to it either, then access to it is governed by the default access level specified in the RDT, the collection of class definitions.  For instance, at one of the installations I manage if a CICS transaction has no owner then anyone can execute it; but as soon as I define an owner for it (some department ACID usually) then no one can access it until I permit access to it.



  • 10.  Re: CICS transactions

    Broadcom Employee
    Posted Jul 16, 2018 10:35 AM

    Bob,

     

    Anything not defined to CA Top Secret, it not secured by CA Top Secret. You have to first define it to CA Top Secret to secure it with CA Top Secret.

     

    The only exception is:

    1. Dataset and volumes which are protected by default.

    2. If the DEFPROT attribute is setup in the the RDT for the resource class. DEFPROT sets default protection to the resource class.

     

    Joe



  • 11.  Re: CICS transactions

    Posted Jul 17, 2018 01:55 PM

    Hi BobB, that is a difficult logic to comprehend…lol!

     

    I don’t see any TSS profile for this particular datasets, no owner either.  And yet a started task is reading these datasets.

     

    You wrote “then access to it is governed by the default access level specified in the RDT, the collection of class definitions”…where do I find this?  Is this the TSS parm member where all the global options are set?

     

    On a separate note, does it affect user access if user profiles are in a different order?  I would think it shouldn’t matter but wanted to make sure..

     

    Thanks again!

     

    Bobby Sagami

    HNA Mainframe Platform security

    Tel:  310-781-4060



  • 12.  Re: CICS transactions

    Posted Jul 17, 2018 05:47 PM

    Hello Bobby,

    Ownership and permissions to a userid or its profiles are not the only criteria to decide, whether a user is granted access to a dataset. The best way to get a closer look at Top Secret’s decision is to use TSSSIM. With TSSSIM you can inspect the decision of an access request of a userid to a dataset or any other resource, Specify TRACE YES in the simulated request. I‘m pretty so sure you will be surprised sometimes ....

     

    You can display the resclass definitions by executing TSS LIST(RDT).

     

    For your separate note: It is up to you, whether you want the sequence of the profiles to be relevant or not. So, have a look at the AUTH control option. You‘ll find details about it in docops.ca.com!

     

    Cheers,

    Josef



  • 13.  Re: CICS transactions

    Posted Jul 17, 2018 07:56 PM

    To add some detail to Joe's answer:

     

    One possible reason a started task may be reading a dataset, even though the dataset has no owner and no permissions, is that the ACID that runs the started task has NODSNCHK, an attribute whose meaning I suppose you can figure out.  The manual says that really should be assigned only during disaster recovery, and I heartily agree, but I've seen it applied distressingly frequently to machine (not human) IDs.  Very sloppy in my opinion.

     

    Another possibility is if the STC list in TSS has assigned "*BYPASS*" (instead of a real ACID) to the particular started task, or if the proc isn't defined in the STC list and the default value is *BYPASS*.  Such STCs are allowed all access—security checks are bypassed, in other words.

     

    You can look at the STC definitions by doing a LIST command on "STC" as if it were an ACID.

     

    As Joe hinted, "RDT" is another entity you can list as if it were an ACID.  That'll show you a definition of every resource class.  I keep thinking the DEFACC field shown there is the default access level for a resource that isn't defined, but it ain't so; I believe DEFACC is actually the access level that is assumed during a PERMIT command if you don't specify.

     

    Profile order: In most TSS installations I've worked at, the profile order does matter.  This is both a strength and a complication; it allows you lots more power in controling access, but it also can result in unexpected interferences.  I've written a few REXX programs for this problem, for example one that lists all users that have two profiles in the "wrong" order, so I can find and fix them once I've discovered the problem.  As Joe said, there's a TSS parm that controls whether the profile order is important; when it does, TSS searches first the user's list of "direct" permissions, then the permissions of each profile one by one, then the ALL record, and stops looking when it finds a match.  I regard this behavior as normal, but your installation may be using a different AUTH setting.