I had to test a few scenario's as I was taking over a project centred around Office 365, the only twist was that user accounts had been provisioned in Office 365 before the production Active Directory was in place (and AD Connect).
I had to test what would happen when the following
- User A existed in Office 365 but was then created in AD (with the same email address) and synced.
The outcome of this test is that User A is still retained in Office 365 with all the existing permissions and testing however their original Office 365 password is overwritten with the new password which is set on their user account in Active Directory. In short the on premise Active Directory becomes the point of authority for passwords which in turn overwrite any existing passwords in Office 365.
The next part I had to test was Azure AD Password Write back, this feature is useful for me on this project as users who were already using Office 365 would have to be provisioned with AD accounts. The plan was to create new user accounts (matches Office 365 email) for everyone with a generic password, when AD Connect was in place, they would then be asked to login to Office 365 using their new generic password. When they had authenticated to Office 365 they would be instructed to reset the generic password to be their own password. After the new password was accepted by Azure AD, it would in turn then we written back to AD, thus becoming the primary and only password for AD and Azure AD.
It should be noted that Azure AD Premium is need to support Azure AD Password Write back.
If you are doing this for the first time it's not obvious that you have to change the Default Domain Policy on the Active Directory to set the Minimum Password Age to 0, or you will get the following error.
The Default Domain Policy usually holds the global account policies for the Active Directory.
You must enable Self Service Password Reset from the Azure AD portal.
You must also ensure password write-back is enabled from the same portal.
The workflow for when users login after write-back has been enabled.
a.) User is issued new password (for Active Directory)
b.) Administrator forces AD Connect do a sync to Azure AD
c.) User is asked to login to Office 365
d.) User is asked to register self-service password reset questions
e.) User is logged in with Active Directory password
f.) User attempt's to reset Active Directory password from Office 365 portal
g.) Office 365 accepts the users new password and writes it back to Active Directory
h.) This password becomes the only password for Active Directory and Azure AD
i.) Event 31007 is logged in the Azure AD Connect server to confirm the write back operation.
In this example my domain was running on Windows Server 2008 R2, no permission changes had to be made to get password write-back working. I did however do exactly the same thing on a production environment all running Windows Server 2016 Domain Controllers, and it never worked, you can find the solution here.