We currently run CA Datacom/DB for several production, test, and development MUFs in our Sysplex. All of the MUFs in our environment are set up to use the External Security configuration with RACF.
We just set up some new test MUFs specifically to perform stress testing, and we modeled them off existing MUFs. We also confirmed that we have the MUF Startup Option “MESSAGE YES,DB00231” in place.
When starting these new MUFs, we do not see the External Security messages:
DB00231I - EXTERNAL SECURITY LEVEL 03 ACTIVE
DB00220I - EXTERNAL SECURITY ACTIVE FOR MYMUFCXX ON SQL OTHER DQ WITH DTTABLE
. . .
What could cause some MUFs to enable External Security, and others running on the same LPAR or in the same Sysplex to fail?
There are multiple points where a configuration can fail in enabling External Security within a CA Datacom MUF: within the MUF configuration of the MUF Startup Options, within CA Common Services, which manages the SAF calls, and with the SAF itself.
The most common cause for this situation – where some MUFs enable External Security but others do not – is related to either the resource profile covering the MUF, or the user profile used to run the MUF.
In RACF, the place to look is on the STARTED resource class profile for the MUF. For example, you might have a generic profile called MYMUFSTC.* for this MUF. Here, you would issue the command RLIST STARTED MYMUFSTC.* STDATA NORACFand look to see if the TRUSTED or PRIVILEGED attributes are there.
TRUSTED and PRIVILEGED are both powerful, and their use should be justified and monitored. Both give unlimited access to all datasets and most resources, and the only difference is that the activity of a TRUSTED is logged in SMF. If the STARTED resource used has either of these, it will cause External Security to be disabled; therefore, these attributes should be removed.
Likewise, CA Top Secret has logonid attributes that permit similar accesses. Although there is not a single CA Top Secret attribute that is the equivalent of TRUSTED=YES in RACF, there are the bypass attributes in CA Top Secret such as NODSNCHK, NOVOLCHK, NORESCHK, NOSUBCHK, and NOLCFCHK, that can be given to an ACID to bypass security checks. All bypass attributes that result in an access permission are audited to the Audit and Tracking File.
For CA ACF2, this is managed via the NON-CNCL attribute on the logonid definition.
For more information about managing External Security in the CA Datacom environment, please refer to the following guides:
CA Datacom/DB Version 14.02 Security Reference Guide
CA Datacom/DB Version 15.0 Security Reference Guide
As always, please contact CA Technologies support for CA Datacom if you have further questions.