Yesterday I placed the UW Windows Infrastructure (UWWI) AD group synchronization source code into a publicly accessible repository on BitBucket.org. This code has been made available for perusal and reuse by the UW via an Apache 2.0 license. You can find it at https://bitbucket.org/uwitiam/group-sync.
The UW Groups Service places all change events on an Amazon SNS topic. The UWWI Group Sync agent reads an Amazon SQS queue that is attached to this topic. I gave a presentation on this event-driven architecture for distributing group changes at last year’s InCommon Identity Week conference. You can find that presentation here.
The UWWI Group Sync Agent updates the UWWI Active Directory based on these group change events. This is an extremely complex task that requires a detailed knowledge of AD. For example, making rapid successive changes to an AD object can be problematic if you don’t make all of the reads and writes to the same domain controller. AD uses a replication methodology known as “eventual consistency” which means that simultaneous reads from multiple DCs may not yield the same results. The solution to this issue is to use DC affinity; always bind to the same DC when making multiple reads and writes.
Another point of complexity is due to the changes that were made to the UWWI AD to give FERPA compliance. FERPA is a Federal statute that requires that student data be kept confidential. Active Directory was designed for a corporate environment where ease of access would grease the skids of commerce. IOW, any authenticated user can read a wide set of properties on any other object including group memberships. Unfortunately this design assumption leads to a violation of FERPA where the names, classes and other student details could be readable by any AD user. Brian Arkills, the UWWI Service Manager, designed a set of changes to AD to remove this default behavior. You can read about these changes here. Thus the Group Sync agent must ascertain the type of group, public or restricted, and set the appropriate ACLs.
UW Groups can be set to be Exchange-enabled. That is, they can act as both security groups to gate access to resource and they can be email distribution groups. The act of Exchange-enabling a group is a multi-step process. The first step is choosing to Exchange-enable a group in the UW Groups Service. One important part of this step is deciding on the email address for the group. The Groups Service validates that the chosen address is valid and unique. The Group Sync Agent then takes this info from the Groups Service change event message and creates or modifies the AD group, adding all of the attributes required for Exchange-enabling a group.
You can see more on the Group Sync Agent here.