One goal at many universities has been to provide a collaboration solution for students, based on email. To do this in Exchange, an administrator needs to create a distribution list to represent the class and populate it with the user accounts. Each distribution list has a members property and each user has a memberOf property, both of which are multi-valued attributes. This is where the problems begin.
The Family Educational Rights and Privacy Act (FERPA) allow directory information on students to be published with permission, some information, such as the students' class schedules, must remain protected. Further, with the introduction of Exchange 2007, Microsoft removed the functionality to hide membership of a distribution list (DL) from the interface because it wasn't a true security solution. It couldn't protect the memberOf attribute on the user object, which meant the security was really only one way.
What we're left with is a non-solution for addressing this common business challenge at colleges and universities. Well, not entirely. There is a massively complex mechanism in Exchange 2007 that could potentially hide both the members property of the DL and the student's class schedule (which would normally be read from the memberOf attribute). The mechanism is the Dynamic Distribution Group (DDG) using a custom oPath filter.
By default, Exchange 2007 ships with a really crappy oPath editor/wizard thing that allows you to do almost nothing useful in the creation of DDGs. They augment this with a very useful PowerShell functionality that, because of a bug, doesn't actually work either. Of course, all of this requires a new language called oPath, which is really just a dumb man's LDAP and it doesn't seem to have any purpose other than to create an LDAP filter. (So, basically, the Exchange team creates a new complex query syntax whose only purpose is to translate into another complex query language that most of our customers were already learning anyway, but I digress).
So what is the solution? The solution is comprised of three steps: (1) create a standard security group, (2) populate the security group with users, and (3) build a custom dynamic distribution group whose filter is based on a user's membership in the security group. An example explains this better.
I have three students: StudentA, StudentB and StudentC. All three students belong to a class called MATH171S2: Calculus I – Section 2. A security group called "f757b582ed2d3c241a798ff98c19774e" is created and populated with all three members. Then, using the PowerShell interface, a Dynamic Distribution Group is created. The filter query for this group seeks membership in the "f757b582ed2d3c241a798ff98c19774e" security group.
Normally, this would be considered task-complete. However, if you validate the membership list, you'll notice it's empty…
But really it's not, because the following alteration to the PowerShell cmdlet does give us the DL membership.
What's going on? Well, it turns out that the LDAP path we entered in the New-DynamicDistributionGroup cmdlet didn't translate properly. Instead, it was saved as an oPath query into an AD attribute that expects an LDAP query. If you look at the msExchQueryFilter attribute, you will see that 'CN= f757b582ed2d3c241a798ff98c19774e,CN=Users,DC=contoso, DC=edu' has been replaced with 'contoso.edu/users/f757b582ed2d3c241a798ff98c19774e' which is invalid, causing the failure. Note that if you try to view the membership in the Exchange console, it will terminate and unload the module from MMC 3.0. You must go in and change the msExchQueryFilter attribute back to its proper value.
Another potential gotcha to watch out for is the scope of your filter. Above, we set the –RecipientContainer attribute to the default domain container. This tells Exchange that when searching for matches against the LDAP query, start in the default domain container and search it and all its child containers. If your membership list seems only somewhat populated, you may have specified a bad RecipientContainer value. This can be edited in the msExchDynamicDLBaseDN attribute of the DDG object in Active Directory.
Is it worth it? Clearly, this proposed solution puts the F in FERPA compliance. It will require some sort of data store to manage the relationship between DDGs and SGs and creation of such groups (in large numbers) will require ADSI code to edit the various attributes back to their correct values. However, this can be done fairly easily, but what do we really end up with.
1. The user's membership in the security group is not visible in Outlook, but would be visible in raw LDAP queries against the directory.
2. Assuming the proper algorithm and salting, a user with access to the SG aliases will not be able to derive the DDG class names.
3. A user with LDAP access to Active Directory will be able to view DDGs' attributes and derive which SGs they are associated with.
4. With explicit denies granted to domain users (people only) on the msExchDynamicDLFilter and msExchQueryFilter attributes, the association between the DDG and SG can be secured. However, this must be done such that Exchange and AD administrators will have access to these attributes for management purposes.
All in all, it's a complex solution for what should be a trivial task, but I am open to your criticisms, suggestions and comments.