Revision #13

You are currently reviewing an older revision of this page.
Go to current version

We've been getting lots of great questions about the Password Sync feature that we released earlier this month.
We wanted to take this chance to start a Frequency Asked Questions wiki to track some of the common questions and hopefully get you closer to getting up and running!

Please use the Azure Active Directory Forum as much as possible when you do have questions - we're working with our team to translate discussions there into additions here.

Good luck and have fun!

Windows Azure Active Directory Sync team


note Note
To provide feedback about this article, create a post on the Windows Azure AD TechNet Forum.



Good starter resources

To start, here are a couple resources that may help you understand and deploy Password Sync:

  1. How do I set up DirSync?
  3. How do I set up DirSync?
  5. How to switch from Single Sign-On to Password Sync

↑ Back to top


Does this feature work for both Office 365 and Windows Azure Active Directory?

Yes. This feature works for both Office 365 and Windows Azure Active Directory.

I'll also answer a slightly different question as well:

What are the differences/similarities between Office 365 and Azure AD? Do I need to set up DirSync and Password Sync for both?

This is a great question.  We sometimes refer to Office 365, and other times refer to Windows Azure Active Directory (or just Azure AD).  So what's the difference?

Windows Azure Active Directory (Azure AD) is the directory behind Office 365.  Just like your on-premises Active Directory stores the information for Exchange, SharePoint, Lync and your custom LOB Apps, Azure AD stores the information for Exchange Online, SharePoint Online, Lync Online and any custom applications you build in our cloud!

So when you set up DirSync for your Office 365 tenant, you've actually set up DirSync with your Azure AD tenant. And because Office 365 is built on Azure AD, Office 365 (and all our other Online Services such as InTune, CRM Online, etc.) benefit from this setup. The same holds true for Password Sync and ADFS.

↑ Back to top


Is this feature just PCNS integrated into DirSync?

No. This new Password Sync feature is not based on PCNS. PCNS relies on the deployment of Password Filters on all of your Domain Controllers to intercept password change events.  This new Password Sync feature integrates directly with Active Directory and retrieves updated passwords in the form of a password hash.  This password hash is subsequently re-hashed before we sync it to Windows Azure Active Directory.

↑ Back to top


Are my user passwords safe?  How secure is this new Password Sync? 

Yes. The information we retrieve from Active Directory aren't your users actual plaintext passwords - they're hashes of those passwords.  Hashes are mathematical functions that are nearly impossible to crack.  The hashes that we retrieve from AD cannot be used to gain access to any of your on-premises resources (Active Directory won't accept the password hash as a means to log a user in).

Here are some additional details to help you feel comfortable with the security of Password Sync:

  • we never see your plaintext password.  Ever.  We only retrieve the hash of the user password from Active Directory. 
  • we re-hash the hash of the user password using a SHA256 algorithm before transport to Azure Active Directory Authentication Service
  • transport of the digest (re-hash of the AD password hash) is done over an encrypted SSL session
  • we store the digest in our system

↑ Back to top

Can I control which passwords synchronize to the cloud?

There are two parts to the answer:

  1. We only synchronize passwords for those user objects that are DirSync'ing.
    See Configure filtering for directory synchronization for more information on how you can configure filtering for DirSync.
  2. You cannot specify additional filters to (1) above to control which users have their passwords synchronized to the cloud.

↑ Back to top



How can I trigger a full password sync?

A full Password Sync, and a full Directory Sync are two distinct activities.  A full password sync will synchronize password hashes for all DirSync'ing users.  A full Directory Sync will does not trigger a full password sync.  By default, the only activity that will trigger a full password sync is completing the Windows Azure Active Directory Sync tool Configuration Wizard.

Perform the following to trigger a full password sync

NOTE: you must have Directory Sync tool version 6438.0003 or greater installed in order to perform the process below.

  1. On your DirSync machine, run the following .psc1: C:\Program Files\Windows Azure Active Directory Sync\DirSyncConfigShell.psc1
  2. In the Powershell console that loads, run the Set-FullPasswordSync cmdlet
  3. Load Services.msc
  4. Restart the Forefront Identity Manager Synchronization Service Service.

Once this is complete, you should see a series of EventId=656 (Password Sync Requests) and EventId=657 (Password Sync Results) indicating that your full password sync has kicked off.

↑ Back to top

Can I use Password Sync and Single Sign-On at the same time?

This depends on what you mean by "at the same time".
A specific user cannot be password sync'ing AND configured for Single Sign-On at the same time.

However, a tenant may have some set of namespaces / domains configured for Single Sign-On and also have enabled the Password Sync feature of DirSync.
In this case, what we'll do is synchronize passwords for all those users that are not configured for Single Sign-On (i.e. users in Managed Namespaces) and we will skip synchronization of passwords for users that are configured for Single Sign-On / Federated Authentication.

↑ Back to top


Can I switch from using Single Sign-On/Federated Authentication to use Password Sync?

Yes. You can switch either individual users or else entire namespaces from Federated Authentication to Password Sync.
Please see this wiki post for information on how this can be done: How To Switch From Single Sign-On To Password Sync.

↑ Back to top


See Also

↑ Back to top


Revert to this revision