20210519: Personal group creation using MI GIDs

Last updated: September 29, 2023
Audience: IT Staff / Technical

Situation

Current State

There is currently no linkage between group GIDs in the Group Service and the gidNumber attribute on MI user accounts. Each new Group Service group is automatically assigned a GID value from an assigned range. Each new MI user is assigned a gidNumber from a different range. See Proposal: Adding GID Support to the Groups Service and MI and below for the range allocations.

Unix has a notion of a user personal group. This is a group whose GID matches the GID on the corresponding user account. See http://en.wikipedia.org/wiki/Group_identifier#Personal_groups.

Third party tools, such as PowerBroker Identity Services, offer integration between Unix-like systems and Active Directory. Computers configured with such a tool can employ AD groups to control resource access. The linkage between such Unix/Linux/Mac systems and AD is the GID number. If there isn’t an actual group for the user’s GID number, the Unix/Linux/Mac system tools, e.g. a file listing, will show the groups’ GID numbers rather than user-friendly names. IOW, it would not be apparent who owns a file/resource. Similarly, it would require looking up and knowing a user’s GID to assign access rights. The PBIS tools throw unhelpful errors when listing user info or when trying to locate the personal group for a user if there is no group corresponding to the user gidNumber.

Brian: It’s unclear to me how significant of a business need the gap noted in the above paragraph is. From my not very unix background, I’m left wondering how often you use a user’s GID to assign ownership vs. a group GID. If it’s only assigned for a single case–the user’s unix homedir, then I’m left thinking that the business need is pretty small and you can address that gap via far simpler means like labeling the directory path with the user’s UW NetID. I also don’t see any mention of the error message at login in the above paragraph–that seemed to me that bigger issue, but again, I’m mostly a unix novice. In any event, there’s something missing here in terms of unix background, and a bit more context setting to address the significance of the gap. I can’t supply that, I can only point out that it seems to be missing.

Conditions to Consider to Reach Desired Outcome

  1. There is no way to specify a GID on group creation within the Group Service. This is not an impediment for Alternative 2.
  2. The Group Service reserves a personal group stem of u_<UW-NetID> with a pre-assigned GID. This GID has no relationship to the gidNumber in MI for that user. Again, not an impediment for alternative 2.
  3. There is a huge number of UW-NetID user accounts in MI, many of whom are inactive or who will never be logging into an AD-integrated Unix/Linux/Mac computer. Thus it probably does not make sense to create a personal group (linked by MI gidNumber) for each active UW-NetID.
  4. We don’t want to create such personal groups directly in MI. The Group Service should continue to be the source for institutional group data. This is not an impediment. Rather it is a design assumption.

Brian: This section seems to assume a solution. There doesn’t seem to be any analysis of possible alternative solutions. Perhaps that’s because there are no other alternatives, but as a reader, I’m missing the step where solutions are considered, analyzed/discussed, and something chosen for its merits.

Target

Users who have a need for a personal group on their AD-integrated Unix/Linux/Mac computers can request and obtain one and then have the ability to manage the group using the existing Group Service tools. Similarly, IT managers of groups of such users can request the creation of personal groups for them.

Proposals

Both of the following proposals require that the UW-NetIDs used have the ability to manage groups in the Group Service.

Alternative 1
  1. Impediment 1 could be overcome by creating a Group Service process/API that consumes a list of UW-NetID and MI-gidNumber pairs and creates a personal group for each.
  2. Impediment 2 could be overcome by using a different stem for these groups since the u_<UW-NetID> stem is already in widespread use.
  3. This process would be on an as-requested basis. There would be no automatic creation of personal groups.
  4. Personal groups would be created in the Group Service and would sync to MI using the existing Group Sync Agent process.

Brian: Most of the above items don’t have much detail. That’s generally OK, but I believe strongly that the stem in #2 really should be explicitly proposed here.

Another detail not addressed is the existence of “home groups” for an existing set of UW NetIDs. These new “personal groups” will create some confusion with the existing “home groups”–what support implications does that have?

Finally, there’s a major issue with the proposal. How does a UW NetID that isn’t allowed to access the Groups Service manage their “personal group”? Today only personal UW NetIDs and shared UW NetIDs can access the Groups Service. That leaves management of some of these personal groups high and dry. The proposal must address this.

Alternative 2
  1. Customer sends us a UW-NetID and a corresponding group that they’d like used as a personal group. This could actually be a list of pairs.
  2. MI updates the gidNumber for that UW-NetID to match that of the GID for the supplied group as read from the Group Service.
  3. Perhaps add a new attribute to the uwPrincipal class, uwPersonalGroup, into which we can add the name of the user’s corresponding personal group. This would be for bookkeeping; e.g. to indicate that the GID points to that group and in case we ever wanted to audit that a non-default gidNumber does in fact point to the proper group.
  4. There would need to be some level of vetting to ensure that the user has admin rights on the group. The simplest way to do this would be to require the group be under the u_<UW-NetID> stem.

A PowerShell script could be written to do this. No changes would be needed in the Group Service.

Nice to Haves

  1. A GUI for creating personal groups. Possibilities for this could be the UW-NetID Support Org tool and/or the Groups Service UI.

 

Notes

Outcome

This proposal has not been accepted or implemented. No recommendation has been posed. Unresolved.