z/OS v1.13 will be the last release to support BPX.DEFAULT.USER, a feature used by nearly 90 percent of sites that use RACF, according to a recent survey conducted by RSH Consulting. What does this mean for these users? Here, we examine the tasks and considerations related to its replacement.
Many z/OS-based TCP/IP applications use sockets (local IP address plus port number). An example is File Transfer Protocol (FTP). For a z/OS user to access such an application, the user requires a UNIX User Identifier (UID) and the user's logon group requires a UNIX Group Identifier (GID).
In RACF, you can assign a user a UID and a group a GID by adding an OMVS segment to each of their respective records. A segment is an extension of a RACF record that provides attributes required by a specific application, which in this case is z/OS UNIX.
As IBM began rolling out TCP/IP applications in the mid-’90s, it was concerned that clients would balk at having to assign tens of thousands of OMVS segments to their users and groups. To ease the implementation of these applications, IBM introduced a feature to assign a temporary default UID or GID to any user or group lacking a UID. This feature first appeared in OS/390 v2.4 (circa 1997). It was implemented as FACILITY class profile BPX.DEFAULT.USER. The APPLDATA field of this profile identifies a user and group whose respective UID and GID are to be used as the default user and default group. The default IDs were open for use by any and all types of users, including technical support staff, started tasks, customers, production batch IDs, business partner FTP IDs, etc.
Unfortunately, this feature hasn’t been a panacea. It essentially creates a shared ID, which security professionals and auditors generally don’t consider to be a best practice. UNIX files or directories any user creates using the default user UID are accessible to all such users. Users of the default user UID are unable to use some UNIX functions, and in a few instances, z/OS UNIX can’t properly provide users with the default user UID when performing certain tasks. In view of these drawbacks, IBM has decided to discontinue this feature and require that all users and logon groups be assigned individual UIDs and GIDs via OMVS segments.
Now that you know what has to be done and why, here are the steps you can take to replace BPX.DEFAULT.USER with individually assigned UIDs and GIDs. The size of this effort will depend upon the extent you’re currently relying on BPX.DEFAULT.USER. The following road map will assist you in making the transition and minimize the possible disruptions this migration might cause.
Step 1: Set Standards
Before launching headlong into the task of assigning UIDs and GIDs, decide what numbers you want to assign. For users, consider establishing ranges of numbers that represent employees, contractors, system IDs (started task and batch IDs), and customers. Make the UID recognizable for ease of administration. For employees, consider incorporating the person's HR employee number in the UID, assuming it isn’t a Social Security Number. For instance, if employee numbers are six digits, prefix them with 10 to form the UID (e.g., employee number 007654 becomes UID 10007654). For groups, set aside different number ranges for default logon groups and access granting groups. For user default logon groups, you might want to incorporate HR department or cost center codes into the GID in a manner similar to what you might have chosen for UIDs.
Step 2: Prepare for ID Assignment
Here’s a list of tasks necessary to properly prepare for assigning UIDs and GIDs:
• Verify the RACF database has sufficient space for all new OMVS segments.
• Convert the RACF database to the Application Identity Mapping (AIM) structure. This will let you use some of the new, optional RACF features designed to replace BPX.DEFAULT.USER. (According to an RSH survey, a mere 50 percent of installations use AIM.)
• Activate the RACF class FSSEC to enable use of extended Access Control Lists (ACLs). With extended ACLs, you can give multiple users and groups access to a file or directory. You may find the use of extended ACLs necessary to replace the shared use of the default user. (According to an RSH survey, only 40 percent of installations have activated this class.)
• Search all UNIX file systems for file and directory OWNER UIDs and Group GIDs that no longer have a corresponding RACF user or group; replace these IDs with valid ones. Failure to perform this step could result in assigning a UID to a user that matches the UID on a file or directory created by a former user who had the same UID. In that case, the new user would instantly inherit ownership of these objects.
• Search all UNIX file systems for file and directory OWNER UIDs and group GIDs matching the default user and group, and assign replacements. You will probably need to set up new permissions, possibly using extended ACLs. Usually, you will need to log access activity for some period of time to determine who is using these objects so proper permissions can be built. Failure to perform this step properly and carefully could result in disruption of system tasks and production batch processes.
• Implement UNIXPRIV class profile SHARED.IDS. This prevents the accidental assignment of duplicate UIDs and GIDs; it requires implementing the AIM structure.
Note: There’s a performance enhancement feature that lets UNIX make some access decisions on its own (without calling RACF). The feature is implemented by defining FACILITY class profile BPX.SAFFASTPATH. Unfortunately, in bypassing RACF calls, logging of such access is also skipped. If you need to turn on logging to track user activity, delete this profile and deactivate its use with a SET OMVS operator command. Failure to do so might result in crucial access activity being missed and not accommodated with replacement permissions.