Use the information provided here to help resolve password synchronization issues.
Here are some suggestions for resolving password synchronization issues:
- Review the Okta System Log to determine if the password synchronization event resulted in a password synchronization attempt to push the password to applications or to Active Directory (AD).
- Sign on to password synchronization target application manually to determine which password is working.
- With Okta to AD synchronization issues, confirm that the Okta AD agent service account permissions are correct and there are no errors in the Agent.log file.
- Review the Okta AD agent and Password Sync Agent (PSA) logs for synchronization events.
- Failed password synchronization events appear in the task list on the Tasks page.
The Okta AD Password Sync Agent is installed on all domain controllers, user's AD password has changed, but user is not able to sign in to apps using desktop SSO
The problem may be that the Okta username format for your org is not set to User Principal Name (UPN) or sAMAccountName. 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:
- In the Admin Console, go to Directory > Directory Integrations.
- Click Active Directory and then the Provisioning tab.
- In the Settings list, click To Okta.
- 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, https://mycompany.okta.com) and click Verify URL. Use the https:// prefix in your entry.
If you launch the AD Password Sync agent and see the message 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 domain okta.com to an allowlist.
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:
- Click Search, enter regedit in the search box, and press Enter.
- If the message Do you want to allow this app to make changes your device? appears, click Yes.
- In the Registry Editor, navigate to HKEY_LOCAL_MACHINE > SOFTWARE > Okta > AD Password Sync.
- Double-click the setting Enable certificate pinning and change the value to 0.
- Click OK to save your change.
For more information about SSL certificate pinning, see Open Web Application Security Project.