What is Azure AD Connect, and does your organization need it? To answer that, let’s take a step back and look at the big picture. Many organizations today rely heavily on the Microsoft cloud. In particular, solutions like Microsoft 365, Microsoft Teams, SharePoint Online and OneDrive for Business have become essential for effective collaboration among geographically dispersed workforces.
However, many companies have good reasons to also maintain an on-premises Microsoft environment. For example, they might have legacy applications too difficult to migrate to the cloud or highly sensitive data that must be stored locally to address specific security or regulatory compliance concerns.
But it’s simply not practical for most organizations to maintain two separate identities. First of all, it’s not a good experience for business users. They don’t care — or want to have to care — where a piece of content or an application they need is hosted, and they definitely don’t want to be constantly prompted to provide their credentials for the “other” environment. It’s also bad for IT teams, who are loath to have to manage two completely separate sets of user identities; it would double the provisioning work and inevitably lead to mistakes that jeopardize both security and productivity.
Fortunately, Microsoft provides two tools to help: Azure AD Connect sync and Azure AD Connect Cloud sync. Here’s what you need to know about these valuable applications.
What is Azure AD Connect?
Azure AD Connect is a Microsoft tool designed to help organizations with hybrid IT environments. It is included for free with your Azure subscription. It offers multiple features, including federation integration and health monitoring. However, today we’ll focus on its best-known capability: synchronization.
Simply put, organizations use Azure AD Connect to automatically synchronize identity data between their on-premises Active Directory environment and Azure AD. That way, users can use the same credentials to access both on-premises applications and cloud services such as Microsoft 365.
How does it work?
You install the application on a domain-joined server in your on-premises data center. The default installation option is Express Settings, which is used for the most common scenario: synchronizing data between a single on-premises forest that has one or more domains and a single Azure AD tenant. If you have multiple forests or multiple Azure AD tenants, check out the other topologies that Microsoft supports.
By default, the sync is one way: from on-premises AD to Azure AD. However, you can configure the writeback function to sync changes from Azure AD back to your on-premises AD. That way, for instance, if a user changes their password using the Azure AD self-service password management function, the password will be updated in the on-premises AD.
What data can the tool sync?
Azure AD Connect can synchronize the user accounts, groups and credential hashes in your on-premises AD. Most attributes of the user accounts, such as the User Principal Name (UPN) and security identifier (SID), are synchronized.
However, the following objects and attributes are NOT synchronized:
- Any objects and attributes you specifically exclude from the sync
- SidHistory attributes for users and groups
- Group Policy objects (GPOs)
- The contents of the Sysvol folder
- Computer objects for computers joined to the on-premises AD environment
- Organization unit (OU) structures
How often is data synchronized?
The synchronization is controlled by a scheduler. By default, a sync task runs every 30 minutes.
Using PowerShell, you can:
- Review the scheduler’s configuration and change some of its parameters.
- Force a sync.
- Stop a running sync task or even temporarily disable the scheduler (for example, so that you can modify the configuration of Azure AD Connect).
Best practices for using Azure AD Connect
It’s important to understand and follow best practices for using any application — especially any tool that touches Active Directory and Azure AD, the beating hearts of your IT ecosystem. Here are the key ones to keep firmly in mind when using Azure AD Connect.
Protect the server like a domain controller.
Protect the server where Azure AD Connect runs as if it were a domain controller. In particular, limit who has local administrative rights on the server, limit the accounts that can log in interactively, and control physical access to the server. In addition, make sure that the service account for the tool has only the rights it needs, and strictly adhere to best practices for password complexity and expiration.
Keep a close eye on who can use the tool.
By default, the only people who can use and manage the sync engine are the user who installed it and local admins on the machine where it runs. To empower other users to access the tool, add them to the ADSyncAdmins group on the local server. But given the power of the tool, it’s critical to be judicious when expanding this group.
Carefully curate which groups you sync to Azure AD.
The default configuration will synchronize all user and group objects (except as detailed above) from your on-premises AD to Azure AD. But not all of your on-premises groups will actually serve any useful purpose in the cloud. (In fact, many of them might even have outlived their usefulness on-premises — group sprawl is a common problem and regular group cleanup is smart for both productivity and security reasons.)
The best practice for synchronization is to look over all of your on-premises groups with a critical eye. Remember, there are two basic types of AD groups: security groups, which act as the trustee for securing an item such as a file share or SharePoint list, and distribution groups, which simplify communications addressing (primarily email). Then use the sync engine’s filtering capability to exclude any groups that are not relevant to your cloud environment.
Before you start making changes to the filtering, remember to temporarily disable the scheduled sync task so that your changes don’t get implemented before you can verify that they are correct.
In particular, don’t sync on-premises admin groups to Azure AD.
The purpose of on-premises admin groups, such Domain Admins, is to enable management of the on-premises directory. Synchronizing these groups to Azure AD offers zero benefit. However, it does introduce unnecessary risk, since those groups will be exposed to more prying eyes — a user in Azure AD can see the membership of the (useless) admin group and know exactly which on-premises accounts to target with phishing or other attacks. Therefore, it’s critical to use the filtering capability to exclude all admin groups from the sync.
Instead, use Azure AD functionality to manage Azure AD.
To manage Azure AD, establish appropriate cloud-only administrators using the predefined roles, such as Global Administrator, Application Administrator, Compliance Administrator and SharePoint Administrator. Remember that a Global Administrator can modify any administrative setting in your Azure AD organization, which is why Microsoft recommends assigning this role to no more than five people in your organization. In addition, take advantage of the features Microsoft offers to add additional security to accounts that are assigned an administrative role, including multifactor authentication (MFA) and privileged identity management (PIM).
As for groups, the hybrid groups you choose to sync up from your on-premises AD are just the start. You can create cloud-only groups, including not just security groups and distribution groups but also Microsoft 365 groups. A Microsoft 365 group can secure items like a security group can; it can function as a distribution list like a distribution group can; and it can also act as a data repository backed by SharePoint and shared mailboxes. Microsoft 365 groups are used in every team in Microsoft Teams as well. Take care to avoid (or clean up) group sprawl in the cloud as well as on premises.
Follow Microsoft recommendations for your sync schedule.
By default, a sync runs every 30 minutes. You can modify the sync cycle, but Microsoft says that a sync must run at least once every 7 days, as follows:
- A delta sync must happen within 7 days from the last delta sync.
- A delta sync (following a full sync) must occur within 7 days from the time the last full sync completed.
Failure to follow these recommendations can result in issues that can be resolved only by a full sync, and full syncs can be very time consuming.
Don’t treat Azure AD Connect as your cloud identity management and backup & recovery solution.
Many organizations have put a great deal of thought and effort into managing and protecting their on-premises Active Directory. But don’t be fooled into thinking that synchronizing your AD up to Azure AD automatically means your cloud IT environment is properly managed and backed up. One of the key reasons is that while most Azure AD objects are synchronized from on-premises AD, they often have certain additional attributes that exist only in the cloud, such as the user’s Office 365 licenses, roles and conditional access policies. If a user object with one or more cloud-only attributes is deleted, you could recover the on-premises AD user object and use Azure AD Connect to synchronize it back up to Azure AD — but the cloud-only attributes would be gone, and the user would be unable to access any Office 365 applications or perform their role-related duties.
Reduce your AD attack surface.
Although the Azure AD Recycle Bin might be able to come to your rescue in this case, it’s also possible for a cloud-only attribute to be deleted from an object, instead of the whole object being deleted. Since the Recycle Bin is for deleted objects only, you cannot use it to recover from an improper modification to an object. Therefore, it’s essential have an enterprise-level backup and recovery solution for your cloud environment. You can learn more about the gaps Azure AD Connect leaves in your cloud recovery strategy in this white paper.
A new option for synchronization
Microsoft now offers another synchronization tool: Azure AD Connect cloud sync. With this option, you deploy a lightweight agent in both your on-premises and IaaS-hosted environments and manage its configuration in Azure AD.
The two sync applications offer overlapping but not identical functionality. In particular, Azure AD Connect cloud sync supports synchronizing from a multi-forest disconnected Active Directory environment (useful particularly in merger & acquisition scenarios) and using multiple provisioning agents (which can simplify high availability environments). However, unlike Azure AD Connect, it does not support either writeback or synchronization of customer-defined AD attributes.
Microsoft provides a detailed feature comparison to help you choose the right synchronization option for your needs.
