This page is the starting point for troubleshooting Password Synchronization Issues and Contains answers for many common questions.
The first place to begin troubleshooting password synchronization issues is on the Domain Controller(s) the Password Sync Client is installed on. If you change a password on that domain controller and nothing is written to the Password Client log file then:
1. Make sure the Password Client Service is running. It is listed in services.msc as Kaseya Password Client Service.
2. Make sure the domain controller was rebooted after installing the Password Client. This is a requirement for the Password Client as the DLL used to capture the Password can only be loaded at system startup.
One of the most frequent problems is the Office 365 PowerShell Module is not installed, or it cannot connect to Office 365 on the server that is running the Password Server Service.
You can download the module here:
To test that the module is installed, open a PowerShell window on the Password Server and run:
If you don’t get an error, then it’s installed properly. Next run:
Type in your credentials when prompted. If you get connected, you could run the following command to ensure that you are connected properly:
get-msoluser -MaxResults 10
If you are unable to get connected, then it’s typically a problem with a firewall/proxy.
If you get an authentication error, one thing to try is uninstalling and reinstalling the Sign in Assistant, as we have seen that clear up authentication issues with the module.
If you are receiving errors about the user not being found in Office 365, ensure the matching attribute in Active Directory matches the Identity in Office 365. When configuring the Password Client on the Domain controllers, in the LDAP Server area you can specify the matching attribute as either the mail or userprincipalname. Which ever value is chosen should be populated in the local Active Directory and match the identity in Office 365.
Yes. The only requirement is the Server Service requires a Windows 2008 R2 or Windows 2012 server. So if you have a domain controller running Windows 2008 R2 or Windows 2012, both components could be installed.
No, the Passwords are only synchronized when they are changed. During a migration, you could force the users to change their password at next login in the Active Directory, which would then sync to Office 365. They would then sign into Office 365 using their new password.
Yes. When a user changes their password, that change could hit any DC in the domain so the client must be installed on all. The exceptions would be Read Only DCs and domains which don’t have any users, such as an empty forest root domain.
On the password client, you have the option of selecting the Matching Attribute. It can either be the mail attribute or the UPN value. If you open the Password Client Admin application on the DC and go to the Config tab, you’ll see an option which allows you to select the attribute. If you make the change, just save the config, stop and start the service.
No. We match the AD accounts to the Office 365 User based on the matching attribute configured on the Password Client Admin.
Kaseya Password Sync does not enforce password complexity. It simply takes the password and passes it to Office 365. Office 365 then verifies the complexity.
No, Active Directory does not support filtering based on OU. An alternative is to create a group and which contains members of the OU and uses the memberof attribute in Active Directory.
If you are having problems with the Password Server Admin which are not addressed in the documentation or support pages, it may be necessary to enable Debug Logging on the Password Server Service. Follow the steps below to enable Debug Logging.
Save the Config, Stop the Service, and Start Service.
The log file should look like this.
Please provide this log file to MessageOps Support.