Share via

Cloud Identity Overview - Part 3 (Synchronisation)

  • Article

Part 3 - Synchronisation

As you will have read I have mentioned the reliance on an appliance named "AADConnect" for synchronisation of users, groups and contacts to Azure AD. So what is this synchronisation and why do we need it?. In a nutshell synchronisation is required for the following reasons.

  1. Provide on-premises integration - enables Azure AD to reflect what is in your on-premises Active Directory to provide a consistent user logon experience, provide the same experience in cloud versions of on-premises systems and secure cloud resources using the same security model you have defined within Active Directory.
  2. Provisioning lifecycle - automates the moves\adds\changes that all customers have within their directory systems to Azure AD.
  3. Authentication Support - as mentioned above "AADConnect" also provides authentication support by either synchronising a "hash of a hash of a password" to support Password Hash Synchronisation or deploying the Pass Through Authentication connector . In addition it also supports the Federated Logon scenario and can automate the AD FS configuration.

 

 

You may beware that "AADConnect" is the latest name for this technology but previously has been named "AADSync" and "Dirsync". The idea behind AADConnect is to have a simple "click next, next, next" appliance (installed on a single server) that sets up synchronisation to your requirements. There are lots of options you can set but I will cover common questions asked by customers.

  1. Can I synchronise Multiple AD Forests? - Yes you can. AAD Connect supports multiple forest topologies but there are design considerations that need to be made depending on your scenario (I will cover these in a later post)
  2. Can I decide what users, groups and contacts I synchronise to Azure AD? - Yes you can. You can filter objects from being synchronised to Azure AD by selecting an attribute, AD domain or Organisational Unit. The key thing you need to remember is that what is synchronised will form the Global Address List in Exchange Online, People Picker in SharePoint Online and generally used for all Microsoft Cloud services, so be very careful on what you filter as it may cause issues down the track. My opinion is to assume the default configuration and only filter if there is a clear security\policy reason to do so.
  3. Can I change the attributes within an object that are synchronised to Azure AD? - While technically possible it is definitely not recommended and can produce undesirable results. The different Microsoft cloud services have hard dependencies on certain attributes and also you want users that use the Cloud services to have the same experience as on-premises. Changing attribute flow can adversely affect this.
  4. What happens if the "AAD Connect" appliance is down? Is there a HA option? - So if the AADConnect appliance is down then the key thing that is affected is the provisioning lifecycle. i.e. users, groups, contact aren't having moves, adds, changes performed in Azure AD. Users can still continue to use the services with 2 exceptions. If you are using Password Hash Synchronisation passwords changed during this downtime may not be reflected in Azure AD, also if you are using Pass Through Authentication and you have not set up an additional connector then authentication may be down for those users. So question is then what are the HA options? Well "AAD Connect" has catered for this with what is known as "Staging Mode". This is another "AAD Connect" server that is a warm standby. It sits there "staging" all of the moves, adds, changing that are occurring and in the event of the hot "AAD Connect" server being down the warm standby is ready to resume operation by taking it out of "Staging Mode"

Well that's the end of the Cloud Identity Overview and I hope it was useful. I will be building on each section with extra content so stay tuned….

MD