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.
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 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.
To trigger a full password sync, perform the following steps:
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". You can synchronize passwords for a user that is currently federated.
However, their login will still happen against your on-premises STS (ADFS or 3rd party STS).
If your on-premises STS becomes unavailable, you may temporarily switch to enable your users to sign-in with sync'd passwords.
The process for accomplishing this can be found in
You may have some set of namespaces / domains configured for Single Sign-On and also have enabled the Password Sync feature of DirSync.
Yes. You can switch either individual users or else entire namespaces from Federated Authentication to Password Sync.
You can also temporarily switch from SSO to use synchronized passwords if your on-premises STS becomes unavailable.
This allows you to resolve the issue then switch back to Federated logins.
Please see this wiki post for information on how this can be done:
How To Switch From Single Sign-On To Password Sync.
If Password Sync is enabled, you can watch it work by monitoring activity
Additionally, there is a script available
here, which definitively states whether or not the feature is enabled.
We have just uninstalled and re-installed the new version of DirSync (10 Jun 2014) and the DirSyncConfigShell.psc1 is missing.
As a workaround, goto C:\Program Files\Windows Azure Active Directory Sync\DirSync and run Import-Modules.ps1
You will have to sort out the PS Execution Policy and run the PowerShell window in Administration Mode.
Once this is done you will have access to the Set-FullPasswordSync
There is no need for a workaround.
Just use Import-Module DirSync
What method/cmdlet/webService is used to send that hash to Azure AD?
Most examples for setting up on premise AD synchronization to Azure AD/Office 365 imply having your local domain set up first and then syncing them. What about having Office 365 up before having you on premise domain ready? I am faced with this now. Our users have Office 365, but we do not have a local domain.