Group Member Privacy

Last updated: January 30, 2023
Audience: IT Staff / Technical

This page describes the background for an AD configuration we’ve made to the NETID domain, as well as the specific details about how we’ve made that configuration.

The Problem

Many groups have membership which in conjunction with the group name is considered sensitive or confidential data.

A common example of this are course groups. FERPA says that US schools must respect a student’s right to protect their educational record. For this reason, if you can view the membership of a course group, directly or indirectly, you may be in violation of FERPA.

There are many other examples of groups like this–course groups are not the only case.

By default, Active Directory allows all domain users to view all user, group, and contact data. This is a problem because if you can read either the group object member attribute or a given user’s memberOf attribute, you have not protected group member privacy.

The Solution

With thanks to Mike Kanofsky at University of Florida, the following recipe creates an AD environment where groups with a private membership are possible:

  1. Yank all members of the ‘Pre-Windows 2000 Compatible Access’ group.
  2. Set the following inherited ACEs on the OU containing the groups you want to protect:
    1. Deny Domain Users£ : Read Membership for Group objects
    2. Allow Domain Users£ : Read for this object and all child objects
  3. For each group you want to protect, remove two explicit ACEs:
    1. Allow Authenticated Users : Read
    2. Allow Self : Read

£    Might need to replace Domain Users with Authenticated Users if you trust other domains

Known Side Effects

The ‘Pre-Windows 2000 Compatible Access’ group usually is populated with either ‘Everyone’ or ‘Authenticated Users’ (depending on what decision you made at domain setup time). The ‘Pre-Windows 2000 Compatible Access’ group has an explicit Allow Read ACE on every user, computer, and group object, so this change will affect some behavior, but to date, we’ve seen nothing serious.

By default, after implementing this, no one except AD administrators can read the MemberOf attribute on user objects.

.NET code to Add/Remove ACEs

For your benefit, here is sample Visual Basic .Net code to accomplish step c above:

Dim ferpaGroup As New System.Security.Principal.NTAccount(“netid.washington.edu”, “FERPA-Registrar Authorized”) Dim ferpaGroupAsSecurityIdentifier As System.Security.Principal.SecurityIdentifier = ferpaGroup.Translate(System.Type.GetType(“System.Security.Principal.SecurityIdentifier”)) Dim domainSid As System.Security.Principal.SecurityIdentifier domainSid = ferpaGroupAsSecurityIdentifier.AccountDomainSid Dim authUsers As New System.Security.Principal.SecurityIdentifier(Security.Principal.WellKnownSidType.AuthenticatedUserSid, domainSid) Dim self As New System.Security.Principal.SecurityIdentifier(Security.Principal.WellKnownSidType.SelfSid, domainSid) Dim rule As New System.DirectoryServices.ActiveDirectoryAccessRule(authUsers, System.DirectoryServices.ActiveDirectoryRights.ReadProperty, System.Security.AccessControl.AccessControlType.Allow) Dim rule2 As New System.DirectoryServices.ActiveDirectoryAccessRule(self, System.DirectoryServices.ActiveDirectoryRights.ReadProperty, System.Security.AccessControl.AccessControlType.Allow) ADEntry.ObjectSecurity.RemoveAccessRule(rule) ADEntry.ObjectSecurity.RemoveAccessRule(rule2) ADEntry.CommitChanges()

Other Known Solution

With thanks to Ross Wilper at Stanford University, the following recipe also creates an AD environment where groups with a private membership are possible. To be clear, UWWI does NOT use this solution.

  1. Modify default schema for user objects to strip all default ACEs.
  2. Configure OU(s) with users with inherited ACEs as you desire.
  3. Set desired ACLs on OU containing groups.

This alternate solution carries many side effects, including:

  • With every Microsoft schema change, must:
    • Turn off user provisioning and re-modify the schema to strip all ACEs from default user objects
    • Must consider whether any new ACEs added to user objects should be added to the inherited ACLs on OUs
  • Departmental administrators must be granted permissions in order to troubleshoot all group access issues.
  • By default, after implementing this, no one except AD administrators can read the MemberOf attribute (or any other attribute depending on what inherited ACL you added) on user objects.