Preparation for removal of Default OMVSUSR and OMVSGRP
Article ID: 19797
Updated On:
Products
Issue/Introduction
Preparation for removal of Default OMVSUSR and OMVSGRP.
Environment
CA Top Secret r15 - Minimum required release to run z/OS 2.1. Customers running CA Top Secret r14 or lower will need to upgrade to r15 across all LPARS before implementing z/OS 2.1.
Related CA 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
Resolution
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 CA 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:
- Security File BLOCKSIZE set to 8192
- Each owned general resource requires one 16 byte entry in the index.
- 8192/16 = 512 index entries/block
- 30000 new index entries / 512 = 59 blocks
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:
- TSSFAR also reports on the percentage of deleted RESBLOCK entries. If this value is greater than zero, this percentage value should be added to the remaining percentage of RESBLOCK space calculated above.
- Running TSSFAR against the Security File can cause degradation to system performance. To avoid system performance degradation, we recommend that TSSFAR always run against a CA Top Secret Backup File.
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:
- The security file RESBLOCK or BLOCKSIZE values must be the same for the BACKUP security file. If you are changing either of these values, you must also allocated new CA Top Secret backup files.
- A change to the security file using TSSMAINT and TSSXTEND requires the allocation of a new VSAM data set to keep the two files synchronized.
For more information regarding increasing the size of your security files, please review the CA Top Secret Installation Guide.
How Groups and DEFAULT groups are used under CA 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, CA 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, CA 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, CA 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, TSS 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, TSS 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, TSS 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. CA 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 the CA Top Secret Control Options Guide. In addition, you should also review the CA Top Secret Cookbook Guide section on Controlling Access to USS 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.
Instructions:
Steps to complete before leveraging UNIQUSER/MODLUSER:
Step 1: Implement TSSMVS r15 related enhancement PTF's.
Step 2: Identify ACIDs that have pre-existing OE authorization assignments.
TSSCFILE - TSS LIST(ACIDS) SEGMENT(OMVS)
-
- TSS OMVS related CFILE record ID's
- 4401 - UID
- 4402 - GID
- 4403 - HOME
- 4404 - OMVSPGM
- 4405 - DLFTGRP
- TSS OMVS related USER LIMITS CFILE record ID's
- 4406 - ASSIZE
- 4407 - MMAPAREA
- 4408 - OECPUTM
- 4409 - OEFILEP
- 4410 - PROCUSER
- 4411 - THREADS
- TSS OMVS related CFILE record ID's
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 the 'Command Functions Guide CA Top Secret for z/OS r15' manual, sub-heading 'Command Functions', section 'LIST Function—Display ACID Security Data'.
Step 3: Reconcile OMVS assignments across all applicable LPARs for these ACIDs
- Establish OE credentials where warranted for these ACIDs. With the new requirement that every non-administrative (UID(>0)) user be explicitly assigned a unique UID, you will want to plan how UID's are assigned in multiple LPARs.
- Will an ACID established in multiple LPAR's have the same UID in all systems?
- Advantages:
- Directory and file UNIX administration can be the same in all APARs.
- UNIX trace will be able to distinguish activity for users by UID on any LPAR.
- Disadvantages:
- Privileges would not vary in the UNIX environment through standard flags.
- Advantages:
- Will a UID for an ACID be confined to distinct ranges of UID for each APAR?
- Advantages:
- The assignment of a separate UID in each LPAR would force administration of standard UNIX security to be different in each system.
- Trace would be able to distinguish where the user originally signed on.
- Disadvantages:
- UID's already assigned outside newly planned ranges might need to be reassigned. In addition, file/directory ownerships will need to be re-administered (via native UNIX security) to enforce the assigned LPAR range.
- Alternatively, if the ranges are not enforced on existing users, there may be large numbers of users who cannot be immediately identified.
- Advantages:
- Will CPF preserve newly created UNIQUSER UID's, across multiple LPARs or will AUTOUID processing be invoked to generate CPF ACID changes to add UID's in ranges assigned to a specific LPAR?
- CA-Top Secret has established control options:
- CPFAUTOUID -
- NO- propagates UID(?) in CPF commands so that they will pick up DFLTRNGU limitations in remote LPAR.
- YES- propagates the generated UID for the local LPAR to all remote CPF destinations
- CPFAUTOGID -
- NO- propagates GID(?) in CPF commands so that they will pick up DFLTRNGG limitations in remote LPAR
- YES- propagates the generated GID for the local LPAR to all remote CPF destinations
- CPFAUTOUID -
- CA-Top Secret has established control options:
- Will there be an impact on the removal of existing credentials to take advantage of UNIQUSER/MODLUSER capabilities?
- Users with incomplete USS credentials will be unable to make use of USS Callable Services.
- Credentials will only be updated when no OMVS segment fields are present on an ACID.
- Individual UNIX file/directory security may need to be re-administered if new UID's are assigned.
Step 4: Define the MODLUSER acid (or use the existing OMVSUSR acid).
- PTF RO63740 introduces a new enhancement that allows the variable &acid or &ACID to be specified in the HOME field of a MODLUSER ACID. When leveraged, CA Top Secret will insert the ACID for this value (respectively as lower or upper case to support your UNIX directory standard) when the permanently defined OMVS credentials are automatically copied from the MODLUSER to the session ACID which lacks OE credentials. For example, if FRED01 is an ACID attempting entry to OMVS without OE credentials, and the MODLUSER ACID MODL01 has HOME(/u/&acid), UNIQUSER processing will prototype a HOME value of HOME(/u/fred01) into FRED01.
- You may use the ACID that you currently set in z/OS 1.13 and below as your OMVSUSR for your MODLUSER. The following conditions will need to be considered:If you make use of HFSSEC(ON), HFSSEC permissions on the MODLUSER will not be propagated from the MODLUSER.
- The UID from the ACID will not be propagated.
- If the session ACID lacks a DFLTGRP attribute, as well as an OMVS segment, the DFLTGRP will also be copied to the session ACID.
The DFLTGRP on the MODELUSER will be assigned as a GROUP to an ACID that logs on to USS/OMVS if that user does not already have an OMVS segment. - Other GROUPs, PROFILEs permissions and ownerships present on the MODLUSER will not be propagated to the session user, even if they are present.
Step 5: Identify the highest UID that is currently assigned on each LPAR.
There are multiple ways to identify the highest UID currently assigned on each LPAR.
- To find the highest UID that is currently assigned on an LPAR, issue TSS WHOOWNS UID(*). The UIDs are listed in numerical order from low to high. The highest one will be at the bottom of the listing. NOTE: TSS WHOOWNS UID(*) should be issued during off peak hours because this command can be high I/O intensive to the security file and may negatively impact performance.
- As an alternative, you can leverage the CA Top Secret Utility TSSCFILE output from Step 2. The CFILE record id 4401 contains the assigned UID value for each ACID.
Step 6: Set CA Top Secret control options as follows:
- DFLTRNGU - Assign a unique range for each LPAR via CA Top Secret control option and DFLTRNGU. You want the range to be significantly greater than the highest currently existing UID number. This is the pool of available numbers that CA Top Secret will use to auto assign UID's as needed.
Example: DFLTRNGU(1000000,1999999) - UNIQUSER(ON) - Turns on auto UID assignment if ACID has no OMVS credentials.
- MODLUSER(acid) - Identifies the model ACID (set of additional fields auto assigned) whenever UNIQUSER code is invoked.
- CPFAUTOUID(YES) - If CPF is leveraged, this changes the outgoing CPF command from UID(?) to the UID assigned/generated on the local LPAR. If this control option is set to NO (which is the default), the UID(?) will be sent and will most likely result in a different UID number assigned for each of the CPF connected LPARs.
- CPFAUTOGID(YES) - If CPF is leveraged, this changes the outgoing CPF command from GID(?) to the GID assigned/generated on the local LPAR. If this control option is set to NO (which is the default), the GID(?) will be sent and will most likely result in a different GID number assigned for each of the CPF connected LPARs.
Additional Information
FAQ's
How can I identify users on my system that do not have established USS credentials?
While running z/OS 1.13 and below, CA 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 CA 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 CA 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), CA 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 CA 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.
What do I need to do if I have externalized Unix Systems Security (USS) using CA Top Secret HFSSEC? Is UNIQUSER/MODLUSER still required?
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.
What happens to existing OMVS authorizations (on a CPF targeted LPAR) if a user logs into OMVS workloads on a system where they do not have pre-existing OMVS credentials defined?
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 CA 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.
How does CA Top Secret determine what number to auto assign for a UID/GID?
There are three ways CA Top Secret calculates the number used when auto assigning a UID/GID:
- Range can be specified on the Top Secret command:
Example: TSS ADDTO(userid) UID(?) RANGE(1000,10000) - For manually entered commands that do not specify the RANGE keyword, or for UNIQUSER assigned UIDs, CA Top Secret will leverage control options DFLTRNGU and DFLTRNGG.
- If no range is specified on the command and DFLTRNGU and/or DFLTRNGG are not active, CA Top Secret will select the next available number. This could include a previously assigned UID or GID number that had been removed.
What do I need to do if I leverage CPF?
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 CA 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 CA Top Secret (RO63150) implemented/activated:
- When a command to ADD a UID or GROUP is sent via CPF to another LPAR, prior to implementation of the CA Top Secret support for z/OS 2.1, the following command will be sent:
TSS ADDTO(acid) UID(?)
The question mark (?) results in a UID being assigned using the next available UID slot on the targeted system. When this command is executed on multiple systems, it can result in different UIDs or GIDs being assigned at different remote nodes - either because:- DFLTRNGU and DFLTRNGG are set differently on different LPARs
- Or the UID or GID generated in one system may not be the "next" available number on another.
TSS ADD(acid) UID(?)
TSS ADD(group) GID(?)
With CA Top Secret (RO63150) implemented/activated:
- RO63150 introduces two new CA Top Secret Control options (CPFAUTOUID and CPFAUTOGID). The CPFAUTOUID control option can be configured so that the UID assigned number generated on the local system (where the USER logged in) is inserted in the commands sent to all connected CPF systems.
For example, a user logs into a USS application and does not have USS credentials established and the following conditions in place:- UNIQUSER/MODLUSER implemented
- Next UID slot available: 4101991
- MODLUSER is assigned a DFLTGRP GROUP correctly defined with a USS GID.
Using the above criteria, the CPF command sent would be;
TSS ADDTO(acid) UID(4101991)
Does UNIQUSER also auto assign GID's in addition to UIDs?
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.
What happens if all the range values specified in DFLTRNGU or DFLTRNGG are currently assigned?
The ADD will fail with the following TSS 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.
What happens if an ACID with a pre-defined Default group but does not have any OMVS segment data signs on to USS?
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.
Control Options Usage z/OS 1.13 (and below) versus z/OS 2.1
UID/GID assigned at USS initiated workloads
Related Top Secret Control Options
z/OS 1.13 & z/OS 2.1
FIGURE 1: https://ca-broadcomcsm.wolkenservicedesk.com/servlet/servlet.FileDownload?file=0150c000004ANMRAA4" alt="Figure 1"
* Gotcha Alert: At z/OS 2.1 the OMVSUSR & OMVSGRP control options are ignored. If these control options are set in TSS PARMS at startup when running at z/OS 2.1, the following error messages will result:
TSS9196I-OMVSGRP NOT SUPPORTED IN z/OS 2.1 AND ABOVE
TSS9197I-OMVSUSR NOT SUPPORTED IN z/OS 2.1 AND ABOVE
UNIQUSER/MODLUSER Usage:
Gotcha Alert: The UNIQUSER/MODLUSER control option does not get leveraged (no action taken) if the user has any OMVS SEGMENT related fields.
An OMVS SEGMENT is considered defined if any of the following fields exist on the ACID:
- UID(0) or Unique UID>0
- HOME
- OMVSPGM
- OECPUTM, OEFILEP, ASSIZE, PROCUSER, THREADS, MMAPAREA, MEMLIMIT, SHMEMMAX.
Note: GROUP or DEFAULT GROUP pre-assigned authorizations are not considered in determining OMVS SEGMENT status. If these values are assigned, and none of the above fields are present, the UNIQUSER/MODLUSER code will be leveraged. The pre-assigned GROUP/DEFAULT GROUP will remain on the ACID.
Experiences can be different between z/OS 1.13 (and below) and z/OS 2.1 (see examples below):
- Sign-on to OE/FTP
- z/OS 1.13
- OMVSUSR/OMVSGRP set
- UNIQUSER/MODLUSER not set
FIGURE 2: https://ca-broadcomcsm.wolkenservicedesk.com/servlet/servlet.FileDownload?file=0150c000004ANMSAA4" alt="Figure 2"
Experiences can be different between z/OS 1.13 (and below) and z/OS 2.1 (examples continued):
- Sign-on to OE/FTP
- z/OS 1.13
- OMVSUSR/OMVSGRP set
- UNIQUSER/MODLUSER set
FIGURE 3: https://ca-broadcomcsm.wolkenservicedesk.com/servlet/servlet.FileDownload?file=0150c000004ANMTAA4" alt="Figure 3"
Experiences can be different between z/OS 1.13 (and below) and z/OS 2.1 (examples continued):
- Sign-on to OE/FTP
- z/OS 2.1
- OMVSUSR/OMVSGRP set <-- Control Options ignored at z/OS 2.1
- UNIQUSER/MODLUSER set
FIGURE 4: https://ca-broadcomcsm.wolkenservicedesk.com/servlet/servlet.FileDownload?file=0150c000004ANMUAA4" alt="Figure 4"
Experiences can be different between z/OS 1.13 (and below) and z/OS 2.1 (examples continued):
- Sign-on to OE/FTP
- z/OS 2.1
- OMVSUSR/OMVSGRP set <-- Control Options ignored at z/OS 2.1
- UNIQUSER/MODLUSER not set
FIGURE 5: https://ca-broadcomcsm.wolkenservicedesk.com/servlet/servlet.FileDownload?file=0150c000004ANMVAA4" alt="Figure 5"
Sample Usage Case #1
Customer requirements:
- 5 LPARS all CPF connected (SYS1, SYS2, SYS3, SYS4, SYS5)
- ACIDS with already pre-defined OMVS credentials assigned should have the same OMVS credentials defined on any LPARs where they currently have none defined (or partially assigned).
- ACIDS (without pre-existing OMVS credentials) that are defined on multiple LPARs should be auto assigned the same UID number across all systems regardless as to what system they initiate USS workloads. The customer requires the following:
- The assigned Default Group should be the same as the OMVSGRP acid (under z/OS 1.13).
- The HOME assigned should contain /u/acid (where acid is equal to their acid (in lowercase).
Recommended solution:
- Identify ACIDS with pre-defined authorizations using reports generated from (TSSCFILE, TSS LIST commands or CIA). As an alternative, to find the highest UID that is currently assigned on an LPAR, issue TSS WHOOWNS UID(*). The UIDs are listed in numerical order from low to high. The highest one will be at the bottom of the listing. NOTE: TSS WHOOWNS UID(*) should be issued during off peak hours because this command can be high I/O intensive to the security file and may negatively impact performance. Build command streams to authorize OMVS credentials on all applicable LPARS as needed.
- Once step 1 is complete, the next step is to identify the highest UID that is currently assigned on each LPAR. After that has been established, assign a unique range for each LPAR leveraging CA Top Secret control option and DFLTRNGU. You want the range to be significantly greater than the highest currently existing UID number. For example, the highest UID value across all LPARs that is currently assigned is 100347. The DFLTRNGU range for each of the 5 LPARS could be set to:
SYS1 (via TSS PARMS) DFLTRNGU(1000000,1999999)
SYS2 (via TSS PARMS) DFLTRNGU(2000000,2999999)
SYS3 (via TSS PARMS) DFLTRNGU(3000000,3999999)
SYS4 (via TSS PARMS) DFLTRNGU(4000000,4999999)
SYS5 (via TSS PARMS) DFLTRNGU(5000000,5999999)
In addition to setting control option DFLTRNGU, you will also need to set (TSS PARMS) the following control options on all 5 LPARs:
UNIQUSER(ON)
MODLUSER(acid) - This should be the acid that is assigned to the OMVSUSRP control option.
CPFAUTOUID(YES) - Assign the MODLUSER acid the following HOME authorization:
TSS ADDTO(acid) HOME(/u/&acid)
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: CA 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).
Sample Usage Case #2
Customer requirements:
- 5 LPARS all CPF connected (SYS1, SYS2, SYS3)
- ACIDS with already pre-defined OMVS credentials assigned should have the same OMVS credentials defined on any LPARs where they currently have none defined (or partially assigned).
- ACIDS with already pre-defined Default Groups should retain these assigned groups and not inherit the MODLUSER default group.
- ACIDS (without pre-existing OMVS credentials) that are defined on multiple LPARs should be auto assigned the same UID number across all systems regardless as to what system they initiate USS workloads. The customer requires the following:
- The assigned Default Group should be the same as the OMVSGRP acid (under z/OS 1.13).
- The HOME assigned should contain /u/acid (where acid is equal to their acid (in lowercase).
Recommended solution:
- Identify ACIDS with pre-defined authorizations using reports generated from (TSSCFILE, TSS LIST commands or CIA). As an alternative, to find the highest UID that is currently assigned on an LPAR, issue TSS WHOOWNS UID(*). The UIDs are listed in numerical order from low to high. The highest one will be at the bottom of the listing. NOTE: TSS WHOOWNS UID(*) should be issued during off peak hours because this command can be high I/O intensive to the security file and may negatively impact performance. Build command streams to authorize OMVS credentials on all applicable LPARS as needed.
- Assign a unique default group for all ACIDs that require one.
- Once step 1 and 2 are complete, the next step is to identify the highest UID that is currently assigned on each LPAR. After that has been established, assign a unique range for each LPAR leveraging CA Top Secret control option and DFLTRNGU. You want the range to be significantly greater than the highest currently existing UID number. For example, the highest UID value across all LPARs that is currently assigned is 100347. The DFLTRNGU range for each of the 5 LPARS could be set to:
SYS1 (via TSS PARMS) DFLTRNGU(1000000,1999999)
SYS2 (via TSS PARMS) DFLTRNGU(2000000,2999999)
SYS3 (via TSS PARMS) DFLTRNGU(3000000,3999999)
In addition to setting control option DFLTRNGU, you will also need to set (TSS PARMS) the following control options on all 3 LPARs:
UNIQUSER(ON)
MODLUSER(acid) - This should be the acid that is assigned to the OMVSUSRP control option.
CPFAUTOUID(YES) - Assign the MODLUSER acid the following HOME authorization:
TSS ADDTO(acid) HOME(/u/&acid)
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.
Attachments
Feedback
