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.