Event-Driven Architecture for Synchronizing Active Directory Groups Nathan Dors – University of Washington Eric Kool-Brown – University of Washington

Active Directory in Higher Ed IT Granting access to Windows resources via Access Control List entries Best practice to use groups as ACE trustees rather than individual user accounts Groups being used as Exchange Distribution Lists Interop with Linux/Unix systems via LDAP, Kerberos, and SAMBA Customers continue to figure out new ways to use our AD services EDA & Syncing AD Groups

Connecting Access Management Systems The Vision Seamless information flow through IT systems Architectural agility for updating IT systems Traditional Solutions Domain-specific, hardwired, batch oriented Scheduled rather than real-time IDM Suites (OpenIDM, OIM, AD/FIM) Relatively heavyweight alternatives Enterprise Integration Patterns Guidance on how to roll your own heavyweight system Event Driven Architecture – a lightweight approach EDA & Syncing AD Groups

Event Driven Architecture EDA facilitates the transfer of information between producing and consuming systems It is a design pattern that decouples components An intermediate component: a message queue An intermediate format: a message schema Flexibility as to the propagation model It provides near real-time information propagation Components and systems can evolve independently The message schema is versioned EDA can facilitate a GR/DR capability if the queue is in the cloud EDA & Syncing AD Groups

Propagating Access Management Changes The UW uses Grouper as the groups data master There are multiple downstream consumers of Grouper changes AD changes used to be pulled via scheduled batch processes We switched to EDA via Apache ActiveMQ a year ago Requires in-house hardware and support We are moving to Amazon SNS and SQS AWS is an attractive option due to simplicity, flexibility, and reasonable cost Trivial to add new consumer queues to an SNS topic EDA & Syncing AD Groups

Information Security Considerations Group data risk assessment and classification Assessment conducted by Michael Brogan 2 years ago UW policy data classes: public, restricted, or confidential Groups have a hierarchical administrative model Admin controls on who can create groups and modify their attributes and membership Group data is signed and encrypted while in transit In addition to the SSL data channel encryption Groups with viewer restrictions cannot be Exchange -enabled EDA & Syncing AD Groups

UW AD as a Group Event Consumer Group Sync Agent is a Windows Service and reads from the ActiveMQ or SQS queue Periodic reconciliation compares Grouper data to AD data and adjusts the latter as needed Group viewership restrictions result in the updating of AD group ACLs Brian’s Hiding Data in AD Administrative model is enforced in Grouper, AD groups updated only by Group Sync (with a few exceptions) AD replication latency issues resolved by using domain controller affinity Event queues are abstracted as interfaces EDA & Syncing AD Groups

What's Next? Completing the switch over to Amazon SNS/SQS Implementations for other queues, e.g. Azure Message Bus? Using the message queue model for bi-directional group change flow (for those exceptional groups) Perhaps inserting a workflow processor in place of a simple queue Sharing code? EDA & Syncing AD Groups

Conclusion Happy with results, it’s very reliable and usually quite fast ~50k messages per month Course group creation at quarter start imposes an unusual load; ACL setting causes queue back ups Prioritizing interactive group changes over bulk updates Release course creation over a longer period of time Looking at other places were the EDA pattern can be applied EDA & Syncing AD Groups

Appendix EDA & Syncing AD Groups

EDA & Syncing AD Groups