This release has been a capability which has generated a lot of interest with my customers going with Office 365 Education. I have put together a quick FAQ to help with this.
What is Azure Active Directory Dirsync with Password Sync?
Formerly known as Dirsync, this tool has been updated to allow for the synchronization of local Active Directory passwords to Azure Active Directory. in addition to the syncing of users, groups and contacts. This new feature will allow for Same Sign In with Microsoft cloud services such as Office 365 Education powered by Azure Active Directory since the username and the password from local AD will by synced up to Azure AD. See here on TechNet for more details.
Where can I get the new Dirsync with Password sync bits?
You can grab the latest version of Dirsync here or it is available in the Office 365 portal under ‘users' and then Dirsync.
What version of Dirsync has Dirsync with Password sync?
Dirsync with password sync is available in versions 1.0.6385.12 or newer version.
How can I quickly tell if I have the right version downloaded?
The first way you can tell is by size. The file size is about 183+MB vs. the older version is 99MB. The other way you can tell is by the icon. The application icon should be our new Windows logo with the four blue squares. The final way to confirm this is by hovering over the dirsync download and check the version the version with Dirsync with password sync or later is:
note: I renamed the default ‘dirsync’ filename since I already had the older dirsync in the same directory.
What do I need to do to replace my older dirsync?
You do have to remove the existing installation of Dirsync prior to installing the new version with password sync.
You don’t need to remove other components such as SIA or SQL express. I left everything else in place. Here is the setup I did on an existing Dirsync Server:
1) Important: If using ADFS with federated ID, you must first convert your domain namespace to managed ID PRIOR to installing and running Dirsync with password sync. See steps below under “What if I am federated…”
2) Remove existing Dirsync application from control panel.
3) I took screenshots of the rest:
What if I am federated and using ADFS and want to switch to Dirsync with Password Sync?
You will need to convert your domain from federated to managed. Using the
convert-msoldomaintostandard –domainname foo.edu –skipuserconversion $false –passwordfile c:\password.txt
Azure AD cmdlet. See here on TechNet for more details. Note: the password file is for dumping all users temporary passwords into.
How can I tell if it is configured correctly for Dirsync with Password Sync?
You should see event ID 656 and 657 in your application event log to show that it is syncing the password hash to the cloud.
What are the advantages of Dirsync with Password Sync vs. ADFS?
There are a couple of advantages of using Dirsync with Password Sync over using ADFS 2.1 with Dirsync:
1) A single server is needed vs. redundant and scaled out ADFS servers.
2) No dependency with on prem hardware/data center – if Dirsync with Password Sync server dies – just replace it. There is no impact accessing cloud services with an onprem outage because the identity is a managed identity in Azure AD vs. a federated identity using ADFS 2.1.
3) No complex ADFS architectures – No ADFS Proxies, load balancers, certificate management are required. It keeps the deployment less complex with fewer moving parts.
What are the disadvantages of Dirsync with Password Sync vs. ADFS?
ADFS 2.1 with federated login provides true Single Sign On (SSO) with Office 365 where as Dirsync with Password Sync allows for Same Sign On which implies users will be prompted for credentials when accessing Office 365 even in domain joined scenarios. ADFS 2.1 also allows for better access control based on IPs, etc.
Where can I find more information on troubleshooting Dirsync with Password Sync?
There is an excellent KB article here to help you.
Note: for those running DirSync in a Server Core OSE, the uninstall string for the previous version is "%ProgramFiles%\Microsoft Online Directory Sync\UnInstallDirectorySync.exe"
Does Dirsync with Password Sync responsible for outlook connectivity in office 365 Co-existence with Exchange 2010 Onpremise instead of ADFS Proxy server or only it will do password synchronization from AD Onprem to AD online and do we need to deploy ADFS and ADFS Proxy servers in existed office 365 hybrid/Co-existence with Exchange 2010 Onpremise ?
Exchange Hybrid does not require ADFS and it can run with Dirsync with Password sync only.
After using PCNS for live@EDU this is very welcome, I found a great article on forcing a complete resync for all passwords but would like more information on retries (how many and what interval between?)
So for example - A new account appears in the AD, password sync tries to sync the password to 365 but dirsync has not yet provisioned the account into 365 - when and for how long does it retry - it at least 3 hours in line with DirSync default provisioning schedule?
Then who take cares of SSO ? can you please get me any document
The object will be synced to Azure AD outside of when the user is enabled in Office 365. There is no dependency on Office 365 enablement to sync the password to Azure AD.
ADFS enables true Single Sign On however in the case of Outlook the users experience will be the same. Outlook users will be prompted for credentials the first time whether using ADFS or Dirsync with Password Sync. The user can check 'remember password' to avoid prompting thereafter.
ADFS will allow for promptless sign on with Lync, OWA, SharePoint, and Office Subscription when in a domain joined local intranet scenario where as Dirsync will Password Sync will still prompt for credentials if 'remember password' is not enabled.
Thank you for the clarification ,
Can we upgrade to Dirsync with Password Sync from old version of dirsync server which has already existed in Office 365 hybrid and Rich Co-existence with Exchange 2010 Onpremise, if yes can you please attach related document on how to upgrade and what are difference between Microsoft Online Active Directory Synchronization tool and Dirsync with Password Sync .
does anyone know the client behavior for services like Outlook/Lync/IE with the new DirSync? Like will users have to auth for each app? and will the sign-on assistant help with that experience?
The behavior with Dirsync with Password Sync is SAME Sign On not Single Sign On (ADFS) which implies prompting for every new session. For Outlook, the behavior is the same as Single Sign On (prompt the first time it is opened) but you can cache the creds. Same with IMAP and ActiveSync devices.
For passive clients like OWA and SharePoint, it will be prompted the first time and maintain the session for 8 to 24 hours. Lync will be prompted the first time and it also can 'remember password' option with the SIA client.
This is a most welcome update, after my upgrade to 365 from Live@edu the clock is counting down 30 days on my current FIM\PCNS setup, the setup guide for ADFS made me cry, this looks a lot easier and has more features than my previous setup so getting it up and running on my test site now :)
I just deployed the new tool. on my event log I get EVENT ID 656 & 657 which shows there is a form of password sync, but I also get the below EVENT too:
EVNET ID 652
Failed credential provisioning batch. Error: Microsoft.Online.Coexistence.ProvisionRetryException: An error occurred. Error Code: 81. Error Description: Windows Azure Active Directory is currently busy. This operation will be retried automatically. If this issue persists for more than 24 hours, contact Technical Support. Tracking ID: 5de5fc64-cc95-4f57-955d-7f4549b3c9e0 Server Name: . at Microsoft.Online.Coexistence.ProvisionHelper.AdminWebServiceFaultHandler(FaultException`1 adminwebFault) at Microsoft.Online.Coexistence.ProvisionHelper.InvokeAwsAPI[T](Func`1 awsOperation, String opsLabel) at Microsoft.Azure.ActiveDirectory.Connector.PasswordChangeNotificationExtension.SetPasswords(IList`1 passwords)
EVENT ID 6900
An error occurred. Error Code: 81. Error Description: Windows Azure Active Directory is currently busy. This operation will be retried automatically. If this issue persists for more than 24 hours, contact Technical Support. Tracking ID: 5de5fc64-cc95-4f57-955d-7f4549b3c9e0 Server Name: . at Microsoft.Online.Coexistence.ProvisionHelper.AdminWebServiceFaultHandler(FaultException`1 adminwebFault) at Microsoft.Online.Coexistence.ProvisionHelper.InvokeAwsAPI[T](Func`1 awsOperation, String opsLabel) at Microsoft.Azure.ActiveDirectory.Connector.PasswordChangeNotificationExtension.SetPasswords(IList`1 passwords) at PasswordHashSynchronization.TargetExtensionManager.ExportPasswords(TargetExtensionManager* , ECMAInformation* ecmaInformation, DynamicArray<PasswordHashSynchronization::TargetSynchronizationRecord \*>* targetPasswordChanges) InnerException=> none
EVENT ID 6329
BAIL: MMS(2792): d:\bt\5417\private\source\miis\passwordhashsynchronization\passwordhashconnectormanager\synchronizationenginemanagedhandle.cpp(101): 0x80004005 (Unspecified error) BAIL: MMS(2792): d:\bt\5417\private\source\miis\server\server\server.cpp(10478): 0x80004005 (Unspecified error) BAIL: MMS(2792): d:\bt\5417\private\source\miis\server\server\server.cpp(10548): 0x80004005 (Unspecified error) Forefront Identity Manager 4.1.3451.0
Any idea on what is going on please?
I used this with an existing 365 tenant to allow Password Sync. I also use Lync online but since the first DirSync all users have disappeared from the Lync Online Control Panel. All users still have a Lync license installed. Has anybody else seen this?
i would like to disable ADFS and use only DirSync with PW Sync. After disabling ADFS (Convert-MsolDomainToStandard –DomainName domain.com) the office 365 login page still redirect to our adfs server. How can i disable this??
Run get-msoldomain to make sure it actually converted it to managed. It sounds like it did not since you are still getting ADFS urls.
im little bit confused: Is this right (social.technet.microsoft.com/.../17857.aad-sync-how-to-switch-from-single-sign-on-to-password-sync.aspx):
Following this approach will change the namespace of the migrated user’s UserPrincipalName (the domain following the ‘@’ sign).
This will potentially impact your users’ login experience.
Be sure to notify your users that their login name has changed.
Does this mean that we have to use new userprincipalnames like firstname.lastname@example.org --> email@example.com ???