Conditional Access policies are the best method to secure your Microsoft 365 tenant. But when configured wrong, they can cause unwanted problems. One of those common issues is accidentally blocking your Azure AD Connect Sync client.
The error is often noticed after a couple of days when the Sync Status in the Microsoft 365 Admin Center shows that it was last synced more than 3 days ago. Other indicators are event IDs 906 and 904 in the event viewer.
In this article
In this article, we are going to look at how to find the cause of the sync error and how to solve it.
Finding the AD Sync Error
The first step is to identify the exact cause of the AD Sync error. There are a couple of places where we can find more information about the error and its cause. Where to start depends a bit on where you have found the initial error message.
Microsoft 365 Admin Center
In the Microsoft 365 Admin Center, you will see the AD Sync status on the Dashboard view. This will show when the last successful sync was. If you click on the Sync Status it will show more details about when it was last synced.
When the problem first occurred is always important to know. It allows you to track back if you have made any changes around that day that could have impacted the directory sync service. Also note the sync service account name, we will need that later.
Event Viewer
The event viewer is always a good place to find the cause of a problem. It will often contain a better description of the errors and the possible cause. For the AD Sync errors, we will need to look at events from the Directory Synchronization source in the Application logs.
In this example, we will probably find a couple of event IDs that are all related to each other. The event ID 906 and event 904 for example. If you read the details from event ID 904, then you can see that the access is blocked by a Conditional Access policy.
It doesn’t tell us which constitutional access policy is the cause. But we can find that information in the conditional access Sign-In logs.
Conditional Access Sign-in logs
So we now know that the AD Sync services haven’t been running for a couple of days and that the cause is a conditional access policy. If you have recently changed a single policy, then that will probably be the cause. But we can also find the exact policy in the Sign-in logs.
- Open the Microsoft Entra Admin Center
- Expand Protection and open Conditional Access
- Open the Sign-In Logs
- Click on one of the events from the On-Premises Directory Synchronization Services Account
In the Basic info tab, you will see the Failure reason, which in this case tells us that the access has been blocked by Conditional Access policies. To view which policy is the cause, click on the Conditional Access tab.
In this example, two policies block access to Microsoft Entra for the service account. The first one is that we require MFA for all the users and the second policy only allows service accounts to access Microsoft Entra from trusted IP Addresses.
To solve the error the first error, we will need to exclude the service account user from the policy. For this, we will need to know the user account name. We can look this up in the Microsoft 365 Admin Center as shown before. But we can also view the account name in the sign-in log.
If you open the Basic Info tab and scroll a bit down, you will see the Username that is used for the authentication. Copy the username, so we can exclude it from the policy.
Solving the AD Sync Error
Now we know which conditional access policy is the cause of the problem, we can create an exclusion for the AD Sync user account so that MFA isn’t required anymore for this user.
- Open the Conditional Access policy that blocked the AD Sync user
- Click on Users
- Open the Exlude tab
- Add the username from the AD Sync account (search on Sync)
- Click on Save when done.
The AD Sync client will try to connect every 2 minutes, so you don’t have to restart the sync services. But if you don’t or can’t wait, then restart the Microsoft Azure AD Sync service on the domain controller.
Check the Conditional Access Sign-in Logs and Event Viewer to verify the conditional access error is resolved.
Wrapping Up
Conditional access policies are great, but when configured incorrectly, they can cause quite some issues. Therefore it’s important that you always test your policies in Report-Only mode before you activate them.
When it comes to solving errors, always take your time to read through the log files. They often contain the exact cause of the error. The event viewer is always great place to start.
Hope this article helped you solving the error, if you have any questions, just drop a comment below.
