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
To start, here are a couple resources that may help you understand and deploy Password Sync:
↑ Back to top
Yes. This feature works for both Office 365 and Windows Azure Active Directory.
I'll also answer a slightly different question as well:
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.
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.
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:
There are two parts to the answer:
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.
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.
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.
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.
Maheshkumar S Tiwari edited Revision 18. Comment: Added tags
Peter Geelen - MSFT edited Revision 4. Comment: fixed toc and cleaned HTML
Jono Luk (MSFT) edited Revision 2. Comment: rolling back formatting.
Jono Luk (MSFT) edited Revision 1. Comment: rolling back formatting.