I mentioned this issue in my recent post on using Azure AD terms of use, but it’s worth another post here to share some more details.
The issue is that the terms of use policy creates a conditional access rule in Azure AD that applies to all users. That includes the service account that is used by Azure AD Connect for directory synchronization. The service account can’t accept the terms of use, so it fails to authenticate. This breaks directory synchronization.
If you’re watching your directory sync health, or if you have processes that depend on frequent directory sync, you’ll notice the broken sync fairly quickly.
Otherwise, you should receive an email alert after 24 hours to notify you that synchronization is unhealthy.
One of the troubleshooting steps I used was to run Get-ADSyncScheduler in PowerShell on the AAD Connect server itself. In the days leading up to this problem I had opened the AAD Connect configuration to check some things. This pauses the sync schedule, so my thinking was that the schedule had not been re-enabled for some reason. But instead of seeing the expected output, the following error occurred.
1 2 3 4 | PS C:\> Get–ADSyncScheduler Get–ADSyncScheduler : System.InvalidOperationException: Showing a modal dialog box or form when the application is not running in UserInteractive mode is not a valid operation. Specify the ServiceNotification or DefaultDesktopOnly style to display a notification from a service application. |
It was the part of the error message that says “Showing a modal dialog box or form…” that turned my thoughts towards other recent changes in the environment, namely the configuration of Azure AD terms of use. The conditional access policy that was created for my Azure AD terms of use applies to all users in the organization by default, with no exceptions. So the Azure AD Connect service account is unable to login, because it can’t view and accept the terms of use.
Adding the sync account as an exception to the conditional access policy in Azure AD immediately solved the problem.
The Get-AdSyncScheduler cmdlet now returns the expected results, and the next sync run was successful as well.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 | PS C:\> Get–ADSyncScheduler AllowedSyncCycleInterval : 00:30:00 CurrentlyEffectiveSyncCycleInterval : 00:30:00 CustomizedSyncCycleInterval : NextSyncCyclePolicyType : Delta NextSyncCycleStartTimeInUTC : 5/21/2018 4:46:16 AM PurgeRunHistoryInterval : 7.00:00:00 SyncCycleEnabled : True MaintenanceEnabled : True StagingModeEnabled : False SchedulerSuspended : False SyncCycleInProgress : True |
