In this video, Pete Zerger explains how to synchronize your on-premises identities to Azure Active Directory with Azure AD Connect. Learn how Azure AD Connect synchronization rules and filtering enable you to customize the directory synchronization proces
- [Instructor] Now we're going to talk through the considerations for fully enabling Azure Active Directory in our production organization. Azure AD Connect synchronizes identity data between our on-premises environment and Azure AD. This allows us to maintain a common identity and single sign-on for our users for Office 365, Azure, and SaaS apps integrated with Azure AD. Azure AD Connect is made up of three primary components, the synchronization service, the optional Active Directory Federation Services component, and a health-monitoring component.
Let's take a deeper look at the Azure AD Connect Sync engine to understand how to best configure Azure AD Connect for our environment. The Sync engine creates an integrated view of objects that are stored in multiple connected data sources, and manages identity information in those data sources. Azure AD Connect includes an express settings option, designed for organizations with a single Active Directory forest, and password synchronization. Think, synchronized identity model.
This is the default option, and is used for the most commonly deployed scenario. Data repositories, Windows Server Active Directories that are synchronized by the Sync engine, are called connected data sources. Connectors make API calls to exchange identity information, both read and write, with a connected data source. Connector spaces are staging areas that contain representations of the designated objects from a connected data source and the attributes specified in the attribute inclusion list.
The metaverse is a central storage area that contains the aggregated identity information from multiple connected data sources, providing a single, global integrated view of all the combined objects. Metaverse objects are created based on the identity information that is retrieved from the connected data sources, and a set of rules that allow us to customize the synchronization process. Incoming data can be filtered using inbound sync rules, which are recommended because they're generally the easiest to maintain.
With inbound filtering, we use the power of scope to determine which objects to synchronize or not synchronize from the connected source. In some cases, it's necessary to do the filtering only after the objects have been joined in the metaverse, such as when we need to compare values from an active directory resource and an account forest. This is called outbound filtering, and for these cases, we'll use outbound sync rules. We should really only use outbound filtering if it's required to join objects from more than one forest, before the evaluation can take place.
There are four options for filtering objects, and object types, that are synchronized to Azure AD. The first is group filtering, which is only available during initial setup, and is really designed to facilitate a pilot deployment. Domain-based filtering determines which Active Directory domains will be synchronized, while OU-based filtering determines which AD organizational units will be synced. And finally, attribute-based filtering enables filtering objects based on attribute values on the objects.
We can also have different filters for different types of objects. And finally, we can use positive or negative filtering. With negative filtering, we tell Azure AD Connect, "Don't sync these," to exclude specific objects or object types. With positive filtering, we tell Azure AD Connect, "Only sync these." This can be more challenging, because we often need multiple sync rules to ensure only the objects or object types we want to include are synchronized. Writeback is a feature that enables values written to Azure AD to be replicated to our on-premises Active Directory, enabling enhanced capabilities in a handful of key scenarios.
Device writeback enables conditional access based on devices in Active Directory Federation Services scenarios for protected applications. This would come into play in the federated identity model. Group writeback allows us to write back Office 365 groups, which are mastered, think created and managed, in Azure AD to a forest with Exchange installed. But most important to discussions in this course is password writeback, which allows us to configure our Azure AD tenant to write passwords back to our on-premises Active Directory.
This is important later, when we enable self-service password reset in Azure AD, so when our users reset their passwords in Azure AD, their passwords in our on-premises Active Directory match, maintaining single sign-on. Writeback makes synchronization a two-way process. While there's not much documentation about this, Windows 10 computer objects are automatically synchronized by Azure AD Connect. This basically auto-registers Windows 10 and later devices in Azure AD, enabling a number of advanced authentication and management scenarios.
Windows 7 and 8 device registration is possible, but only in the federated identity model, with Active Directory Federation Services. Azure AD Connect Health will monitor not only Azure AD Connect sync activity, but health and usage stats of Active Directory Federation Services in the federated model, and Active Directory Domain Services, extending monitoring for our Active Directory Domain Services on-premises, giving us a single pane into the health of our hybrid identity.
We can set up alerting and delegate admin rights to co-workers, but we do need to install an agent on our Active Directory domain controllers to enable that hybrid capability.
In this course—the first in the series—Microsoft MVP Pete Zerger takes you through the basics of setting up endpoint protection. He begins by explaining how to set up Azure Active Directory Premium. Next, he goes into enabling multi-factor authentication, followed by setting conditions for secure access. To wrap up, Pete covers managing mobile devices with Intune, and publishing applications with Azure AD App Proxy.
- Setting up Azure Active Directory for an organization
- Enabling user-level and application-level multi-factor authentication
- Setting conditions for secure access
- Planning a mobile device management (MDM) strategy
- How Intune (standalone) MDM works
- How Intune mobile application management works
- Publishing applications with Azure AD App Proxy
- Assigning users and groups