IBM Security Z Security

 View Only

 Command Verifier Policy Profile for group Connect and Protected User

Bill Arrowsmith's profile image
Bill Arrowsmith posted 12/12/25 02:59 AM
Hello,
 
zSecure Command Verifier includes the capacity to implement controls of Connect commands based on a number of user attributes. The documented attributes include Special, Operations, Auditor and so on. 
 
We have a situation where we would like to prevent PROTECTED users from being connected to certain groups. Is this possible? 
 
Thank you,
 
Bill
Tom Zeehandelaar's profile image
Tom Zeehandelaar
Hi Bill,
 
the current version of Command Verifier does not support a policy profile to allow or disallow protected user IDs to be connected to certain groups. But I can see the added value of such a capability to be supported. Naturally, you are welcome to open an idea to request adding a Command Verifier policy profile that enables you to control whether protected user IDs can be connected to groups. Please also provide the business justification that outlines why your company would like such a policy profiles to be supported in a future release of zSecure Command Verifier. 
 
***** ADDITION *****
 
Hi Bill, 
 
Rob van Hoboken reached out to me to post his response below to this thread because the Post button in this thread does no longer work for this thread.
 
Tom is right, there is no policy profile that prevents connect commands when the target user ID has the PROTECTED attribute.  
 
In fact, there is no policy for any of the target user's attributes in C4R.CONNECT profiles. The SPECIAL, OPERATIONS and AUDITOR attributes you mentioned are CONNECT privileges, as mentioned in profile C4R.CONNECT.ATTR.SPECIAL.group.userid, which controls CONNECT userid GROUP(group) SPECIAL.
 
There are two ways to achieve the goal of preventing specific connect groups for users with the PROTECTED attribute:
 
 
 
Create a RACFVAR with the user IDs that have the PROTECTED attribute and another with the denied groups, say &PROTUSER and &PROTNOCO.  Use these in a policy C4R.CONNECT.ID.&PROTNOCO..&PROTUSER, UACC(NONE) and the policy denies these connects.
Use a two-pass CARLa script to monitor that all user IDs with the PROTECTED attribute are members of the &PROTUSER variable.
 
 
Alternatively, you could put all PROTECTED users under a NOCHANGE policy.
First, change the OWNER of the users to some common values, e.g., ALTUSER batprod OWNER(PROTBAT) and ALTUSER jes2 OWNER(PROTSTC).
Next, apply the NOCHANGE policy to all user IDs whose OWNER starts with PROT: C4R.USER.=NOCHANGE.PROT*.*  UACC(NONE)
Bill Arrowsmith's profile image
Bill Arrowsmith
Hi Tom and Rob,
 
Thank you for the suggestions.  The lists of users and groups we are concerned with are relatively static. The solution using RACFVARS might work for us.
 
Kind regards,
 
Bill