UW Windows Infrastructure Course Group Privacy Configuration

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.