Is there a good site that explains output from TSS LIST commands?
1) when listing a TYPE=PROFILE, it lists the associated acids at the bottom. I notice some have -SC at the end of the acids, wondering what SC means...e.g. ABCDEF -SC
2) when listing a TYPE=USER I see some 'XA' statements...e.g. XA DATASET = abcd.abc; XA TSOACCT = abcd; XA OTRAN = 1234. Does XA means "direct permits" to that resource?
The XA DATASET= abcd.abc means a TSS PER(prof) DSN(abcd.abc) was done.
Same with other resources or ACID (TSS PER(prof) ACID(ABCD)
TEST99 -SC means a SCA...security type acid
you may also see
Just issue a TSS LIST on the ACID and you will get you answer
I can recommend docops.ca.com, some answers to your question you could find for example there: https://docops.ca.com/ca-top-secret-for-z-os/16-0/en/using/issuing-commands-to-communicate-administrative-requirements/command-functions/list-functiondisplay-acid-security-data
In docops there is also a search function.
When you are signed-in, you can submit comments and questions at the bottom of a chapter, which are handled by alert CA people! And I'd like to encourage you to feedback, if anything seems to be unclear or incomplete; clear and improved docs are a benefit for you and all other users !
Bobs, to answer your two specific questions: 1) Yes, the XA is permission to a resource. If it's in the user ACID I would call the permission "direct", but you'll also see them in profiles. If instead of "XA DATASET" you see just "DATASET" (for example), it means the ID owns the resource...which, as in RACF, implies full access to it as well. (For that reason CA mostly recommends that you not give ownership of a resource to a user ACID, although of course there can be exceptions.) And 2) as Robert Lynch partially said, "-SC" is an abbreviation that tells you the ACID is an SCA, a central security admin. ("Central" corresponds to system-level SECURITY, as opposed to group-level.) The other security admin types are:
MSCA: The master ACID (like IBMUSER, only in TSS you can name it anything)
ZCA: An user ID with administrative authority over every ID in its zone
VCA: An user ID with administrative authority over every ID in its division
DCA: An user ID with administrative authority over every ID in its department
LCA: The 'L' stands for "limit"; I've never used or created one, but the manual says "An LSCA is not associated with any specific zone, division, or department. It has the same capabilities as an SCA but rules of scope checking apply."
I was under impression if a user has SCA they can manage any TSS record but I'm finding this untrue as our new SCA user is getting:
TSS0207E INSUFFICIENT AUTHORITY FOR FUNCTION, TSS0208E TYPE=RESOURCE, AUTHORITY = XAUTH.
the following 2 commands was executed to give SCA access, thinking the DATA(ALL) covers all profile types, but it appears its only to "list" all profiles?
TSS MOVE(abcd) TYPE(SCA) TSS ADMIN(abcd) DATA(ALL,PASSWORD,PROFILE,SESSKEY)
instead of granting every resource types, is there a command to grant a new SCA user to administer all profiles in TSS?
The SCA has SCOPE to "manage any TSS record" however the ADMINISTRATION AUTHORITIES defines what the SCA can do.
For example site may have Help Desk SCA's and limit them to Unsuspend and Reset Passwords only.
But as a SCA they can perform this to all Users.
You can list out the SCA and see what Admin Auth it has, and tweak accordingly
Refer to the Top Secret User's Guide to get details on the various Admin Authorities.
----------- ADMINISTRATION AUTHORITIES PROGRAM = REPORT RESOURCE = *ALL* ACCESS = ALL ACID = *ALL* FACILITIES = *ALL* LIST DATA = *ALL*,PROFILES,PASSWORD,PWVIEW,SESSKEY,MFA MISC1 = *ALL* MISC2 = *ALL* MISC3 = SDT MISC4 = *ALL* MISC5 = *ALL* MISC8 = *ALL* MISC9 = *ALL*
Bobby, I think the key is this: You're right that making an ACID into TYPE(SCA) will allow it to manipulate all ACIDs, but there's also the question of which manipulations can be performed. If an administrator can list ACIDs, then being CENTRAL (SCA) means he can list all ACIDs—but it doesn't follow that he can change them. The TSS manual touches briefly on this under "Using", "Types of Administrative Authorities". It gives examples under "Using", "Creating Security Administrators", "Assign Administrative Authority". (Really we need them to number their sections so we can refer to them more easily.) But if you want a full description of the various authorities I think you have to start with "Using" / "Issuing Commands to Communicate Administrative Requirements" / "Command Functions" / "ADMIN Function—Grant Administrative Authority", which will get you a list of all the types of admin authority (ACID, DATA, FACILITY, MISC1 etc). Then you look up each of those authorities under "Using" / "Issuing Commands to Communicate Administrative Requirements" / "Keywords" / <ACID, DATA, FACILITY, MISC1 etc> for a detailed description of what each subfunction does.
For example, Under "Keywords" / "DATA Keyword with ADMIN—Determine the Authority to List Information", it says "Use the DATA keyword with the ADMIN command to give or remove CA Top Secret administrators the authority to list Security File information." Note it says to list information. If you want your admin to be able to update something, for example to give an ACID a permission to a resource, I think you need not DATA (or rather not just DATA) but also RESOURCE. To give an admin authority for a particular resource class you might say
TSS ADMIN(victim) DATASET(INFO,XAUTH,OWN,REPORT)
Or you could say ...DATASET(ALL) for all types of authority in the DATASET class. To do all resource classes, as you ask, use RESOURCE rather than a particular class name:
TSS ADMIN(victim) RESOURCE(ALL) ACCESS(ALL)
I recommend you look through all the subfunctions to see what each one does. TSS gives you very granular control over what each admin can do, but that means of course that you have to know more than just a single command to give that authority.
For the content that Robert Lynch refers to above, you'll find it in the documentation about assigning administrative authority (located under Creating Security Administrators) on the CA Top Secret DocOps space.
Hi everyone, thank you for your replies…
I find many instructions on google the commands to give the authorities needed but can’t find a command that lists what authorities they have.
This info does not appear to be in a simple TSS LIST(userid) DATA(A) command. Is there a command to list? regards
TSS LIS(userid) DATA(ADMIN)
Documented in the TSS User's Guide
Robert, that is the command! Thank you
HNA Mainframe Platform security
Bobby, when I do TSS LIST(myID) DATA(A) I see my own admin authorities. Same when I list someone else's. What do you see when — no, don't answer that. If you don't see admin authorities using that command, maybe the ACID doesn't have any. If you're sure it does, you may have to open a case with CA. But they wouldn't want you putting sensitive details here in the forum.
Hey Bob you are absolutely correct…I do see it in the last portion of the TSS LIST(userid) DATA(A) command!
The TSS LIST( userid) DATA(ADMIN) command from Robert Lynch also comes in handy just to list that portion.
Thank you guys!
Hi Bob, a TSS LIST(ALL) shows the following which I couldn’t find much info on. It has access to some resources and facilities..
Is TYPE=GLOBAL the same as RACF’s GLOBAL class?
ACCESSORID = ALL NAME = GLOBAL-RESOURCES
TYPE = GLOBAL SIZE = 14336 BYTES
TYPE=GLOBAL indicates that it is a reserved record.The TYPE=GLOBAL acids are:ALL, APPCLU, AUDIT, DLF, FDT, NDT, RDT, SDT, and STC.These acids can not be deleted.
So TSS LIS(ALL), you are listing what's in your ALL Record
Right, I think of the ALL record as a "fake ACID", although the TSS developers may not see it that way. You can treat it as an ACID with the usual commands—LIST, PERMIT and so on (though not DELETE as Mr Lynch pointed out). I don't suppose it looks like an ACID internally, though, which is why I whisper "fake" to myself when I call it an ACID. It's purpose, at any rate, is determine access that isn't specified by a user's own ACID or by any of her profiles. Anything you permit to the ALL record is applied to any user ID unless it's handled by some permission earlier in the search.
For instance, if I say PER(ALL) OTRAN(BELL), I'm saying anyone can use the BELL transaction. (EXECUTE access is the default so I don't have to specify it.) But I can still forbid it to a particular user by saying PER(exception) OTRAN(BELL) ACC(NONE); TSS sees that permission first, and acts on it, without ever getting as far as the ALL record.
I've never had occasion to use some of the "fake ACIDs" that Robert listed. But I can tell you that STC is a list of connections between started-task procs and the ACID assigned to each, RDT is a definition of all resource classes (like the dynamic CDT in RACF), FDT is for defining and using installation defined fields (and segments, I think), and the SDT, let's see...oh, I've never used that one either; it's for the calender and some other miscellany.
In a profile I’m in, I see that it owns dataset ABCD, which means I have all access.
I need to make it ABCD.123 read access, and everything else ABCD.* all access.
Is my first step to delete ownership from this profile and put it somewhere else? I can’t find the command to delete ABCD as owner.
Once I delete the owner, where do I assign it as the owner? I have a profile called ALL, is that an option.
After owner is defined, then I can define ABCD.123 and ABCD.* at the right level access to my profile?
Btw I see some profiles defined as 1234. and 1234 without the dot. Does the dot signify more than 1 qualifier
Bobby, I recommend you start a new thread for each new question, unless of course it's a followup to a old one. This one, I'd say, should be a new topic.
1) You probably realize it already, but if a profile owns DATASET(ABCD) then everyone in that profile has all access, not just you. Just sayin'.
2) There might be another way to do it, but yeah, I'd start by moving that ownership to some other ACID. If there's no user or group of profiles whom you want to have DATASET(ABCD) ACC(ALL) then move the ownership to a department ACID. (Definitely do not assign the ownership to ALL.) You can do this two ways (that I know of):
tss rem(profilex) dataset(abcd)
tss add(dept1234) dataset(abcd)
tss add(dept1234) dataset(abcd) undercut
The "undercut" argument means "yeah, I already understand that someone else owns that; take it away". Someone at CA may tell you I don't have the concept quite right, but that's how I understand it.
3) Yes, once you have the ownership assigned to an ACID without granting any access, you can then handle the permissions as you want to:
tss per(profilex) dataset(abcd.xyz) access(read)
tss per(profilex) dataset(abcd) access(all)
(You understand that "123" wouldn't be valid for a dataset name.)
4) IIRC you speak RACF, right? The matter of the dot in a dataset permission (or in any other class, for that matter) is about what you might expect. If you permit someone DATASET(ABCD.) (with the period) it's equivalent to ABCD.*.** in RACF; it permits to any dataset that starts with "ABCD.". (Not quite the same as ABCD.** in RACF, because that includes a dataset with just the HLQ and nothing else, but in TSS if you specify the period then there has to be a period in the DSN.) Without the period—DATASET(ABCD)—it's equivalent in RACF to ABCD*.**; the dataset must start with "ABCD". You see?
Hey Bob, thanks as always! Agree, should be new topic, got lazy! Lol
The “tss rem(profilex) dataset(abcd)” worked…somehow I was led to believe to use DSNAME(ABCD)
Reason I mention give ownership to ALL profile is I saw it as a profile with nobody in access list, made me believe it’s just a “holding” area. But then the name fields says GLOBAL-RESOURCE so its probably the same as RACF’s GLOBAL…used globally
The ABCD is owned by us in security so I defined ownership in our user profile reserved for security. But as owner, I couldn’t specify ABCD.123 READ only. So I will look into Department ACID as you suggested as I want to avoid creating a profile just for this sole purpose…
That UNDERCUT is a new concept to me…don’t see anything like that in RACF
And thanks for pointing out the difference in dataset masking ABCD vs ABCD with the dot…I fully understand…
If you're interested on further reading up on undercutting, you'll find information at the following DocOps locations:
Hi Kris, thank you for those links! As a lifetime RACFer it’s a concept I’m not familiar with and this helps, sorta kind of…
I was going over old emails in my In box and realized I meant to reply to this long ago. By now maybe anything I add is moot, but just in case:
Just now I don't remember what GLOBAL means in RACF. In TSS, what happens is that the algorithm looks at the user's permissions for a match to the access request. Failing a match there, it looks through the user's profiles. If it still didn't find match it looks at the permissions in *ALL*. ALL is a sort of profile-for-everyone.
Therefore if you put ownership of a resource in ALL, you're giving everyone full owner's access to that resource, which is probably not what you intended. Although I should add that I've never done that; maybe TSS treats the ALL record differently, prevents you assigning ownership to ALL or something. But in general CA recommends that you assign ownership to ACIDs that don't confer access, usually to department ACIDs. I don't hesitate to
tss add(user2222) dataset(user2222.)
...thus giving USER2222 ownership of his own datasets. But for anything more general than that, not so much.
UNDERCUT and RACF: As I recall RACF handles ownership differently. For one thing, it assumes that datasets with an HLQ of "USER2222" belong to USER2222; when USER2222 tries to access such a dataset, RACF doesn't even consult its access rules, it just allows it. For the rest, ownership is of profiles rather than of resources; the owner of a profile can change the profile, but cannot automatically access the resource itself. So I think this is another case (like "profile" and "global") where RACF and TSS use the same word but for different concepts; don't be fooled into thinking they're analogous.
(That gave me fits when I first set out to learn RACF 15 years ago. The guy who hired me said "sure, you can learn RACF from the manuals", and I said "sure, I can learn RACF from the manuals", and for the first six months I wondered tearfully "what was I thinking?!". A large part of that problem was the RACF manuals calmly using words such as "profile" and me picturing entirely the wrong entity. I got over it eventually. But it would have taken me much less time, and much less emotional wear and tear, had I tracked down someone who speaks both RACF and TSS and gotten him to explain a few things. It's one reason I like contributing to a conversation like this.)
I'd like to share some personal statements *), hoping they help to broaden your understanding and to answer some of your questions.
*) Please do not hesitate to feedback, when they would need to be corrected or amended...
(1) Keep in mind, that from a certain perspective Top Secret (actually: the security server product, because this is valid also for RACF and also ACF/2) acts as an inqiry system The access to a resource is alwaysdone by the operating system or the application. The operating system or the application (subsystems or vendor products etc.) just asks Top Secret or does not ask Top Secret, before it accesses the resource. It is alway up to the operating system or application, whether the access takes place or not. (2) Top Secret, if asked, can give principally three different answers like: "granted", "denied" and "do not know that resource". The path, how Top Secret comes to its decision/result is influenced in many ways, not only the specific authorisations permitted to the user-acid, to one of the tss-profiles attached to the userid or to the *ALL*-record. The decision depends among others from TSS-options (e.g. AUTH(...)) privileges of the user-acid (e.g. NODSNCHK), best match-algorithm and much more. @CA Technologies: It would be very interesting to make the complete decision-tree visible in a documentation... maybe it already exists ...
(3) The permissions in the *ALL*-record are effective according to the AUTH(...) option. Please see https://docops.ca.com/ca-top-secret-for-z-os/16-0/en/using/specifying-control-options-to-modify-your-security-environment/authmerge-records-for-search I did not try it, but I think, that you can NOT ADD ownership of resources to the *ALL*-record. You could use the '%' masking character to permit access to user specific resources, which contain the userid somewhere in the resourcename. See also https://docops.ca.com/ca-top-secret-for-z-os/16-0/en/using/setting-up-resource-definitions-and-ownership/resource-ownership/masking
(4) "Ownership" is a kind of circumstance, which could make the application (or operating system) to even skip the security call to TSS. For example JES2 does not even check access to a job(resclass JESSPOOL) when it determines, that the acting userid is "owner" of that job, if think, there is a similar behaviour for some db2 ressourceclasses and also datasets.And I guess, that is the reason, why datasets should be owned by a none-user-acid (department, division, ...), so that Top Secret is asked about permissions.
(5) UNDERCUT has supposably a different meaning in RACF, which I did nor research; in Top Secret it is a suboption, when you establish ownership and you have undercut already existing ownerships. Seehttps://docops.ca.com/ca-top-secret-for-z-os/16-0/en/using/issuing-commands-to-communicate-administrative-requirements/keywords/undercut-keywordtransfer-resource-ownership
Bob/Josef, thank you for taking the time to explain. I am making progress, it is always interesting learning a new "language" such as TSS. I have a couple more questions which I will mention on a new thread...regards
you're welcome, ... and, be prepared ... to experience some surprises ...