Posts tagged “Azure 2-way directory sync

Setting up Azure AD Connect, 2-way directory synchronization, password write-back, online-password reset

For this demo, I will create a new Azure Active Directory (AAD) called Vertitech3AAD and a new on-premise Active Directory called Vertitech3OP.local (NetBIOS name Vertitech3OP) in a new 2012 R2 AD forest.

Create a new Azure Active Directory:

As of 24 February 2016, creating a directory is available only in the classic portal ( If you try to do it in the new portal (


You’ll simply be redirected to the classic portal:

I created Vertitech3AAD Azure Active directory in Azure, and created an on-premise AD domain called Vertitech3OP.local in new 2012 R2 forest:


I can see the new AAD (Azure Active Directory) domain:


Create new AAD Global Admin user:

We create a new AAD user for AD Connect because we need a Global Admin that has rights to a single AAD. In the new AAD I create a new user with Global Admin permissions:


The new AAD user is created:


Change the temporary user password:

Next, I must change the new user password. I browse to, log off and login again using the new user credentials and temp password:


I’m then prompted to change my password:


Download and install AD Connect on an on-premise machine:

AD Connect can be downloaded from the Azure AD page or this link.


Install AD Connect



Using Express Settings:


Enter the AAD Global Admin user name and password:


And local (on-premise) AD credentials – this account needs to be member of the Enterprise Admins group:


The message/recommendation about custom domain verification can be safely ignored.


AD Connect uses SQL Express – but can be configured to use other on-premise full deployment of SQL:


And we’re all done:


I recorded the machine services in an XML file before installing AD Connect using the Powershell command:

Get-Service | Export-Clixml .\Services1.xml

After installing AD Connect, I ran this small script to identify new services added:

$Services1 = Import-Clixml .\Services1.xml
$NewServices = @()
(Import-Clixml .\Services2.xml) | % {
     if ($_.Name -notin $Services1.Name) {
         $NewServices += $_
$NewServices | sort name | select name, displayname,status | FT -a

We can see 5 new services. Some are running under LocalSystem.


In Computer Management under Local Users and Groups, we can see a number of new local groups that have been created during AD Connect installation:


Only ADSyncAdmins local group has users. It has the local user account (service account for ADSync service) and the domain account that the AD Connect installation ran under,

And in Azure we can see a new Synchronization service account:


Also, note that Directory integration is now Activated:


To view synchronization activity, run Synchronization Service Manager (c:\program files\Microsoft Azure AD Sync\UIShell\miisclient.exe)


User objects in the on-premise AD need to have inheritance enabled for AD Connect to work and synchronize these objects to Azure AD.

Enable Password Write-back:

We can also see Azure AD Connect icon on the desktop (shortcut to “C:\Program Files\Microsoft Azure Active Directory Connect\AzureADConnect.exe”)


Which shows the following options:


First option is to View Current Configuration:


Note the default settings above. To change synchronization settings, click Customize Synchronization Options:


Next we enter our Azure AD Global Admin user credentials:


And our local (on-premise) AD admin credentials:


We can select to synchronize all domains and OUs or specific domains and OUs:


As well as optional features:


I check the box to enable Password Write-back, and click Install to reconfigure the synchronization process:



To test synchronization, I create a local AD user:


By default AD Connect synchronizes every 30 minutes. To force a manual synchronization I use this Powershell cmdlet on the AD Connect machine:

Start-ADSyncSyncCycle -PolicyType Delta

Now I can see the user in Azure:


Configure Password Reset Policy:

In the Azure classic portal at, browse to your directory/configure page:


Click the Yes button for ‘Users Enabled for Password Reset’.

Don’t forget to click the Save icon on the bottom center to save and apply your new settings.

Accept the remaining default settings or customize them as needed under the ‘user password reset policy’ section.

I changed the default setting ‘Require Users to Register When Signing in’ from Yes to No. This feature will require users to enter Mobile Phone OR Alternate Email Address as configured in this section. You may want to warn users before hand to expect that requirement, or/and tackle any internal organization/privacy issues related to users’ alternate emails and mobile phone numbers.

One last note here; Password Reset Policy is a directory-wide setting. It will apply to all users. As of 7 March 2016, it cannot be configured to apply to a certain user/group/OU.

Finally, users can change their passwords online using the standard Azure password reset pages/links such as


which can be reached from the settings/password link under for example: