Top Secret

We are in the process of installing z/OSMF. One of the steps is to define the z/OSMF facility.

The documentation show this:

TSS MODIFY FACILITY(USERn=NAME=ZOSMF) where n is an unused number in your system.
TSS MODIFY FACILITY(ZOSMF=MODE=FAIL)
TSS MODIFY FACILITY(ZOSMF=...)

where '...' is any other FACILITY control options that you want to override the default settings.

Since we are new to z/OSMF is there any options that should be specified or are the default settings adequate ?

Just for info - what number did you use ?

Any other suggestion are appreciated.

Thank You

Top Secret provides predefined Facilities USER1, USER2....

You would modify these to your new facility. So for example

To find if the predefined USERx is available you would issue:

example:

TSS MODI FAC(USER50)

TSS9550I FACILITY DISPLAY FOR USER50
TSS9551I INITPGM=*** ID=50 TYPE=099
TSS9552I ATTRIBUTES=ACTIVE,SHRPRF,ASUBM,NOABEND,MULTIUSER,NOXDEF
TSS9552I ATTRIBUTES=LUMSG,STMSG,SIGN(M),INSTDATA,RNDPW,AUTHINIT
TSS9552I ATTRIBUTES=NOPROMPT,NOAUDIT,RES,WARNPW,NOTSOC,LCFTRANS
TSS9552I ATTRIBUTES=MSGLC,NOTRACE,NOEODINIT,IJU,NODORMPW,NONPWR
TSS9552I ATTRIBUTES=LUUPD
TSS9553I MODE=FAIL DOWN=GLOBAL LOGGING=INIT,SMF,MSG
TSS9554I UIDACID=8 LOCKTIME=000 DEFACID=*NONE* KEY=8
TSS9566I MAXUSER=03000 PRFT=003
TSS0300I MODIFY FUNCTION SUCCESSFUL

Example of a USERx already used:

TSS MODI FAC(USER2)

TSS9186E The Facility name is invalid no such facility name.
TSS0301I MODIFY FUNCTION FAILED, RETURN CODE = 8

In you Top Secret Parmfile you can see what Facility Name replaced USER2

USER2=NAME=newfacname  

Mark,

The default FACILITY setting are adequate for most 3rd party applications:

TSS MODIFY FACILITY(USERn=NAME=ZOSMF) where n is an unused number in your system.
TSS MODIFY FACILITY(ZOSMF=MODE=FAIL)

Should be sufficient. You don't really need MODE=FAIL unless you want to override the global mode. Most likely you are running MODE=FAIL, so its not really needed.

Then you need to add the FACILITY to the z/OSMF started task:

TSS ADD(zosmf_stc_acid) MASTFAC(ZOSMF)

All users signing on to z/OSMF will need authorization to signon to the new FACILITY via:

TSS ADD(acid) FAC(ZOSMF)

Setup is just like setting up a FACILITY for any 3rd party application that has a multiuser address space.

Just also wanted to mention that TSS MODIFY commands are temporary. They go away after the recycle of TSS or IPL.

You need to put the above in the TSSPARM file to make the changes permanent.

 FACILITY(USERn=NAME=ZOSMF)
 FACILITY(ZOSMF=MODE=FAIL)

Regards,

Joseph Porto - CA Level 1 Support

Joseph,

many thanks for above sumarization,

I'd like to extend the original question to be asked for any (3rd party) vendor product, e.g. Compuware and so on, for which the vendor does not supply mandatory or recommended specifications for the setup as a Top Secret (CA) FACILITY; or is not able to supply those specifications: 

Would FACILITY(USERn=NAME=my_facility_for_vendor_product) plus defaults of such a TYPE=099 facility be presumedly correct and we have just to wait and see, whether problems appear or not......

Or, are some of the facility attributes to be scrutinized? If yes, which would you recommend to have a closer look ...     

Regards and thanks,

Josef

.

Joseph,

The facility ID settings need to go into the TSS Parameter File "if and only if" you are running with "FACSTOR(NO)" in effect.

If "FACSTOR(YES)" is in effect, then the facility ID settings are hardened to the VSAMFILE dataset.

John P. Baker

Josef,

My recommendations apply for Compuware and other 3rd  party applications also.

TYPE like INITPGM is really obsolete. Not really needed anymore.

Setting RES attribute and MODE is really the only other two that I recommend when defining the FACILITY aside from what was already mentioned. Example:

FAC(ZOSMF=RES)

FAC(ZOSMF=MODE=FAIL)

Regards,

Joseph Porto - CA Level 1 Support

Hi Joseph,

may I add some additional question in this context and could address a general - and important - aspect:

Q1: What are the consequences, when an application server like ZOSMF or a Compuware produce et cetera is NOT defined as a Top Secret Facility (FAC)? Or, the other way round: What is the importance to define such server-applications as Top Secret FAC?  

I noticed for example, that events in the ATF or SMF-80-records are then related to FAC(STC).

Q2: Beyond the control to login to such application servers by FAC (dependant from the code in the application server, it could control logon also by a security call to the APPL-resclass or a user-defined resclass $xxxxx.LOGIN): What ist the behavioral difference between a TYPE=002 (STC) FAC and a TYPE=099 (USERx) FAC?     

Q+A3: If it is generally important to define an application server (like ZOSMF or a vendor product) as Top Secret FAC and a vendor does not supply sufficient info's how to define that FAC, you gave the answer in your previous posts.

Many thanks and kind regards,

Josef

Josef,

Q1: What are the consequences, when an application server like ZOSMF or a Compuware produce et cetera is NOT defined as a Top Secret Facility (FAC)? Or, the other way round: What is the importance to define such server-applications as Top Secret FAC?  

I noticed for example, that events in the ATF or SMF-80-records are then related to FAC(STC).

Answer:

A FACILITY is required to be defined. It lets TSS know that the application is a multiuser address space. FACILITY STC and BATCH are for single user address space which means only one user is only allowed to signon to the address space. If a second user attempts to signon, the first user will get signed off and the second user will get signed on.

Q2: Beyond the control to login to such application servers by FAC (dependant from the code in the application server, it could control logon also by a security call to the APPL-resclass or a user-defined resclass $xxxxx.LOGIN): What ist the behavioral difference between a TYPE=002 (STC) FAC and a TYPE=099 (USERx) FAC?     

Answer:

STC FACILITY is used for started tasks that only have one user signed on. If its a multiuser address space, then you will need to define a FACILITY for it. See explanation in Q1. 

Q+A3: If it is generally important to define an application server (like ZOSMF or a vendor product) as Top Secret FAC and a vendor does not supply sufficient info's how to define that FAC, you gave the answer in your previous posts.

Answer:

Any application including z/OSMF and Compuware products that is a multiuser address space, needs a FACILITY defined. This lets TSS know that the address space will have multiple users signed on concurrently to the address space like CICS. Creating a FACILITY for the various multiuser address spaces is pretty much the same with default security settings. The differences are the names being used for the FACILITY. Of course you can set different security setting for each of your FACILITYs. See the following knowledge document for an example FACILITY with default security setting.

Create a FACILITY for RDZ and assigning access to - CA Knowledge 

Joseph,

many thanks for the detailed answers!

I‘d just like to question the term „multiuser addres space“. 

Is a server address space (stc), which does security checks for client userid‘s different to the Stc-userid, (I guess, this is authorized code) a „multiuser address space“?

If it is not a multiuser a.s. in the strict sense, would it make sense resp. would it be  still necessary to define a FACILITY for this server?  For example for performance reasons?

many thanks,

Josef

Josef,

If the application running in the address space was designed to support multiple users to be signed on to it concurrently like CICS, then its a multiuser address space and FACILITY should be created for it. For details see:

Multiple User Address Space - CA Top Secret® for z/OS - 16.0 - CA Technologies Documentation 

If the application doesnt support multiple concurrent users signed on, the STC FACILITY should be used. You can create a FACILITY for a single user address space, but not usually done by CA Top Secret users. The STC FACILITY is what everyone uses. When you define the FACILITY you need to specify the attribute SUAS. Documented here:

FACILITY—Control System Facility Processing - CA Top Secret® for z/OS - 16.0 - CA Technologies Documentation 

Regards,

Joseph Porto - CA Level 1 Support

Joseph,

Many thanks for your answers! 

To realize your definition of a multi user address space: When you find INI-records and TRM-records (LOG(INI), TSSUTIL ATF/SMF80) of different time-shared userids within a single server address space  (started task), then it is a multi user address space and a FACILITY should be defined for that instance. Correct?

If you unconsciously do not (or forget to) define a FACILITY, what are the possible consequences or effects?

Or, in other words, which kind of problems would lead you to the fact, that a FAC definition is missing? 

Regards,        

Josef

Josef,

Questions:

1. To realize your definition of a multi user address space: When you find INI-records and TRM-records (LOG(INI), TSSUTIL ATF/SMF80) of different time-shared userids within a single server address space  (started task), then it is a multi user address space and a FACILITY should be defined for that instance. Correct?

 Answer:

Correct. If you see many signons and signoffs for different acids in a single server address space, then its a multiuser address space and a FACILITY should be defined.

2. If you unconsciously do not (or forget to) define a FACILITY, what are the possible consequences or effects?

Or, in other words, which kind of problems would lead you to the fact, that a FAC definition is missing? 

Answer:

Since you didnt define a FACILITY, you probably assigned the STC FACILITY to the address space. Regular type users are generally not authorized for the STC FACILITY, therefore your users will get FACILITY NOT AUTHORIZED security violations for the STC FACILITY and the user was not allowed to signon.

If the user is authorized for the STC, you notice that only one user is allowed to signon at anytime. So if you signed on, then I attempted a signon, you will get forced off so I can signon. If another user signs on, I will get forced off, and the 3rd user will signon. As you can imagine, this will cause lots of problem. Users will get unexpectedly signed off.\

Regards,

Joseph Porto - CA Level 1 Support

Joseph,

many thanks again for your clearifications.

Just to sum up in one sentence (as you already wrote in this thread) 

The definition of a Top Secret FACILITY is required for a multi user adress space to provide proper security behavior.

Best regards,

Josef 

Josef,

There are predefined multiuser FACILITYs that we give you like CICSPROD, CICSTEST, IMSPROD, IMSTEST,....but most people like to create their own FACILITYs with more meaningful names than use the predefined multiuser FACILITYs.

Regards,

Joseph Porto - CA Level 1 Support

Joseph,

Predefined facilities have a different TYPE=nnn. I've read, that one should not change TYPE=nnn of a facility. What is controlled by these different TYPE=nnn? What would happen, if FAC(CICSTEST) is used for a vendor multiuser server? Or should vendor multiuser server have always TYPE=099?

Regards,

Josef   

CICSTEST FACILITY is configured for a CICS environment. It is not recommended and would not be supported. Why would you use a predefined FACILITY configured for CICS with a non-CICS environment? TYPE= is really not needed any more. It is automatically picked up now. 

Regards,

Joseph Porto - CA Level 1 Support

Joseph,

many thanks again for your valuable details. I think, I should have submitted a separate question, because we address general questions about Top Secret Facilities.... btw. is there some "best practices documentation" about TSS facilities?

Of course I would not use a CICSTEST FAC for a vendor product ... thus I understand your answer, that the TYPE=*** option is well considerable.

Let me ask a next general question:

When the vendor product is implemented in more instances (e.g. dev, test, qa, prod) and the vendor product provides its own login check (for expample by security call to a user-defined resource): What would be best practice either to define one FAC for the product or to define a FAC per instance of the product?

An example would be MQ-series, which operates with the MQCONN(*queue-handler*) resource to handle connections. If you have more than one mq subsystems running, is it better to define a FAC for every MQ subsystem or define a separate FAC per MQ-subsystem, or is it like-for-like. What are the pro's and con's?

Thanks and regards,

Josef    

Hi Josef,

We don't have any specific best practices content for facilities in the DocOps material. You can check out either of the following sections though (in case you have not already perused them).

You will find occasional recommendations throughout some of the granular doc, but no specific best practices collection.

• Protecting Facilities
• Facilities Matrix for CICS

-Kris