Products

ACF2 ACF2 - DB2 Option ACF2 for zVM ACF2 - z/OS ACF2 - MISC

Issue/Introduction

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: ACF2 r15 - Minimum required release to run z/OS 2.1. Customers running ACF2 r14 or lower will need to upgrade to r15 across all LPARs before implementing z/OS 2.1.

Related 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 ACF2 r15 maintenance (leveraged at z/OS 2.1):
RO59312 - Enhancement: z/OS 2.1 Compatibility

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 ACF2 Administration Guide. In addition, review the 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.

Resolution

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:

 ACF
 SET LID
 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)
 LIST LIKE(-)
 END

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.

BPX.DEFAULT.USER values may be defined in the UNIXOPTS GSO record but users may not actually be using those values. Assigning OMVS credentials to all users may not be desired if they never use OMVS services. A new trace facility will allow detection on 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.

RO55702 has been replaced by RO65357.

RO65357 allows 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:

SET CONTROL(GSO)  
CHANGE UNIXOPTS TRACEDFT
F ACF2,REFRESH(UNIXOPTS)

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 BPX.UNIQUE.USER is not defined, and the user does not have an OMVS USER profile, one will need to be manually created. If there is not 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.
```
ACF
SET LID
CHANGE IF(GROUP LE X'40') GROUP(dftgroup) (specify the default group instead of dftgroup)
END 
```

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, 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 USER01 is auto-assigned OMVS credentials, the user profile for USER01 will be given HOME(/u/user01). If the MODLUSER profile has HOME(/u/&LID), USER01 will be given HOME(/u/USER01).

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. The range should 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 DFTUSER and DFTGROUP are 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 defaults are still defined.

Prior to upgrade to z/OS 2.1, the following message is written:
ACF79482 BPX.DEFAULT.USER values defined - They become obsolete at z/OS 2.1 and above

After upgrade to z/OS 2.1, the following message is written:
ACF79483 BPX.DEFAULT.USER values defined - They are ignored at z/OS 2.1 and above

Once all users are reconciled and have UID and GID defined, and the cutover to z/OS 2.1 is complete, the DFTGROUP and DFTUSER assignments can be removed from the UNIXOPTS GSO record.

Note: z/OS 1.13 and below require the OMVS defaults be available for IOSAS processing.

Remove BPX.DEFAULT.USER in ACF2 in z/OS 2.1+

Article ID: 19805

Updated On: