Datacom External Security failures using MUF users with special attributes
Article ID: 46094
Updated On:
Products
Issue/Introduction
We currently run 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 05 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?
Environment
Release: All
Component : Datacom/DB
Component : Datacom/AD
Resolution
There are multiple points where a configuration can fail in enabling External Security within a Datacom MUF: within the MUF configuration of the MUF Startup Options, within 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. There are two security definitions that must work a certain way to enable External Security for a MUF: ACTIVATE.LEVEL05.PASS must allow access to the MUF user, and ACTIVATE.LEVEL05.FAIL must deny access to the MUF user. If these are defined correctly, then we need to look at the MUF user itself.
RACF
In RACF, the first 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 NORACF and 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.
TOP SECRET
Likewise, Top Secret has logonid attributes that permit similar accesses. Although there is not a single Top Secret attribute that is the equivalent of TRUSTED=YES in RACF, there are the bypass attributes in 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.
ACF2
For ACF2, special access is often managed via the NON-CNCL attribute on the logonid definition. If the logonid associated with the MUF has the NON-CNCL privilege, then the ACTIVATE.LEVEL05.FAIL resource will not return the correct return-code, because the NON-CNCL privilege will grant access. To use the NON-CNCL privilege and still allow the .FAIL access to be denied, ACF2 GSO SAFDEFs can be used to return the proper return codes. Here is an example of using SAFDEF rules to return the correct security level for logonid uuuuuuuu that has the NON-CNCL privilege:
ACF
SET CONTROL(GSO)
INSERT SAFDEF.DCFAIL FUNCRET(8) FUNCRSN(0) ID(DATACOM) MODE(IGNORE) -
RACROUTE(REQUEST=AUTH CLASS=DTSYSTEM -
ENTITYX=ACTIVATE.LEVEL05.FAIL) RETCODE(8) USERID(uuuuuuuu)
INSERT SAFDEF.DCPASS FUNCRET(0) FUNCRSN(0) ID(DATACOM2) MODE(IGNORE)
RACROUTE(REQUEST=AUTH CLASS=DTSYSTEM
ENTITYX=ACTIVATE.LEVEL05.PASS) RETCODE(0) USERID(uuuuuuuu)
F ACF2,REFRESH(SAFDEF)
Be aware that the MODE(IGNORE) parameter means that the rule (ACTIVATE.LEVEL05.xxxx) will not be validated for the level of access, and that these SAFDEF rules will return a RC 8 or 0 for the .FAIL or .PASS resource calls, respectively, regardless of permission settings for this USERID value in those resource rules.
Additional Information
For more information about managing External Security in the Datacom environment, please refer to the Security Overview section of the Datacom documentation.
As always, please contact Broadcom support for Datacom if you have further questions.
***
Feedback
