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.
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.
With thanks to Mike Kanofsky at University of Florida, the following recipe creates an AD environment where groups with a private membership are possible:
£ Might need to replace Domain Users with Authenticated Users if you trust other domains
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.
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()
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.
This alternate solution carries many side effects, including: