When resetting the password of an Active Directory (AD) user who uses Delegated Authentication, the Okta AD Agent sends the password reset attempt to the AD Domain Controller (DC) for processing. The process times out, and Okta will report an error if the agent does not respond within 30 seconds, even if the password update eventually succeeds in the directory. This behavior can occur when environmental latency or network configuration delays communication between the Okta AD Agent and the DC.
Okta System Log may report:
FAILURE: Communication error occurred, please try again
In some cases, the end user receives an error on the password change screen. When trying to change it again, the error says the old password is incorrect, confirming that AD successfully changed the password.
- Okta Classic Engine
- Okta Identity Engine (OIE)
- Active Directory
- Delegated Authentication
- Self-service Password Reset
- Admin-initiated Password Reset
Communication between Okta and the AD Agent will time out if the overall password change attempt exceeds 30 seconds. While the Okta System Log reports a failure, the password often updates in AD because the DC eventually processes the request after the Okta connection closes.
A common cause for delays exceeding 60 seconds is a blocked kpasswd port (464) on the member server. AD first attempts to reset the password via Kerberos on port 464, retrying after 30 and 60 seconds before falling back to the less secure NETBIOS protocol. This delay leads to an Okta timeout. This issue can be verified using a Wireshark packet capture from the agent server.
DC load, security software, and network configuration may also cause the password change request to time out.
How is a timeout in Okta during AD password reset resolved?
The following steps help identify the source of the delay and apply the necessary configuration changes.
- Review the AD Agent logs to determine the
executionTimefor the affectedrequestId. Use the How to Retrieve Okta Logs for Troubleshooting guide to locate these files. - Search the logs for the
DIRECTORY_INVOKEaction and identify theexecutionTime. If the time exceeds 60 seconds, ensure the network configuration allows traffic on port 464 between the agent server and the DCs.
Example:
2024/11/08 09:33:38.740-05:00 Info -- <SERVER>(<THREAD>) -- Processing DIRECTORY_INVOKE action (id=rpc::app.active_directory.agent.reply.<OKTA CELL>.internal//<COUNTER>//<REQUEST ID>:<RESPONSE ID>:) finished, (executionTime=00:01:03.4990394)
Located below the DIRECTORY_INVOKE action, the "POSTing ActionResult" entry shows when the Okta AD Agent received the request from Okta, when it forwarded the request to the DC, when the DC responded, and when the agent responded to Okta, which may help identify where the delay is occurring.
Example:
2024/11/08 09:33:38.830-05:00 Info -- <SERVER>(<THREAD>) -- POSTing ActionResult to Okta. actionReceivedFromOkta: 11/8/2024 9:32:34 AM, actionSentToLdapServer: 11/8/2024 9:32:34 AM, responseReceivedFrom LdapServer: 11/8/2024 9:33:35 AM, responseSentToOkta: 11/8/2024 9:33:35 AM
- To test the DC performance directly, execute the following PowerShell command on a DC to measure the local password reset duration. Replace
<upn>with the Universal Principal Name (UPN) of the account being reset and<password>with a test password.
$stopwatch = [system.diagnostics.stopwatch]::StartNew()
Set-ADAccountPassword -Identity <upn> -Reset -NewPassword (ConvertTo-SecureString -AsPlainText "<password>" -Force)
$stopwatch.stop()
$stopwatch- If the local DC reset takes more than 2 seconds, contact the internal Windows infrastructure team or Microsoft Support to investigate environmental latency.
- If the DC processes the change in under 2 seconds but the total transaction still exceeds 30 seconds, increase the Polling Threads for the AD Agents. Refer to the Okta Active Directory agent variable definitions for instructions.
