Understanding Federated Resources, Forward Syncing, and Loose Coupling in Office 365

Buried among one of the sessions on Office 365 Groups at last week’s Microsoft Ignite conference in Chicago, I came across some interesting architectural information about how Office 365 manages identity data between its different services. In this Ask the Admin, I’m going to share the basic concepts of how Office 365 group and user objects are managed under the hood, which can be useful to know when troubleshooting or administering Office 365.

Azure Active Directory

Azure Active Directory (AAD) is the identity management nucleus of Office 365. Regardless of the identity model that you decide to use with Office 365, i.e. cloud, synchronized, or federated identity, AAD always maintains a single source of truth for group and user identities in the cloud.

What may not be immediately obvious is that Office 365 services, such as Exchange and SharePoint, are able to function independently, relying on groups and notifications to make them intelligently aware of each other. This lack of dependencies between services has been baked into the design of Office 365 from the get go, to ensure maximum flexibility.

Federated Resources

In practice, this requires that Exchange and SharePoint maintain their own private AD instances, containing replica objects from AAD. This may seem counterintuitive at first, but it’s important to understand that these additional AD databases can never be updated directly by users or tenant administrators. No matter from which part of the Office 365 management interface a new user or group is created, that information is always created first in AAD.

The redundancy provided by multiple AD databases brings improved performance and resiliency for individual services; so if one service or AAD goes offline, the impact of the outage is limited, and users may not even notice there’s been an infrastructure failure elsewhere. And despite the segmentation of Office 365 services, the user experience across the suite remains integrated.

In Microsoft’s presentations on Office 365 at the conference, there was a lot of talk about one source of truth in different contexts, and AAD sits at the top of a trickle-down hierarchy where all changes are made at the highest level, and then filtered down to service AD databases, a system Microsoft refers to as Forward Syncing.

Group creation flow in Office 365 (Image Credit: Microsoft)

Loose Coupling and Notifications

Office 365 services also use notifications from each other to update their own private copy of AD objects. For example, if a new group is created from within Outlook Online, the task is delegated to AAD, and only then Exchange Online creates a local copy of the group. Exchange then notifies SharePoint Online that a new group has been created, and a copy is also provisioned in SharePoint Online AD. While a group may not actually be required in SharePoint at this point, it’s created in anticipation that it will be required in the future, to make any SharePoint operations that rely on the group complete faster.

If the group is later updated, i.e. members added or deleted, AAD forward syncs the updates to Exchange and SharePoint Online AD. Microsoft calls this system of notifications combined with forward syncing loose coupling, meaning that if a user or administrator creates a new group, it may not instantly appear in Exchange or SharePoint. But after a short time, ranging from 30 seconds to a few minutes, the new group object should appear in the services where it’s needed.