Groups Service Integration
The Groups Service (GS) is designed to be an institutional repository for groups that are re-usable across multiple technologies. As such, it’s desirable for MI to be closely integrated with it. We encourage you to read more about the Groups Service, but we’ll cover a couple Groups Service topics here because they are relevant to how we integrate with the GS.
The GS currently supports 2 types of groups:
- standard groups
- course groups
Some of these groups have special optional features that include:
- membership privacy
- Exchange enabled
Support for these core features required custom schema modifications, implementation of the eduPerson schema, and configuration changes to support private membership.
Standard groups are basic AD groups, sometimes with a few fancy things on them, but usually they are very straightforward.
Groups with membership privacy are basic AD groups with special ACLs to keep the membership private.
Only groups without membership privacy can be Exchange enabled, which results in email-enabled security groups within the NETID domain that are usable as Exchange distribution groups or for authorization purposes on resources. Groups with membership privacy can not be Exchange enabled, unless approval by the relevant data custodian allows an exception. The Exchange enable mechanism currently is limited to Exchange support staff and requires a request to email@example.com, but in the future, any user of the Groups Service will be able to Exchange enable a group.
Course groups correspond to courses that students enroll in. Their membership is private because FERPA applies to them. 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)), and of course the members. The members include the enrolled students AND the instructor(s).
An example name of a course group (as represented in the NETID domain) is: course_2005sum-psych101a.
There are a large number of course groups in the NETID domain–usually about 30,000-50,000 at any one time. Course groups older than 3 quarters are automatically removed from the Groups Service and the NETID domain.
All course groups have membership privacy. Standard groups have the option of having membership privacy.
In either case, in the NETID domain group membership is kept private by a mechanism described in detail here. From a high-level, it’s important to know that the ‘Pre-Windows 2000 Compatible Access’ group is empty, and that by default, no one has access to the memberOf attribute on user objects. Some applications and services make assumptions about these two items, causing problems. The number of applications and services that make such an assumption is low, but it is something to keep in mind.
If you think your application has a problem because of this configuration, ask for help, as we know about some common workarounds.
Groups Of Note
Affiliation groups are groups that represent the eduPersonAffiliation values associated with each person. There is a known number of affiliations that correspond to affiliation groups that is unlikely to increase very rapidly. The affiliation groups are:
These groups have a large number of members, and have obvious use in terms of authorization.
GS to Active Directory Integration Details
All groups created by the NETID Group Sync Agent are created as universal groups to maximize their usefulness. In the future, additional AD group types might be supported, but at this time, that functionality is not present.
The GS supports a couple group member types that include:
- UW NetID
- Named certificate
- Group, i.e. support for nested groups
- Federated IDs
- NETID Computers
It’s possible that in the future, GS will support the greater diversity of member types allowed by Active Directory, maybe including: Exchange public folders, Exchange distribution lists, and contacts.
When the NETID Group Sync Agent encounters a member which it does not recognize, that member is discarded. This can happen in several cases:
- A UW NetID which:
- has been abandoned,
- has become a prior NetID (i.e. a UW NetID rename has happened),
- for which no Kerberos service is active,
- which doesn’t have a password, or
- was considered inactive and has been deleted.
- All named certificates are dropped, as they don’t map to any security principal object in Active Directory
- All federated IDs are dropped, as they don’t map to any security principal in Active Directory
The Exchange email-enabled group functionality does depend upon the Exchange services provided by the MSCA service offering.
How It Works
The NETID Group Sync Agent is a loosely coupled service that consumes event-based messages from the Groups Service. These event messages are sent to a 3rd party message bus which holds them until processed. The Group Service publishes a message for every change, and the NETID Group Sync Agent consumes these messages in real-time writing any needed updates to the NETID domain. This approach means that only the delta changes are processed, reducing the overhead for groups with many members. It also means latency for group changes is extremely low. Any unexpected problems result in alerts to UW-IT staff.
In addition to the near real-time event based service, a reconciliation process runs occasionally to identify and fix groups which have fallen out of sync with the Groups Service.
Should the NETID Group Sync agent go offline, the event messages remain, waiting to be processed. We have a geo-redundant hot-spare NETID Group Sync Agent which can take over processing of those messages. We occasionally switch the processing load to this GR spare to validate that it is operationally ready.
Details about how the data in the Groups Service is mapped to Active Directory are documented.