ADConnect Sync with MFA

[RonB]

When MFA is implemented for all users and admins, is the automatically created sync account for ADConnect going to be denied access to sync AD to Office 365?  Do those accounts need to be excluded?  How?

[VNJoe]

I'd like to comment that if you were running ADConnect and no longer are, you won't be able to log in if you enable MFA.  It is very important to mention that once MFA is enabled/enforced, you are forced to change your password immediately, and IF ADConnect disallows password changes, you're in trouble.

It'd been nice to hear that all passwords have to change when you enable MFA, huh?

[JanoschUlmer]

@VNJoe :When you enable MFA, you are not enforced to change passwords immediately just because of MFA.

If you enable the end user protection baseline policy you might be asked to change your password when leaked credentials are detected (and then, it is imo a good thing to be informed your credentials have leaked).

That you might be asked to change passwords is already documented in the guidance: https://docs.microsoft.com/en-us/partner-center/partner-security-requirements#enforcing-mfa-for-all-users 

If you use synced accounts with AAD Connect, self service password reset for those accounts will onyl work with AAD Premium licenses (Password writeback is required) - otherwise you need to reset onpremises. 

It is best practice to have at least one (admin) account created in the cloud so that any sync issues or issues with synced account will not lock you out.

[VNJoe]

This is a fantastic response, and the correct one, so thank you.  The problem is I didn't encounter any of these items or issues until after MFA was enabled.  The compromised users thing is still in Preview/Beta and I wasn't even aware of it, but I can't touch or change it without a premium AD license.  So while there's a simple sentence in that article about Compromised users at the tail-end, it does not take into consideration things like users who run MS software on phones or tablets and have a VPN, for example, so that the software that constantly logs in to Microsoft logs different IPs and automatically throws the user in a compromised user bucket without notifying anyone.  I'm the tenant admin and had no idea 'Risky Users' even existed, so I'd like to know that I've got users in that bucket.

As I said, the answer is exactly as you've described, but it required me to get baseline removed from my user account so I could get in then disable baseline for everyone.  But it took 10 hours and my company was out of business for a day, with all users being considered Risky Users and my DC unavailable for password changes.

Issues resolved, but the problem is there, and they shouldn't be basing our partnership agreements on Preview/Beta software.

[FikoIO]

We are facing the same problem.

[Scott-NetRes]

Apologies if this has been answered elsewhere; I'm playing catch up and I'm still reviewing the MS-published docs as well as the community; but so far I've only seen a slight reference to this, which in itself is concerning.

So on to the question - will AADC continue to function once the baseline policies are enabled? We long established internal policies that all our staff use MFA on our tenant, but obviosly don't have it switched on for the O365 account that gets created by AADC to handle sync, that is: 'On-Premises Directory Synchronization Service Account'.

So, does AADC just break when we enable the baseline policies? Or has a technical solution already been developed? I can see one post where a partner mentions this was asked during an 'Office Hours' presentation, but didn't receive an concrete answer.

[JanoschUlmer]

Azthe Azure AD Connector account does not have a directory role that is affected by the MFA for admin baseline policy, but it might be affected at a later point by the end user protection policy. 

We are aware of this topic & potential issues and currently discussing solutions internally - will update you as soon as I know more.

For the meantime, if you experience issues with AzureAD connect after enabling , please do not hesitate to raise a support ticket, this helps tracking this problem internally.

[cyberb00f]

Hi,

So, if I enable MFA for the On-Premises Directory Synchronization Service Accounts via the AAD Security console, will it break anything?

Thanks!!

[JanoschUlmer]

The on-premise service accounts accounts are usually not synced, even if they would it woud probably not break anything since they do not authenticate with AzureAD. However, The AzureAD Connector account is in AzureAD: https://docs.microsoft.com/en-us/azure/active-directory/hybrid/reference-connect-accounts-permissions#azure-ad-connector-account 

If you use AzureAD Security Defaults and when you did not customize this account, but used the defaults, it will not break. If something breaks, contact support.

[JonW]

---

@JanoschUlmer wrote:

Azthe Azure AD Connector account does not have a directory role that is affected by the MFA for admin baseline policy, but it might be affected at a later point by the end user protection policy. 

We are aware of this topic & potential issues and currently discussing solutions internally - will update you as soon as I know more.

For the meantime, if you experience issues with AzureAD connect after enabling , please do not hesitate to raise a support ticket, this helps tracking this problem internally.

---

Yikes, yep. This shouldn't affect customers who enable the end user protection baseline policy, as that policy doesn't enforce MFA. However, it would affect partners that use ADConnect -- if the techincal requirement is all accounts must have MFA enabled. However, not an issue if we are only disabling legacy authentication...

[JonW]

According to office hours session on 7/9 at 8pm EST, the adconnect account is special and should not be affected when enabling conditional access policies that require MFA. If you do have a problem, they suggest opening a support ticket to investigate as that should not be happening.

[idwilliams · Accepted solution]

I would like to confirm that you should not enforce MFA for the Azure AD Connect service account. Also, if you are using the baseline protection policies, then you do not need to worry. The implementation of those policies does not impact the Azure AD Connect service account. If you encounter any issue with synchronization after implementing the baseline policies please open a support ticket. That way our support organization can help investigate.

[JonW]

I have heard that if you use the default adconnect account mfa is not required.

However, if you use a different name, then it will not work.

So by special, are we saying that account gets an exception, but other accounts that are in a similar situation, just using a non-microsoft service are not permitted the same consideration?

[idwilliams]

When you use Azure AD Connect with a custom account, then there is a possibility you will encounter errors with the synchronization process. However, if you let the Azure AD Connect setup process create the account for you then you will not be impacted. There are improvements being made to this process to make it where the behavior is consistent in both scenarios mentioned. 

@JonW I would recommend that you reach out to your PDM to share this feedback. That way they can ensure it shared with the appropriate teams. 

[kmergur]

@idwilliams, don't you think that it would be nice if we knew the details of those baseline policies? What are the conditions, included/excluded items etc? Now, those baseline policies are blackboxes in the form of 'take it or not'. 😞

[JanoschUlmer]

@kmergur  : Good starting point is here: https://docs.microsoft.com/en-us/azure/active-directory/conditional-access/howto-baseline-protect-end-users

For the identity protection features that are included - the "sign-in risk" that is evaluated -  you can refer to this documentation: https://docs.microsoft.com/en-us/azure/active-directory/identity-protection/howto-sign-in-risk-policy(Note that with AAD Premium P2 you can not create your own risk policies and without AAD P1 you will not see any risk events in the reports - so with only the baseline policy you have no insight on why exactly a risk was determined).

What is not documented yet is a planned change on behavior when a user from a CSP tenant will authenticate, which will be considered a risky sign-in every time so MFA is always triggered. 

Beneath that, there are no other exclusions in the baseline policy (same for the MFA-for-Admins policy - this does not include the identity protection features though).

[VNJoe]

Again, great response, and I appreciate that, but you hit the nail on the head:

---

@JanoschUlmer wrote:

(Note that with AAD Premium P2 you can not create your own risk policies and without AAD P1 you will not see any risk events in the reports - so with only the baseline policy you have no insight on why exactly a risk was determined).

---

So without making an additional purchase, you succumb to the whim of Microsoft's designation of a Risky Sign-In, again, a "feature" I had no idea was being applied to me or my tenant.

I can't even use MPN Azure Credits to purchase Azure AD P1 or P2 (which would be my preferred method moving forward).

You've revealed the issue, though, very well, and again, I did uncover all of this myself, but only after locking out all my users who were all assessed Risky Sign-In designation with no notification on my end...

Thanks for your time and effort, @JanoschUlmer !

[JanoschUlmer]

Thanks for your feedback and I'm sorry to hear that enabling this policy resulted in a full day business outage. I have worked with a few Partners already enabling those, luckily none of them experienced this. Your comments are definitively a good read for all the other Partners in this community.

I agree that some of the caveats in those policies can be documented more clearly (and some of this was already improved in the last weeks). Still I wonder why usage of different source IPs would trigger a password reset - often-changing IPs should only trigger a forced MFA prompt, not a pw reset. Anyway, difficult to do a root cause analysis later and without logs of risk details...

Reg. internal use rights - as Partner you should have internal use licenses for EM+S E3, which includes AzureAD Premium P1 (And those keys/license packs can be enabled in any tenant - but each key only in one tenant).

I can understand that using preview features is not the preferred options for a business, yet it was decided this way to make a cost-free method to enable MFA for everybody available immediately, instead of waiting until GA to come with this option.

[VNJoe]

The root cause (I'll save you some time):

I do not seem to have EM+S E3 nor exactly know what those letters mean, but I don't have AD Premium.  However, I have Risky Users and Risky Log-Ins, but have no access to modify or remove those capabilities from my tenant.  Unbeknownst to me, those Risky Users were going to be forced to change their password upon enabling MFA (again, not even knowing that existed on my tenant).  However, we do (did) have ADConnect enabled with a DC that's in storage right now while we wait on new office construction to complete, and so no users were able to change their password in the cloud.  As a result, enabling MFA checked Risky Users and forced them into an infinite loop of forcing a password change that would never complete, meaning no users on the Risky Users list could log completely in to the portal.

So there's the root cause, FYI.  And I appreciate all your feedback on this issue.  I will investigate what EM+S E3 means now. Thanks!

[JanoschUlmer]

Thanks, I meant the root cause why a password reset was triggered, since enabling the end user baseline policy does normally not do this - only when the accounts are already compromised. Not important though, would just be nice too know.

Having a setup with a synced directory, and then not having the source AD available for a longer period of time is something I would avoid at all costs. As a best practice I would either evaluate to deploy a DC & AAD Connect in e.g. Azure for the meantime - or disable the synchronization for the tenant so users are managed in the cloud and password reset on the portal works.

EM+S E3 is something you'll see since 2016 in your Partner benefits - "Enterprise Mobility + Security" - it is a suite containing AzureAD premium, Intune, Azure Information Protection + other services. See also https://techcommunity.microsoft.com/t5/Enterprise-Mobility-Security/Introducing-Enterprise-Mobility-Security/ba-p/249870 

[VNJoe]

Correct, it normally doesn't, but if it thinks your user's login is compromised (which is pulling data from the RIsky Users module which I don't have access to configure), then it triggers the password change.  It's a compounded effect.  I had to acknowledge the RIsky Users objects and logs to disable forcing the password change (I haven't tested this yet but it seem's the workaround).

Just wanted you to understand it as you seem very helpful and knowledgeable and those are things to encourage!