This article addresses the issue where an Okta user's password fails to sync to Active Directory (AD) through Application Sync Password despite the feature being enabled. The problem is reported when a user or admin perform a password reset in Okta, but the corresponding password for the user's AD object does not update.

Steps to reproduce the issue:

1. Enable Sync Password for the Active Directory application.
2. Perform a password reset for a user in Okta.
3. Check the user's password in Active Directory. It remains unchanged.
4. In the Okta System Log, the following entry is observed, indicating a successful transfer of the password to the Okta AD AppUser profile: 

   Push user's Okta password to application SUCCESS

5. Following the success entry, the log shows a failure when Okta attempts to write the password to the AD object: 

   Perform directory invoke command by AD agent FAILURE

NOTE: To investigate the full transaction, perform the following system log query: 

eventType eq "system.agent.ad.invoke_dir" or eventType eq "application.provision.user.push_okta_password"

If the "Push user's Okta password to application and Perform directory invoke command by AD agent" log entries appear with the same timestamp (or within a few seconds), the most likely root cause is insufficient AD Agent Service account permissions.

• Active Directory (AD) Integration
• Application Sync Password feature
• AD Agent Service Account Permissions
• User Provisioning

The root cause of the password sync failure can be insufficient Active Directory permissions assigned to the AD Agent Service Account.

The AD Agent successfully receives the new Okta password (Push user's Okta password to application SUCCESS), but the Service Account lacks the necessary permissions to execute the directory operation and write the new password to the target user object in Active Directory (Perform directory invoke command by AD agent FAILURE).

The resolution involves confirming the root cause is permissions related and then granting the AD Agent Service Account the necessary permissions to update user passwords.

1. Confirming the Permissions Issue (Temporary Fix)

To confirm the issue is permissions-related, perform the following temporary steps:

1. 1. Temporarily grant Domain Admin privileges to the AD Agent Service Account by placing the account in the built-in Domain Admins Active Directory group.
   2. Restart the AD Agent service on the server where it is installed. This must be performed on all AD Agent servers.
   3. Perform another password reset for a user in Okta and verify one of the following:
      • The "Perform directory invoke command by AD agent" log entry is now successful.
      • The user can successfully authenticate to the domain with the new password.

If the password sync succeeds, the root cause is confirmed to be permissions. Proceed to a permanent solution.

2. Implementing a Permanent Solution (this step is not needed if the Service Account can remain in the Domain Admins group)

The following steps detail how to assign granular permissions required for password updates.

1. 1. Remove the service account from the Domain Admins group immediately after confirming the issue.
   2. Grant the service account the necessary granular permissions on the Active Directory domain or the specific Organizational Units (OUs) that contain the synchronized users. The Okta service account permissions describes all permissions needed to perform Okta AD Agent actions.
   3. After the permissions have been properly updated in Active Directory, restart the AD Agent service. The agent will now use the granular, restricted permissions.
   4. Perform a final password reset for a user in Okta to verify that the password successfully syncs to Active Directory.