we have an on premises Active Directory. The environment got hacked and domain controllers were restored to a backup that is clean according to forensic people.
For better explanation, let's assume the hack occurred on October 1st and the backup it got restored to was from September 1st.
All local accounts that were created and synchronized before September 1st are fine. All local accounts that were created and synchronized between September 1st and October 1st are lost on premises. A new AADC instance has been installed, configured and is synchronizing happily. For some reason, the accounts created after September 1st and before October 1st were not deleted in the cloud when AADC started synchronizing again. We do not know why. They do not exist on premises any more though. These local accounts are supposed to be created again, so they can access on premises resources. I looked at Microsoft documentation about soft/hard matching in AADC: Azure AD Connect: When you already have Azure AD | Microsoft Docs
It states that object newly imported to AADC will be hard matched or soft matched if possible and afterwards, AAD will mark them as " Directory synced". It also states: The match is only evaluated for new objects coming from Connect. If you change an existing object so it is matching any of these attributes, then you see an error instead. My question is: If we have those accounts in the cloud that are marked as "Directory synced" and create them on premises, will this be considered as a "new object" by AADC and hard matched or soft matched? Or will this cause duplicate accounts in the cloud or the error mentioned above? If we stop the AADC sync service locally, create the accounts on premises and assign those newly created on premises accounts the same "sourceAnchor/immutableID" value as the cloud object and restart synchronization, will this work or will it cause an error?
Thanks!!!
• First, reverse synchronization, i.e., synchronization of user identities from Azure AD to on premises AD is not possible as of today even using Azure AD Connect. There are only few attributes that can be written back, and that's mostly for hybrid configurations, and passwords if you have the corresponding feature (and licenses) enabled. So, in your case, if you have enabled ‘password writeback’ and ‘password hash synchronization’ in Azure AD Connect, then only you can edit these properties of the users in on premises through Azure AD. Also, if that’s what you want, you can simply export the list of users via PowerShell (Get-MsolUser/Get-AzureADUser) or the Graph API, along with any relevant attributes, then use the exported data to recreate them in AD (again, PowerShell helps). You cannot export passwords. Once the export/import is done, you can "match" the on-premises users with the cloud ones and give them the SSO experience. The process is known as soft match. The other type of syncing between both the environments is called hard match. You can find more details in the link below: -
• But there is a way you can try as given in the links below by creating those users who were created during that month whose backup isn’t available and ensuring their domain suffix and email as well as alias attributes are identical to those as synced in Azure AD during that month. Thus, when you create users identical, primary SMTP, email, alias, and domain suffix, you may be able to sync these users’ identity once again to the same identities synced(created) in Azure AD earlier. Please refer the links below for detailed steps to follow: -