Idea Details

Enhance OMVS Administration when adding DFLTGRP

Last activity 01-14-2019 07:45 AM
Paul Sutton's profile image
10-31-2014 03:57 PM

We would like to request an enhancement to the administration process (command processor) when adding DFLTGRP to an ACID. Let me explain.

 

Currently you can issue the "TSS ADD(acid) DFLTGRP(group-name)" or "TSS REPLACE(acid) DFLTGRP(group-name)" commands and;

  • No cross check is done to verify that the GROUP name used in DFTLGRP field even exists. You can specify anything.
  • No cross check is done to ensure that if, the GROUP name used does exist, is it already connected to the user that you are adding the default group to?

 

We would like the "ADD/REPLACE" command for DFLTGRP to fail if one of the above conditions exists:

  • DFLTGRP should always be a GROUP that has been previously defined to the security system.
  • The DFLTGRP for a user must also be added to the users ACID. There are numerous instances where an application does not just depend on the OMVS Segment checking (for UID/GID) and will query TSS to see if a GROUP has been attached to the ACID.

 

Thanks.

 

 

Paul


Comments

01-14-2019 07:45 AM

I'd like to add a positioning from another perspective:

 

In the context of z/OS uss login processing and expressed by data-modeling language:

 

DFLTGRP is an attribute of the ACID<->GROUP-relation and NOT an attribute of the ACID-only.

 

Currently Top Secret's Security Administration behaviour concerning DFLTGRP and GROUP neglects this. Implementation of the proposed idea would correct this. 

01-11-2019 05:46 AM

Hello CA Technologies - a Broadcom Company,

 

As this idea has status of "Currently Planned", is there already an indication, when this will be implemented in the product?

 

Many thanks and best regards,

Josef

06-16-2015 02:36 PM

Some of this - I don't remember how much or which parts (sorry) - is being implemented in R16.  Anybody in development care to chime in?

 

- Don

01-07-2015 01:00 PM

In a recent idea submission entitled "warning MSG needed - GROUP ADDED as DFLTGRP", the submitted raised the case that a DELETE of a GROUP that is assigned to an accessor ID via the DFLTGRP attribute is not detected.  The submitter recommended that a warning message be issued to alert the security administrator to the problem.

 

I disagree with the recommended approach.  Rather, I suggest that this idea be revised by the inclusion of the following requirement -

 

  • A TSS DELETE for an accessor ID of type GROUP should be rejected with an appropriate error message if that GROUP is connected to an accessor ID by either of the DFLTGRP(accessor-ID-8) or GROUP(accessor-ID-8) attributes.

 

John P. Baker

11-09-2014 07:17 PM

I would like to add the following recommendation to the requirement -

  • When listing a GROUP with DATA(ACIDS) specified, for each connected accessor ID where the group ID is the default group ID for that accessor ID, provide an indication in the output of the TSS LIST command that the group ID is the default group ID for that accessor ID in a manner not unlike the indication that an accessor ID subordinate to a organizational accessor ID is a DEPARTMENT (D), DIVISION (V), GROUP (G), PROFILE (P), or ZONE (Z).

11-09-2014 04:35 PM

Yes, I like the ideas above, especially the one around the RENAME of a GROUP, that it is also reflected in the DFLTGRP.

11-07-2014 01:07 PM

I like the ideas as outlined above. I would also suggest to ensure that if a RENAME of a GROUP is performed that all of the places where that GROUP is a DFLTGRP also be changed to the new name.

11-04-2014 01:02 PM


Let me revise option 4 with the following text -

  • When adding a GROUP attribute, where the command does NOT specify a DFLTGRP operand, and where there are no group IDs currently connected to the accessor ID, provide an implicit DFLTGRP operand using the group ID specified by the GROUP operand.

I believe that this will address your concerns and reflects my intent, which the original language failed to do.

11-04-2014 12:30 PM

The default would apply IF AND ONLY IF only one group ID is added to the accessor ID and would serve to save the security administrator from coding the DFLTGRP operand, either on that command or on a separate following command.

 

If the user codes DFLTGRP on the command then it takes precedence.

 

If the user codes DFLTGRP on a subsequent command, then again, it takes precedence.

 

Providing the default would have no adverse impacts.

11-04-2014 12:16 PM

I can agree with your addition of administrative scoping to check when the commands are issued.

 

I don't agree with your 4th option:

 

  • When adding a GROUP attribute, where the command does NOT specify a DFLTGRP operand, and where the group ID specified by the GROUP operand is not currently connected to the accessor ID, provide an implicit DFLTGRP operand using the group ID specified by the GROUP operand ;

 

An ACID can have multiple groups attached to it, only one can be the DFLTGRP so the user needs to choose and if they need that changed when a new GROUP is added.  I don't think that (as shipped) Top Secret should be accountable to enforce what may be individual business practices in the processing of commands. If this is how you want your shop to run then maybe you need to code this in the "Command Pre-Processor" exit point of TSSINSTX.

11-03-2014 01:04 PM

I would expand upon this requirement as indicated below -

 

  • When adding a DFLTGRP attribute, check to see that the group ID exists in the security file and is within the administrative scope of the issuer of the command ;
  • When removing a DFLTGRP attribute, check to see that the group ID is within the administrative scope of the issuer of the command ;
  • When adding a DFLTGRP attribute, where the command does NOT specify a GROUP operand, and where the group ID specified by the DFLTGRP operand is not currently connected to the accessor ID, provide an implicit GROUP operand using the group ID specified by the DFLTGRP operand ;
  • When adding a GROUP attribute, where the command does NOT specify a DFLTGRP operand, and where the group ID specified by the GROUP operand is not currently connected to the accessor ID, provide an implicit DFLTGRP operand using the group ID specified by the GROUP operand ;
  • When issuing a REMOVE command specifying a DFLTGRP operand, where the command does NOT specify a GROUP operand, and where the group ID specified by the DFLTGRP operand is the only group ID connected to the accessor ID, provide an implicit GROUP operand using the group ID specified by the DFLTGRP operand ;
  • When issuing a REMOVE command specifying a GROUP operand, where the command does NOT specify a DFLTGRP operand, and where the group ID specified by the GROUP operand is the only group ID connected to the accessor ID, provide an implicit DFLTGRP operand using the group ID specified by the GROUP operand.