Troubleshoot password synchronization

Use the information provided here to help resolve password synchronization issues.

Here are some suggestions for resolving password synchronization issues:

The Okta Password Sync agent is installed on all domain controllers, user's AD password has changed, but user is not able to log in to apps via desktop SSO

The problem may be that the Okta username format for your orgThe Okta container that represents a real-world organization. is not set to User Principal Name (UPN) or sAMAccountName. In most cases, the Okta username format must be set to User Principal Name (UPN) or sAMAccountName in order for the AD Password Sync Agent to work. To check the Okta username format setting:

  1. On the Okta AdminAn abbreviation of administrator. This is the individual(s) who have access to the Okta Administrator Dashboard. They control the provisioning and deprovisioning of end users, the assigning of apps, the resetting of passwords, and the overall end user experience. Only administrators have the Administration button on the upper right side of the My Applications page. Console, click Directory > Directory Integrations.
  2. Click Active Directory and then the ProvisioningProvisioning is the enterprise-wide configuration, deployment, and management of multiple types of IT system resources. Specifically, provisioning provides users access to equipment, software, or services. This involves creating, maintaining and deactivating required business process automation objects and attributes in systems, directories, and applications. tab.
  3. In the SETTINGS list, click To Okta.
  4. In the General area, make sure that User Principal Name (UPN) or sAMAccountName is selected for Okta username format.

Filter was loaded successfully, but is not enabled

If you launch the AD Password Sync agent and a message displays stating that the agent is not enabled, you must enter your Okta URL (for example, and click Verify URL.

Note: You must use the https:// prefix in your entry.

Could not establish trust relationship

If you launch the AD Password Sync agent and the message displays The underlying connection was closed. Could not establish trust relationship for the SSL/TLS secure channel, then you installed AD Password Sync agent version 1.3.0 or later and your environment is one in which the agent's support for SSL certificate pinning prevents communication with the Okta server. This is most likely to occur in environments that rely on SSL proxies. To allow installation to complete in this case, Okta recommends that you bypass SSL proxy processing by adding the domainA domain is an attribute of an Okta organization. Okta uses a fully-qualified domain name, meaning it always includes the top-level domain (.com, .eu, etc.), but does not include the protocol (https). to a whitelist.

Alternatively, you can choose to disable SSL certificate pinning as described below, but be aware that doing so disables a security enhancement provided by the agent.

To disable support for SSL pinning, edit the Windows registry as follows:

  1. Click Search, enter regedit in the search box, and press Enter.
  2. If a message displays Do you want to allow this appAn abbreviation of application. Essentially, it is a web-based site used to perform any number of specific tasks, and requires authentication from end users by signing in. to make changes your device?, click Yes.
  3. In the Registry Editor, navigate to HKEY_LOCAL_MACHINE > SOFTWARE > Okta > AD Password Sync.
  4. Double-click the setting Enable certificate pinning and change the value to 0.
  5. Click OK to save your change.

For more information about SSL certificate pinning, see Open Web Application Security Project.