A few weeks ago, Microsoft announced a great new Conditional Access feature called Terms of Use. This allows organizations, on access for users accessing content/services integrated with Azure AD, to surface a disclaimer for legal or compliance requirements. Event cooler, it works in tandem with things such as Azure AD Domain Join scenarios and event B2B users for access to Yammer (and other B2B use cases)!

As this was announced, I decided to deploy this in our lab environment. It was pretty straight forward. I logged into the portal, found Terms of Use and created myself a new policy. When you check the box for Create a policy, it simply creates a new Conditional Access policy linked to this that’s targeted at all apps and all users.

Pretty straight forward right?

Well all was fine, and the policy was enforced (pretty cool by the way) when I logged on to the Azure portal. In fact, I LOST access to the Azure portal until I logged back in again to accept the TOU.

Everything was going along swimmingly, until I noticed a day or two later that my Azure AD Connect instance stopped synchronizing. Well I did a bunch of troubleshooting, and really couldn’t easily find a root cause.

I saw that the export to AAD stopped working

I checked my sync account creds, made sure it was active and the password was set to never expire

So finally after a few hours of troubleshooting, I figured I’ll just go ahead and re-install AD Connect, just because.

Well in doing so, it kept on failing and for the life of me I couldn’t figure out why, especially since the wizard seemed to take everything without complaining. But I kept on getting to the following at the very end:

An error occurred executing Configure AAD Sync task: Showing a modal dialog box or form when the application is not running in UserInteractive mode is not a valid operation. Specify the SerivceNotification or DefaultDesktopOnly style to display a notification from a service application.

I couldn’t for the life of me figure out what was going on. So I started digging into things, and finally decided to look at what Conditional Access policies were applied to this user.

I thought about recent changes I made, and decided that removing the TOU policy I had deployed days prior, would be the best step.

Low and behold, the sync then finished the next time I ran it!

For some reason, it was not surfacing the TOU policy for my Global Admin account that was entered into the wizard when it redirected to the Azure portal to enter my credentials.

Easy enough fix, as I just disabled the TOU policy temporarily for that Global Admin account and re-enabled it after, since it just needs the creds one time to create the sync account.

Great, I’m out of the clear! Well not yet….2 hours later….

I went to go look at things, and noticed the sync wasn’t working now

So again, I thought, could this be the same thing? Again I disabled the TOU policy, and syncing immediately started working again

As I can’t logon to Azure AD with those credentials directly (easily) because they are generated by the service, I’m kind of in a bind for how to use TOU globally, but not break AD Connect.

So I went ahead and setup a user exclusion for the sync account explicitly, and all seems to be operating healthy now!

Word of warning for ALL folks testing TOU policies, it WILL break AD Connect synchronization if you leave the default settings (not excluding the AD Connect sync account) when you create the TOU policy, as I’m sure many have done.

I have raised this as an issue to the Conditional Access & AD Connect Product Groups and they are investigating the issue to reproduce and ensure proper communications/solution is addressed.

Hopefully this saves some folks time and trouble!

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes:

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>