Azure AD Connect (now Microsoft Entra Connect) – your questions answered

Where should you install Azure AD Connect (Microsoft Entra Connect)?

It does not have to be on a primary DC, or any DC – it merely has to be able to get to a DC, and out to Azure AD (Microsoft Entra ID), of course. In my demo, I only have one DC, and that is where I put AAD Connect.

Some of those attending the webinar spotted that I did nothing to ensure uniqueness of account names. And that’s OK for a demo where we don’t want to go into confusing detail. The issue of uniqueness is present in any identity management system, and by that I mean that somewhere, either manually or programmatically, at least one real world unique attribute will be required. I stress real world because just about every system will have a GUID or reference number of some kind – but we need to generate user-friendly email addresses, account names, logons and so on. It would be impossible to cover all the approaches to this problem here so here are two tips:

  1. Always solve the problem at the source if you can. For example, if you enter users in an HR system first, and this is the authority on which provisioning decision are based, then this is a great place to establish one unique attribute (an “alias”) that can be used to generate all your email addresses, account names and logons. The alternative is a lot of work repeated as you try to solve the problem in each system.
  2. Ask yourself how you do it now, or perhaps how you would like it to be done. Are you prepared to use an impersonal employee ID (easy, but ugly)? Can it be automated – in other words, is it acceptable to have an algorithm that would produce something like “JaneDoe, JaneWDoe, JaneHDoe, JaneDoe1, JaneWDoe1, JaneDoe2 and so on (fairly easy, but still a bit ugly)? Does it really require human intervention (check a default for uniqueness, then if necessary ask the operator to make a decision (harder but prettier)? Are you prepared to involve the user – “Well, John, I am sorry to say that JohnSmith has gone, but you can have JohnASmith, JSmith, JohnSm or JoSmit” (more effort, but makes happy users).

So when you know the answers to these, you can come up with a technical solution (or we can help you do so!)

What about Azure AD Connect MIM sync?

Let’s be quite clear that these are not connected. You can have MIM sync doing all your on-premises stuff, and it can be extended to connect to cloud services, including Azure AD. However, many organizations with MIM will still have AAD Connect doing the AD to AAD sync, this is the architecture that Microsoft supports, and that we recommend. Of course, you can install AAD Connect with MIM nowhere in sight; and there are a few use cases where AAD Connect presents an alternative to MIM.

What about controlling sync activity?

AAD Connect run profiles are like MIM ones, and you configure them in the same way, but the combined runs have now gone (enforcing what has been the correct practice in MIM for some time). You should name them simply as “Delta Import”, “Export” etc. if the scheduler is to pick up the right ones. You can run profiles manually (having disabled the AAD Connect scheduler), and you can write PowerShell to call the scheduler with your own custom schedule. The scheduler normally does a delta sync every 30 minutes (you can make that interval longer if you like) and that means a delta import on all connectors, and delta sync on all connectors and an export on all connectors – but when I say “all connectors”, that is not true today but will be so in the next release. For more information see this article by Andreas Kjellman.

What about licensing?

No licensing is needed to install AAD Connect and get all your AD users and groups syncing with AAD. If you include other connectors there is still no licensing required. But if you want to write anything back to AD from Azure AD that requires AAD Premium licensing.

What about password sync?

AAD Connect will write AD passwords to AAD. If you already use MIM for example to do self-service password reset (SSPR), those changes can be sync’d to AAD. If, on the other hand, you want to set passwords in AAD, perhaps using the SSPR that comes with AADP, passwords can be written back to AD if you have AADP (but note this article about ensuring that this is done securely). No other password sync is currently supported (emphasis on currently – things are moving fast!) You CAN set initial passwords on provisioning, but this will usually mean writing your own connector (or Management Agent).