20130524: Adding GID Support to the Groups Service and MI

Status

This proposal was implemented. Track progress via these items:

• GRP-582 – Each group has a unique, immutable GID value. Closed
• MI-394 – Automatic 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.

Background

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.

Assumptions

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

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

Challenges

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.

Description:

• 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.

Downsides:

• 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.

Benefits:

• 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.

Description:

• 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.

Downsides:

• 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.

Benefits:

• Customers have greater degree of control of GIDs assigned

Outlook: Poor

Open Issues

None that we are aware of.

Recommendation

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: