Per IBM's announcement that z/OS 1.13 was the last release to support BPX.DEFAULT.USER, IBM recommended using one of three methods to assign UID/GID values.
- Use BPX.UNIQUE.USER support with BPX.NEXT.USER support (introduced in z/OS 1.11); which will generate UID/GID automatically and ensure they are unique values.
- Use BPX.NEXT.USER to assign the next sequential available UID;
- Manually assign UIDs to users who need them and assigning GIDs for their groups.
Release requirement: CA ACF2 r15 - Minimum required release to run z/OS 2.1. Customers running CA ACF2 r14 or lower will need to upgrade to r15 across all LPARs before implementing z/OS 2.1.
Related CA ACF2 r15 maintenance (leveraged at z/OS 2.1 and below):
RO55702 - Enhancement: DETECT USERS OF BPX.DEFAULT.USER (use prior to implementing z/OS 2.1)
The process originally provided by RO55702 has now been replaced by RO65357 - BPX.DEFAULT.USER TRACE NOT ENABLED AT STARTUP
RO62767 - Enhancement: UID/GID CONSISTENCY FOR SHARED UID/GID - &LID IN HOME FIELD
RO62039 - Enhancement: ADD MSGS FOR BPX.DEFAULT.USER REMOVAL
Related CA ACF2 r15 maintenance (leveraged at z/OS 2.1):
RO59312 - Enhancement: z/OS 2.1 Compatibility
CA ACF2 r15 provided control options UNIQUSER/MODLUSER (via the UNIXOPTS GSO record) that can be leveraged to activate the equivalent support for BPX.UNIQUE.USER. Usage for both UNIQUSER and MODLUSER is detailed in the CA ACF2 Administration Guide. In addition, you should also review the CA ACF2 Administration Guide for information about using the AUTOIDOM GSO record to set ranges for UID and GID values for use by BPX.NEXT.USER.
At z/OS 2.1, IBM has eliminated the security calls related to BPX.DEFAULT.USER and is enforcing the requirement that all Unix Systems Services (USS) work requires the userid to have established USS credentials. This includes a UID (preferably unique) and an assigned default group that has an associated GID (also preferably unique*).
* Note regarding unique GIDs. Every logonid that accesses Unix Systems Services (USS) should have a group specified in the LOGNID GROUP field. The GROUP specified in a user's LOGONID corresponds to an ACF2 OMVS GROUP Profile record. Multiple LOGONIDs can specify the same GROUP. Each ACF2 OMVS GROUP should have a unique GID value.
Steps to complete before leveraging UNIQUSER/MODLUSER:
Step 1: Implement ACF2 r15 z/OS 2.1 related enhancement PTFs.
Step 2: Identify logonids that have pre-existing OMVS authorization assignments.
Use ACF commands in batch to display user assignments:
LIST IF(GROUP LE X'40') SECTION(RESTRICTIONS) PROFILE(OMVS)
LIST IF(GROUP GT X'40 ') SECTION(RESTRICTIONS) PROFILE(OMVS)
SET PROFILE(GROUP) DIV(OMVS)
Note: The LIST command with the IF parameter for GROUP LE and GT X'40' rather than a blank is used to account for
logonids that may contain invalid hex data in the GROUP field.
The first LIST IF command will list all users that DON'T have a GROUP defined and will list their OMVS user profile records.
The second list command will do the same for any users that DO have a GROUP defined and will list their OMVS user profile records.
The third list command will list all the OMVS GROUP profile records.
ALERT: At z/OS 2.1, if a user attempts a USS sign-on and does not have a GROUP field defined on the LOGONID record, this will result in a failed USS sign-on. Logonids with incomplete OMVS credentials will need to be reconciled before implementing z/OS 2.1.
Step 3: (Optional) Determine whether any users are using the BPX.DEFAULT.USER values.
You may have BPX.DEFAULT.USER values defined in the UNIXOPTS GSO record but are unsure whether your users are actually using those values. You may not want to assign OMVS credentials to all users if they never use OMVS services. A new trace facility will allow you to detect who is using the defaults. The trace, when run prior to z/OS 2.1, should run for a long enough period of time to detect all users who use OMVS services. The time needed depends on the frequency in which users access USS Services at your site.
RO55702 has been replaced by RO65357.
RO65357 allows you to activate a new option that will trace any initUSP callable service requests that use BPX.DEFAULT.USER. The report ACFRPTOM will log the initUSP requests showing that the defaults were used. The option is TRACEDFT in the GSO UNIXOPTS record. The default is NOTRACEDFT. To enable this tracing:
CHANGE UNIXOPTS TRACEDFT
Step 4: Reconcile OMVS assignments.
Using the data from the lists created in step 2
- If you have BPX.NEXT.USER and BPX.UNIQUE.USER defined, ensure that all users have a GROUP assigned to the logonid. At OMVS logon time, a unique UID will be assigned if one does not already exist. If a GROUP is assigned to the logonid, a unique GID will also be assigned if it is not already assigned to the GROUP. If no GROUP is assigned to the logonid, the OMVS logon will fail.
- If you do not have BPX.UNIQUE.USER defined, and the user does not have an OMVS USER profile, you will need to manually create one. If you do not have an OMVS profile with UID defined, the user will not be able to use OMVS services.
- It is recommended to assign unique GROUPs to users. Sites can either manually assign unique GROUPs to logonids that have no GROUP specified based on the LIST command in step 2. above, or sites can continue using the default GROUP profile record, by issuing a change command to change all users without a GROUP assignment in the logonid record to have the default group that was originally defined in the GSO UNIXOPTS DFTGROUP field.
CHANGE IF(GROUP LE X'40') GROUP(dftgroup) (specify the default group instead of dftgroup)
Note: PTF RO60393 is required to do the CHANGE command
Note: The LIST command with the IF parameter for GROUP LE X'40' rather than a blank is used to account for
logonids that may contain invalid hex data in the GROUP field.
Step 5: Define the MODLUSER OMVS USER profile (or use the existing DFTUSER profile).
- PTF RO62767 introduces a new enhancement that allows the ampersand (&) to be specified in the HOME field of the OMVS USER profile record. When leveraged, CA ACF2 will insert the logonid for this value (upper or lowercase is supported) when the permanently defined OMVS credentials are automatically given. For example, if the MODLUSER profile has HOME(/u/&lid) defined, and userid FRED01 is auto-assigned OMVS credentials, the user profile for FRED01 will be given HOME(/u/fred01). If the MODLUSER profile has HOME(/u/&LID), FRED01 will be given HOME(/u/FRED01).
Step 6: Identify the highest UID and GID that is currently assigned on each LPAR.
When CPF is used with BPX.UNIQUE.USER, the UID or GID assigned on one LPAR will be propagated to the receiving LPAR. Ensuring that different ranges are used on each LPAR will ensure that unique UIDs will be assigned across multiple CPF nodes.
Assign a unique range for each LPAR via the ACF2 AUTOIDOM GSO record.
UIDSTART, UIDEND, GIDSTART, and GIDEND control the ranges to be used for UID and GID auto assignment. You want the range to be significantly greater than the highest currently existing UID number.
Example: UIDSTART(10000000) UIDEND(19999999) GIDSTART( 5000000) GIDEND(5999999)
The maximum value for each field is 2,147,483,647.
AUTOIDOM ASSIGNU and ASSIGNG will cause new OMVS profile records to be automatically generated with UIDs and GIDs** when users access OMVS services.
**Note: The OMVS GROUP Profile record will only be created and a GID assigned if the user's LOGONID specifies a GROUP. For example is user's logonid TEST01 specifies GROUP(TESTGRP) and there is no ACF2 OVMS GROUP Profile TESTGRP, when logonid TEST01 accesses OMVS Services, ACF2 OVMS GROUP Profile TESTGRP record will be created and assigned a GID based on the AUTOIDOM GSO record fields.
Step 7: Define BPX.UNIQUE.USER and BPX.NEXT.USER.
UNIQUSER on the GSO UNIXOPTS record specifies that the BPX.UNIQUE.USER profile is active. This will allow OMVS USER profile records to be created automatically by initUSP and getUMAP/getGMAP callable services. The GSO AUTOIDOM record defines the settings to be used by BPX.NEXT.USER processing to auto-assign UIDs and GIDs.
- MODLUSER(modluser) - Identifies the model OMVS USER profile record (set of additional fields auto-assigned) whenever UNIQUSER code is invoked. This option is in the UNIXOPTS GSO record.
- ASSIGNU - Indicates that the UID can be auto-assigned when the AUTOUID keyword is specified or implied when inserting or changing an OMVS user profile data record. This option is in the AUTOIDOM GSO record.
- ASSIGNG - keyword is specified or implied when inserting or changing an OMVS Group Profile data record. This option is in the AUTOIDOM GSO record.
Step 8: Remove DFTGROUP and DFTUSER fields from the UNIXOPTS GSO record.
With RO62039 applied, if you have DFTUSER and DFTGROUP assigned in the UNIXOPTS GSO record, a message will be received every time that ANY GSO record is refreshed, at startup of ACF2 and at midnight. The message will state that you still have the defaults defined.
Prior to upgrade to z/OS 2.1, you will receive the following message:
ACF79482 BPX.DEFAULT.USER values defined - They become obsolete at z/OS 2.1 and above
After upgrade to z/OS 2.1 you will receive the following message:
ACF79483 BPX.DEFAULT.USER values defined - They are ignored at z/OS 2.1 and above
Once you have reconciled all users have UID and GID defined, and have successfully cutover to z/OS 2.1, you can then remove the DFTGROUP and DFTUSER assignments from the UNIXOPTS GSO record.
Note: z/OS 1.13 and below require the OMVS defaults be available for IOSAS processing.