BPX.DEFAULT.USER removed at z/OS 2.1 and above. Implement z/OS 2.1 or above with CA ACF2 r16, what is needed to remove default UID and GID from ACF2 GSO UNIXOPTS record?
search cancel

BPX.DEFAULT.USER removed at z/OS 2.1 and above. Implement z/OS 2.1 or above with CA ACF2 r16, what is needed to remove default UID and GID from ACF2 GSO UNIXOPTS record?

book

Article ID: 105760

calendar_today

Updated On:

Products

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

Issue/Introduction

IBM announced that BPX.DEFAULT.USER was being removed at z/OS 2.1 and above. When preparing to implement z/OS 2.1 with CA ACF2, what is needed to setup a system so the default UID and GID can be removed from the ACF2 GSO UNIXOPTS record?

Environment

Release:
Component: ACF2MS

Resolution

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 r16 - Required release to run z/OS 2.1.

Control options UNIQUSER/MODLUSER (via the UNIXOPTS GSO record) 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.

Solution:

Steps to complete before leveraging UNIQUSER/MODLUSER:

Step 1: 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 2: (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.

The GSO UNIXOPTS TRACEDFT|NOTRACEDFT option 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 3: Reconcile OMVS assignments.

Using the data from the lists created in step 1

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.

  1.  
  2. 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.
     
  3. 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: 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 4: Define the MODLUSER OMVS USER profile (or use the existing DFTUSER profile).

  • Note that the ampersand (&) can be used to specify 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 USER001 is auto-assigned OMVS credentials, the user profile for USER001 will be given HOME(/u/USER001). If the MODLUSER profile has HOME(/u/&LID), USER001 will be given HOME(/u/USER001).

Step 5: 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 6: 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 7: Remove DFTGROUP and DFTUSER fields from the UNIXOPTS GSO record.

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.

Powered by Wolken Software