Preparation for removal of Default OMVSUSR and OMVSGRP.
Top Secret r15 - Minimum required release to run z/OS 2.1. Customers running Top Secret r14 or lower will need to upgrade to r15 across all LPARS before implementing z/OS 2.1.
Related Top Secret r15 maintenance (leveraged at z/OS 2.1 and below):
RO58980 - Enhancement: TSSOERPT detect users of BPX.DEFAULT.USER
RO63150 - Enhancement: CPF - Add option to change UID/GID(?) to locally assigned UID/GID number.
RO63740 - Enhancement: Support ampersand (&) in the HOME field (allows for &acid).
RO61055 - Enhancement: z/OS 2.1 toleration - Eliminate TSS9112E UNABLE TO DETERMINE JES LEVEL
Oct 15th, 2014 update – Gotcha ALERT: Before implementing the steps detailed in this document regarding the use of UNIQUSER/MODLUSER, you need to first determine if your current security file allocations for RESBLOCKS are properly sized to hold the added UID and GID assignments that can result once UNIQUSER is implemented. With each newly added UID or GID, the general resources index will be updated. Each owned general resource prefix requires one 16-byte entry in this index. Once the allocated RESBLOCKS become 100% filled, no further additions can be done. If UNIQUSER is implemented, this 100% full condition will result in failed UID assignments for users that do not currently have an assigned UID (that initiate USS workloads). The users will then be stopped from initiating USS workloads until the security file is resized.
To determine if your current security file is properly sized to handle the increased number of UID’s and GID’s, before turning on UNIQUSER, run the Top Secret TSSFAR utility specifying the SFSTATS sub option. The output from TSSFAR will list the current RESBLOCK allocation is currently being used. Once you have this information, you can leverage the following formula to determine how many added UIDs will result in reaching the maximum free space available.
Formula to determine recommended RESBLOCK value:
The output from TSSFAR will identify the current RESBLOCK allocation and percentage used. The potential number of new entries added when UNIQUSER or MODLUSER could be significant if all ACIDS will get a permanently assigned UID (and unique GID).
TSSFAR execution notes:
If the maximum number of added UIDs and GIDs that will fit is less than the total number of ACIDS allocated on your file, you should increase the RESBLOCK allocated entries accordingly before implementing UNIQUSER/MODLUSER support. In addition, you can then adjust the RESBLOCKs value to fit your requirement; the maximum number of RESBLOCKs that can be specified is 9999999 but we recommend you use a value that approximates your sites configuration. You should add a 40% buffer to account for future growth ownerships.
The procedure to increase the number of RESBLOCKS requires allocating a new security file and running TSSXTEND to copy your existing security file into the newly created RESBLOCK enlarged file.
Expanding the security file notes:
For more information regarding increasing the size of your security files, please review the Create the Security File.
How Groups and DEFAULT groups are used under Top Secret:
When a user signs onto a multi-user facility (for example, IMS, CICS), they are given the option to specify a group. In CICS, you may specify GROUP as part of the CESN sign on transaction. In IMS, you may specify GROUP as part of the /SIGN sign on command. In TSO, you may specify GROUP as part of the standard sign on information.
When a user signs on, Top Secret builds a list of groups for the user using the user's GROUP assignments and IBMGROUP permissions. The resulting list of groups constitutes the list of valid groups for that user. If you specify a GROUP at signon, it is checked against the list of groups. If GROUP is validated against one of these entries, the GROUP that you specified at sign on is passed to the session. If the GROUP specified by the sign on is not valid for the user, the group is altered to "*" and the sign on is allowed to proceed. This action can lead to problems later if the user intends to use Unix Systems Services, because no GID is assigned to the session. If OPTION(69) is set and the GROUP specified is not valid, the signon fails.
Dec 12th 2014 update - Gotcha Alert: The number of users that can physically be assigned to the same group in Top Secret is approximately 73,000 Acids. Some security calls may request the list of users attached to a group be returned in below-the-private storage. For this reason it is highly recommended you keep the number of attached users significantly lower, perhaps in the range of 3,000-5,000. For sites that plan to meet or exceed this level, you will need to monitor and define a new group replacing the default group assigned to the MODLUSER acid as this limit is approached.
If the user does not specify a GROUP at signon, but has a DFLTGRP in their acid record the DFLTGRP is passed to the session as the connect group and the signon is allowed. The DFLTGRP does not have to be in the user's list of valid groups. A DFLTGRP without a GID can lead to problems with USS access.
To use IBM Open Edition MVS, a user ACID must be associated with at least one group that has an assigned GID. The group can be attached directly to a user as a GROUP or as the DFLTGRP. Prior to z/OS 2.1, Top Secret provided support for default UID and GID through the OMVSUSR and OMVSGRP control options (this is also referred to as BPX.DEFAULT.USER support). Starting with z/OS 1.11, Top Secret has also provided support for AUTOUID (automatic generation of OMVS UID, GID and segment information) through the UNIQUSER and MODLUSER control options (this is also referred to as BPX.UNIQUE.USER support).
When a user attempts to enter OMVS (the USS shell), if the user's connect group does not have a GID and the UNIQUSER control option is active, Top Secret will automatically generate a GID for the GROUP acid. If the UNIQUSER control option is not active, the attempt to access OMVS will fail.
When a user attempts to enter OMVS and the user's connect group is "*", if the UNIQUSER control option is active and the MODLUSER acid has a DFLTGRP, Top Secret will add the DFLTGRP to the user's acid. If the operating system release is below z/OS 2.1 and the user's connect group is "*", and UNIQUSER is not active, then if the OMVSGRP control option is active, Top Secret will assign the default group GID to the user for the OMVS session. If the user still does not have a GID after UNIQUSER and OMVSGRP are processed, then the attempt to enter OMVS will fail.
Preparing your LPAR for z/OS 2.1:
Per IBM's announcement that z/OS V1.13 was the last planned release to support BPX.DEFAULT.USER, IBM had recommended that you either use the BPX.UNIQUE.USER support that was introduced in z/OS V1.11, or assign unique UIDs to users who need them and assign GIDs for their groups. Top Secret r15 provided control options UNIQUSER/MODLUSER can be leveraged to activate the equivalent support for BPX.UNIQUE.USER. Usage for both UNIQUSER and MODLUSER is detailed in UNIQUSER—Assign a UID Automatically During OMVS Logon and MODLUSER—Identify an OMVS Model User. In addition, you should also review Set Up UID and GID Auto-Assignment for additional information on assigning UID/GID through explicit or auto assignment.
At z/OS 2.1, IBM has eliminated the security calls related to BPX.DEFAULT.USER. In doing so, starting with z/OS 2.1, IBM is enforcing the requirement that all Unix Systems Services (USS) work requires the userid (ACID) to have established USS credentials. This includes a unique UID, assigned default group and Home.
Steps to complete before leveraging UNIQUSER/MODLUSER:
TSSCFILE - TSS LIST(ACIDS) SEGMENT(OMVS)
Gotcha ALERT:At z/OS 2.1, if an ACID attempts a Unix Systems Services sign-on and has any of these fields pre-assigned, the UNIQUSER/MODLUSER support will not get leveraged. This will result in a failed USS signon (the ACID will have incomplete OMVS credentials). ACIDS with incomplete OMVS credentials will need to be reconciled before implementing z/OS 2.1.
NOTE: The command, 'TSS LIST(ACIDS) SEGMENT(OMVS)', means display the basic ACID information, AND, if the ACID has SEGMENT information, display that too. It does not mean display the basic ACID information, ONLY, if the ACID has SEGMENT information. This is fully documented in LIST Function—Display ACID Security Data.
There are multiple ways to identify the highest UID currently assigned on each LPAR.
While running z/OS 1.13 and below, Top Secret r15 maintenance is available to help you identify which users are leveraging the default user (OMVSUSR) and group (OMVSGRP) assignments. This maintenance adds support to cut trace records for users that leverage the default user and/or group at sign-on. These trace records result in entries (written to SMF) and are reported on via the Top Secret r15 TSSOERPT reporting utility. The PTF for this support has been published as RO58980.
RO58980 adds the ability to turn on this BPX.DEFAULT.USER "trace". To activate this support, you will need to set Top Secret Control Option OPTIONS(32) to enable the USS logging feature and OPTIONS(85) to generate the default use trace messages. By activating Options(32,85), Top Secret will automatically log trace records for any successful initUSP callable service that has used the BPX.DEFAULT.USER values.
Gotcha Alert: Turning on OPTIONS(32) can result in a significant increase of records written to the Top Secret audit tracking file . Depending on the amount of UNIX systems services activity, the number of records written to the ATF files could more than triple. It is therefore recommended that you increase the size of your ATF files before turning on this option.
HFSSEC is leveraged to externalize security for accessing USS directory and files as well as several system functions related to UNIX.
Gotcha Alert: Although HFSSEC externalizes security for USS, OMVS credentials are still required to sign-on to USS related workloads.
Customers running with HFSSEC turned on will still need to establish the minimum OE segment authorizations for any ACIDS that leverage USS workloads. UNIQUSER and MODLUSER should be considered for sites running HFSSEC that want users to be auto assigned OMVS segment authorizations by default when none exists.
The OMVS segment related commands sent via CPF will replace all existing OMVS authorizations on the receiving CPF node.
Gotcha Alert: The pre-existing directories/files will still be natively owned by the original assigned UID (when they were created) even after the UID has been changed in Top Secret.
For customers that do not leverage HFSSEC security, there is the potential for users to no longer have native USS OWNER access rights for the files/directories they created under a previously assigned UID. To avoid this problem, before implementing UNIQUSER and MODLUSER support, make sure users with OMVS segment authorizations are assigned the same OMVS segment authorizations on all LPARs where they sign-on to USS workloads.
There are three ways Top Secret calculates the number used when auto assigning a UID/GID:
If you keep your security files in sync using Command Propagation Facility (CPF), and have chosen to leverage UNIQUSER/MODLUSER support, the following items should be considered:
Gotcha Alert: The Top Secret ADD commands sent via CPF will replace any existing fields that exist on the target systems. This will include UNIQUSER generated MODLUSER fields added to users who possess no OE credentials. In addition, it is possible that generated defaults from a test system could replace a targeted LPAR where the user already has pre-existing OMVS credentials. Please review your CPF network and identify nodes as receive-only which are used for temporary testing purposes, so that they do not corrupt production environments.
Without Top Secret (RO63150) implemented/activated:
With Top Secret (RO63150) implemented/activated:
Yes, but in rare instances only. If an ACID has no OMVS segment fields, and in addition has a DFLTGRP group which has not been assigned a GID, then UNIQUSER processing will copy the prototype OMVS fields from the MODLUSER ACID, generate a new UID for the session ACID, and generate a new GID for the DFLTGRP.
Gotcha Alert: The number of users that can be assigned to the same group is approximately 73,000 Acids. For sites that plan to meet or exceed this level, you will need to monitor and define a new group replacing the default group assigned to the MODLUSER acid as this limit is approached.
The ADD will fail with the following Top Secret message: TSS0326E UID/GID NOT AVAILABLE IN RANGE
Because of this, you should specify a range value that is significantly higher than the expected requirement.
If UNIQUSER and MODLUSER are active, the ACID will get auto assigned a unique UID as well as any other OMVS authorizations that reside on the MODLUSER ACID. The ACID will not inherit the default group (from the MODLUSER ACID). The pre-defined Default group will remain the same for the ACID.
Customer requirements:
Recommended solution:
Benefits:
These recommendations insure that the same UID number is assigned to an ACID across all LPARS where the ACID is defined. In addition, the unique LPAR ranges (assigned via DFLTRNGU) will assist the security administrators in identifying where the end user first initiated a USS workload. This can be helpful for debugging purposes. Note: Top Secret administration done outside of UNIQUSER processing should specify the RANGE keyword specifying a range that is not as needed (outside of the ranges specified in DFLTRNGU).
Customer requirements:
Recommended solution:
Benefits:
These recommendations insure that the same UID number is assigned to an ACID across all LPARS where the ACID is defined. In addition, the unique LPAR ranges (assigned via DFLTRNGU) will assist the security administrators in identifying where the end user first initiated a USS workload. Assigning pre-defined unique default groups ensures that all users will have a unique UID, HOME and default GROUP.