Active Directory Application Password check-in not resetting password - only the old or original password works

Only the original password works when using Active Directory Application Password CheckIn CheckOut
User check-in is not resetting the ldap account's password (credentials not being updated)
User is able to login with privileged credential by using the old or original password.
The password displayed to the user in MyAccess during password checkout is invalid and does not work.
The basic example ldap perl check-in script was used as the password reset script.

The following in logs when attempting to login as user:
Info, LDAP mapping found for Administrator
Warning, LDAP bind failed, error 49 (Invalid credentials)
Info, LDAP authentication failed, using local authentication
Debug, Authentication status 401
Warning, User authentication failed for

The following is displayed in the unifid.log indicating a successful check-in:
Info, START PASSWD RESET
Debug, Input LDAP parameters : host - <ldapServerAddress> :: port - 389 :: secure - 0 :: adminDN - CN=Administrator,CN=Users... :: userDN - CN=Administrator2,CN=Users...
Info, Resetting the password of the LDAP user CN=Administrator2,CN=Users...
Debug, Authenticating to the LDAP server...
Debug, LDAP authentication to ldap://<ldapServerAddress>:389 as CN=Administrator,CN=Users... successful.
Debug, Modifying the password of the user CN=Administrator2,CN=Users...
Debug, LDAP modify successful in resetting the password of the user CN=Administrator2,CN=Users...
Debug, Logging out CN=Administrator,CN=Users... from ldap://<ldapServerAddress>:389
Info, END PASSWD RESET
Note: Administrator is the reconcile account doing the check-in, while Administrator2 is the credential being checked-in.

Active Directory Password Check-in / reset is done differently than the standard ldap check-in process and requires a unique password reset script. Please refer to Active Directory, Adding a Policy Template to import an example configuration with the correct password reset script.

This behavior can occur when the incorrect password reset script has been configured in the Vault Resource or Application Account Domain.