NETID Groups

Last updated: January 30, 2023
Audience: All UW

This document discusses NETID Groups and how to make use of them, referencing additional background material.

Introduction

This document focuses on how to create, manage and use NETID groups. We’ll also explore the different types of groups and uses of each, and how group naming variations factor in.

Group Creation and Management

It’s not possible to manually create or manage groups in NETID directly with Active Directory Users and Computers (ADUC). Instead, all groups are created via the UW Groups Service.

The UW Groups Service introduction page discusses basics about how to get started using it, and has many overlaps with the NETID groups material here. You are encouraged to read that material. We’ll repeat the bits most relevant to NETID here.

To create or manage NETID groups, you’ll need to go to the Groups Web Service (GWS) interface.

It is possible to have groups created ONLY in NETID, even with names that do not conform to the UW Group Service naming. If you find you need this, please make a request via help@uw.edu. If all you need is a naming exception for the UW Group Service, you can ask for that too.

UW Group Service and NETID

Changes made at the UW Groups Service will propagate to NETID. The usual synchronization latency time is on the order of minutes, however, on several days of the year (bulk quarterly course group creation) there can be a larger latency which may mean a latency of up to a day. To read more about group synchronization, consult the relevant portion of the MI Architecture Guide.

Currently, all groups provisioned from the UW Groups Service are created as a universal group type in NETID to maximize their potential outside the forest. Universal groups can be placed in universal groups or domain local group in an external domain/forest or be used directly on resource ACLs on computers in an external domain/forest. At some point in the future, the UW Groups Service will enable you to choose the Active Directory group type.

The UW Groups Service permits group members which do not correspond to existing groups or UW NetIDs. When the NETID synchronization process encounters a member which does not correspond to a valid NETID user or group, it ignores that group member.

The UW Groups Service does not currently support several possible Active Directory member types, including  contacts and Exchange public folders. Feature requests for this functionality are on the UW Group Service backlog. If you have a need involving these, please make a request via help@uw.edu and we’ll see whether it can be accommodated manually.

The UW Group Service does support NETID computers as members. gMSAs are considered NETID computers and can be added using the same format as a NETID computer.

Using NETID Groups

For detailed examples of how to make use of NETID groups, see these FAQs:

How do I make use of NETID groups across a trust?
How do I limit access to a share or folder to students in a particular course?
How do I limit access to a Web page to just faculty and staff?

You can tell a great deal about a group’s intended use from the name. Knowing the background behind group naming and about data-driven groups (i.e. groups whose membership is automatically derived from enterprise data) may be invaluable in helping you to make better use of a NETID group.

Adding NETID computers as a Group Member

To add a NETID computer as a group member via the Groups Web Service UI, enter:

w:NETID-computer-netbiosname$

For example, to add luke.netid.washington.edu to a group, you’d specify:

w:luke$

as a group member.

Group Naming and Type

Groups in the UW Groups Service are organized by stem. A stem is a string which might be thought of as a prefix in the group name. Stems are always followed by a delimiter, in this case an underscore (_). There are several common top-level stems:

  • Course Groups: course_

Course groups correspond to courses that students enroll in. Course groups are an example of data-driven groups whose membership is automatically derived from enterprise data. Course membership is private. Course groups have lots of bits of info associated with them including:

  • displayName (the course title)
  • uwYear (the year offered)
  • uwQuarter (quarter offered: SUM|SPR|WIN|AUT)
  • uwSln (the decimal number in the catalog for this course)
  •  uwCurric (the departmental discipline)
  • uwCrsNo (the course level number)
  • uwSectID (the section)
  • uwInstructor (the instructor(s))
  • members

Within NETID, the members include the enrolled students AND the instructor(s). Within GS, students and instructors are kept separate, and there is no “member”. An example name of a Course group is:

course_2005SUM-PSYCH101A

  • UW Groups: uw_

“uw_” stem groups are used for organizations. They generally represent groups which have some official standing at the UW. One notable example of uw_ stem groups are affiliation groups.

Affiliation groups are groups that represent the eduPersonAffiliation values associated with each person, and are data driven groups. There is a known number of affiliation groups that don’t often change. The affiliation groups are:

  • uw_affiliate
  • uw_alum
  • uw_employee
  • uw_faculty
  • uw_member
  • uw_staff
  • uw_student

These groups have a huge number of members and have wide use across a variety of scenarios.

Students, faculty, and staff are just what you’d think: all UW NetIDs with an active Kerberos subscription and those respective affiliations.

Member is intended to include faculty, staff, student, and other persons with a basic set of privileges that go with membership in the university community (e.g., they are given institutional email and calendar accounts). It could be described as “member in good standing of the university community.”

Employee is intended to include people who are active faculty or staff.

Alumni is intended to include people who have some active relationship with the university (i.e. at least one other affiliation) and were students in the past.

Affiliates are people with a UW NetID with an active Kerberos subscription, not student, staff, or faculty, and some relationship to the university.

Only a fraction (~1/4 at the time this document was written) of all UW NetIDs are a member of one of the affiliation groups.

  • Adhoc Groups: u_

Adhoc groups are basic groups–nothing fancy about them. All adhoc groups are associated with either a personal UW NetID or a shared UW NetID. Those associated with a personal UW NetID are generally used for protecting resources managed by a single person. Additionally, some computing services (e.g. MI itself) leverage adhoc groups with a shared UW NetID. Some example names of adhoc groups are:

u_barkills_mygroup
u_windowsinfrastructure_readallcomputers

  • Hierarchy Less Groups: g_

Hierarchy less groups also are fairly straightforward. What distinguishes these groups is that they are not based on a UW NetID, nor on a recognized UW organization. Currently, these groups are NETID-only and managed by UW-IT, but at some point in the future, they will be managed by the UW Groups Service. An example name of one of these groups (as represented in NETID) is:

g_PotteryAdmins

In addition to these stem-based distinctions, there are a couple other possible qualities of all groups which are notable. These are:

  • Privacy groups

Privacy groups can be any kind of group. When a group is private, some portion of the group is not generally readable. There are two types of privacy groups:

  • Membership private groups are the most common type of privacy groups. With membership private groups, the membership is not readable by any UW NetID. You can choose who can read the membership.
  • Complete private groups restrict all the non-operational attributes of a group. The name and a few other obscure attributes are not restricted, but most information, including the membership, is restricted to only those users you allow.

There are many privacy groups in the UW GS and NETID today. You can not Exchange mail-enable a privacy group due to the leaky nature of the Exchange GAL via Outlook Web Access. Exceptions can be granted, so do ask if you have a strong business need to Exchange-enable a privacy group.

  • Exchange Mail-enabled groups

Exchange mail-enabled groups are simply AD security groups which are also an Exchange distribution group.

In addition to course groups and affiliation groups, there are other data-driven groups, some planned and others not well-documented yet. Examples include:

For the most part, data driven groups are a feature of the UW Group Service and you are encouraged to engage with the UW Group Service team to identify needs which might be met by this kind of functionality.