Making it simple to connect Windows Server AD to Windows Azure AD with password hash sync

Making it simple to connect Windows Server AD to Windows Azure AD with password hash sync

  • Comments 20
  • Likes

Howdy folks,

Over the past 12 months of live usage with Office 365 and our Windows Azure Active Directory (AD) developer preview, one of the top requests we've received from customers and partners is for a simpler way to connect their on-premise Windows Server Active Directory with Windows Azure Active Directory.

Many companies would like to have their employees use the same username and password on premise as in the cloud. But up until now, doing this seamlessly with Windows Azure AD has required deploying and running a set of ADFS servers on-premise or using a 3rd party solution.

I'm happy to let you know that as of last Friday (5/31) we've made it dead simple to connect AD to Azure AD, enabling users to log into Office 365, Windows Azure and any other cloud app integrated with Windows Azure AD using their on-premise username and password.  We've done this by updating Windows Azure Active Directory Sync Agent (a.k.a. DirSync) adding the ability to sync hashes of users' on-premise AD passwords into Windows Azure AD. 

This new password sync capability has many advantages over existing 3rd party solutions that synchronize your on-premises passwords to Azure AD/Office 365:

  • We don't sync plaintext passwords - The solution syncs hashes of hashes of your user's passwords greatly reducing the risk of a password leaking.
  • You don't need to install any new software on your Domain Controllers OR reboot your DCs.
  • Users don't need to change their password in order for their password to initially sync to Azure AD.

This new password sync is another feature of DirSync.  If you are already running DirSync, you'll need to download and install the new DirSync build.  When you set up DirSync, enabling password sync is simple as checking the "Enable Password Sync" checkbox in the DirSync Configuration Wizard.  No additional hardware, no additional installation steps:


Even simpler with improved updating:

We've also updated DirSync so that you'll no longer have to uninstall and reinstall to get the newest features.  In the future, you'll only need to download the latest version of DirSync and run it on your existing deployment to upgrade to the latest and greatest configuration! 


So, when should you use Password Sync? 


This is a great question. Windows Server ADFS still offers benefits to customers that Password Sync doesn’t.  You need to analyze your business requirements and determine which solution (Password Sync or ADFS) fits your organizations need best. 

Password Sync offers customers what we call "Same Sign-On", which is not the same as "Single Sign-On" that ADFS offers.  With Password Sync, users that have their passwords sync'd to AAD and will be able to use the same username and password to log into their Azure AD services as well as their on-premises resources.  But they will be prompted to sign in to their cloud resources, even if they are already logged in to your corporate network. With ADFS, users get true single sign-on where they are not prompted to enter their credentials if they have are already logged into their Windows PC's.

Additionally ADFS supports

  • Support for custom 2 factor authentication mechanisms deployed on-premises
  • The Ability to make policy based access control decisions

So there are definitely some compelling reasons to use Windows Server ADFS. 

However based on what we've heard from partners and customers, there is s strong need for the simpler/light weight password sync model. We're excited to be able to deliver this capability and are looking forward to hearing about your experiences with it!

For more detailed information about our new password hash sync feature as well as deployment guidance, please refer to our TechNet documentation here:


Best Regards,

Alex Simons (twitter: @Alex_A_Simons)

Director of Program Management

Active Directory

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment
  • Hi Alex,

    Our understanding (Microsoft told us) is that using ADFS, we required "Windows Server User CALs" for each user that authenticates via ADFS (as it is a Windows Server component).

    Do you know if this works around this licensing requirement, as the user is authenticating directly with Office 365 / Windows Azure AD?



  • Hi James,

    I will need to do some research on this and get back to you.


  • Is the DirSync tool a one-way push from the on-premises AD DS (authoritative) to AD DS in the cloud, or is it a two-way sync so that the user could change their password at O365 and it would sync down to the on-premises AD DS?  

  • Hi Kent,

    It's a one way sync. Users that have Password Sync enabled are required to change their passwords on premises in an AD connected machine.



  • A follow up question to the Paul. Is it possible to enable password sync only for specific users/OU's and leave the remainder of the users not synchronizing their password through the new DirSync tool, or is it all or nothing?

  • Jim

    You cannot define users who's passwords are synced to cloud. But you can define which users are synced to cloud.

  • @James:  

    Getting back to you.  For a user to have their password stored in AD so we can sync it and to be able to change/update the password, they need to have an WS Cal.  Password sync relies on these, so yes, you would still need the WS Cal for this.



  • Can this be installed on a DC?  Based on the statements above it says no need for additional software or hardware.  If that is true then DirSync can install on a domain controller as most of my customers only have one Server which is also their DC.



  • Hi Alex, if I filter for only certain OUs when using DirSync, do I need to check the "Enable this partition as a password synchronization source"?

    Not that is overly matters as I implemented ADFS but curious for other deployments I may do.


  • Hi Alex, what user in local AD should I use for Identity Integration Server wizard/configurator?