20130524: Adding GID Support to the Groups Service and MI

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


This proposal was implemented. Track progress via these items:

  • GRP-582Each group has a unique, immutable GID value. Closed
  • MI-394Automatic GID assignment for all UWWI user accounts Closed

Version History

This is version 3 of this proposal, incorporating prior feedback, adding MI users to the scope, and adding explicit GID reservations for legacy UW-IT unix groups.


Many Unix platforms assign a group identitifier (GID) as a unique identifier for a given group. Once assigned, the GIDs are used to reference a given group in file permissions.

Several MI Active Directory customers have asked for GIDs on groups so they can integrate both their Windows and Unix systems within a delegated OU. Additionally, a primary GID is needed on MI Active Directory user accounts to allow them to authenticate users by UW NetID on both platforms.

Goal Statement

There are two goals:

  1. Add GID to the UW groups service design and assign values to groups in an automated, delegated, and/or self-service way that enables these scenarios involving Unix platform integration.
  2. Add GID to MI users in an automated way that enables the above noted scenarios.


Most Unix platforms use a 32-bit integer for GIDs.

GIDs assigned to the Group Service should respect GIDs assigned to MI users.


The primary design challenges include:

  • Avoiding conflicts with already well-established GID values. Many GID values are already widely in use on Unix platforms, so there’s risk of collisions when integrating UW groups. This issue can be mitigated by avoiding the lower 16-bit range of GID numbers, reserving values below 65,535 for historical local users, while assigning only GIDs above 65,535.
  • Assigning GID values for existing UW groups. GIDs for all of the existing groups can be assigned in different ways: automatically from an available range, assigned by choice (i.e. a person picks), or many options in between. For example, group admins might be given the option of choosing a GID value from an available range, with the groups service automatically assigning a  value if no value is chosen after a certain period of time. A complex approach like this may require significant communication and would probably cost more to implement and support. By allowing GWS UI customers freedom to choose their own GIDs, even for existing groups for a limited time period, there is the possibility of customers later claiming they didn’t know about this period, and wanting a GID changed later. This would create an expectation that we allow and support GID changes which adds cost to the design and operations of the service. Additionally, GWS API clients would have to figure out how and when to assign GID values during group creation.
  • GID assignment to MI users is non-trivial. There are AD performance reasons to not assign all MI users the same primary GID. In specific, certain LDAP searches from Unix clients will be very inefficient and expensive when the LDAP filter involves the gidNumber attribute + any given gidNumber value is present on more than 1000 directory objects. This performance problem is unlikely to ever be addressed by Microsoft.

Design Options

For goal #1, two main options have been discussed for assigning GID values to groups.

Option 1A: Automatically assigned, immutable values.


  • The groups service automatically assigns a unique GID value when a group is created. Existing groups in the Groups Service will be assigned a GID similarly, except for legacy UW-IT unix groups which are assigned their existing GID (as represented in the UW-IT UA environment) in two distinct ranges noted in the table below.
  • Each GID value is immutable; once assigned to a group it cannot be changed.
  • GID values are assigned within a specific range, avoiding the 16-bit space (above 65,535), the range of likely negative GIDs, and the range used for MI user GIDs. See table below for specifics.


  • Existing customers integrating UW groups with their existing Unix groups may need to modify their GIDs and fix any file permissions referencing those GIDs.
  • Some customers may need to change existing local group GIDs if they are using GIDs above 65,535 to avoid collisions when integrating UW groups.


  • Low cost to entry for adding this capability
  • Low on-going support cost for this capability
  • Avoids collisions on most commonly used GIDs

Outlook: Good.

Option 1B: User-selected values.


  • Clients creating a new group have the option of picking a unassigned GID, otherwise it is assigned by the groups service itself or it isn’t provisioned to MI.


  • This option doesn’t handle multiple customers who want the same GID, but that problem can be solved with client tools like PowerBroker, etc.
  • This option may require an exception process to support GID changes after the fact when a mistake is made. This implies increased support costs.


  • Customers have greater degree of control of GIDs assigned

Outlook: Poor

For goal #2, three options have been discussed for assigning GID values to MI users.

Option 2A: Gating process


  • Some process is established, by which a MI user can be assigned a GID corresponding to a group that makes sense for that user. This would require establishing criteria which could be used to determine what is an appropriate group and may also require an approval process. Before a GID could be provisioned for a given user, that user would need to go through this process.
  • Useful, meaningful primary GID is assigned.
  • Hard to integrate your Unix computers with MI before you got all your users through the gating process.
  • Must develop process that takes into account multiple factors that include:
    • constrained to valid GIDs on existing Groups Service groups
    • approval from group owner to assign a group to a user
    • complex AD performance issue
  • Additional burden on all group owners to respond to primary group assignment requests
Outlook: Poor; unlikely to work without significant implementation costs and probably would also require significant buy-in and on-going involvement across all group owners.
Option 2B: Home group option


  • A MI user’s primary GID is the GID associated with that user’s Group Service home group, e.g. the GID for u_barkills would be barkills’s primary GID.


  • Every user has a unique GID that corresponds to an actual group.


  • Only users which can/have logged into the Groups service get a home group created. This prevents several classes of UW NetIDs from getting a primary GID, and requires users to access the GS to take part.
  • Some other approach for users which can’t log into the Groups service must be developed; this solution is incomplete.

Outlook: Poor; however, downsides might be addressed.

Option 2C: Unique value not corresponding to any group


  • Assign a unique GID from a range that is reserved. This GID doesn’t correspond to any Group Service group.


  • The primary GID isn’t meaningful/useful.


  • Every MI user can get a GID assigned immediately and new MI users can get a GID assigned at time of creation.

Outlook: good.

Open Issues

None that we are aware of.


Taking into account input from several subject matter experts, customers and other stakeholders, Option 1A + 2C are being recommended.

The recommendation for how the GID space is divided specific to the combination of 1A + 2C is:

Numerical Range
1-99 1-99 Reserved for legacy departmental uses
100-1192 100-1192 Reserved for legacy UW-IT unix groups
1193-19999 1193-19999 Reserved for legacy departmental uses
20000-20980 20000-20980 Reserved for legacy UW-IT unix groups
20981-2^16 20981-65536 Reserved for legacy departmental uses
(2^16+1)-2^30 65537-1073741824 Reserved for Group Service GID assignment
(2^30+1)-2^31 1073741825-2147483648 Reserved for MI user GID assignment
(2^31+1)-2^32 2147483649-4294967296 Reserved for legacy departmental uses. Addresses negative GIDs.