Okta "Sync User in External Application" Failures Result in Disabled Active Directory Users During Provisioning
Last Updated:
Overview
During user provisioning from Okta to Active Directory (AD), a "Sync user in external application" failure event occurs, resulting in AD users being created in an inactive (disabled) state. This issue occurs because a blocked KPASSWD port (464) causes a job timeout while waiting for the directory invoke event. Resolve this issue by allowing incoming traffic to the domain controller on port 464.
In the Okta System Log, the "Sync user in external application" event logs as a failure during Okta user provisioning to AD without an error message.
Review the Okta System Log to identify the failure event during user provisioning.
This failure event occurs 30 seconds after a successful "Perform LDAP write by AD agent" event to create the AD user profile.
Review the Okta System Log to identify the successful LDAP write event that precedes the failure.
Following these events, a "Perform directory invoke command by AD agent" event appears as a success.
Review the Okta System Log to identify the successful directory invoke command event that follows the failure.
Applies To
- Okta Identity Engine (OIE)
- Okta Classic Engine
- Directories
- User Provisioning
- Networking
Cause
The failure occurs due to a job timeout while waiting for the directory invoke event to succeed. The user provisioning job requires the directory invoke event to complete within 30 seconds; otherwise, the job stops and remains incomplete. If the directory invoke command response arrives later than expected, the job fails, and the AD user remains disabled.
Using a trace tool like Wireshark reveals why the directory invoke event takes additional time. During a normal directory invoke action, Windows Server uses the KRB5 and KPASSWD protocols.
Review the Wireshark trace to observe a normal directory invoke action using the KRB5 and KPASSWD protocols.
When the port for KPASSWD (464) is blocked, Windows Server retries three times before reverting to the less secure SMB2 protocol. This retry process exceeds the 30-second limit.
Review the Wireshark trace to observe the blocked KPASSWD port retries.
Review the Wireshark trace to observe the fallback to the SMB2 protocol.
Solution
How is the directory invoke event timeout resolved?
Configure the network settings to prevent timeouts during the directory invoke event.
- Allow incoming traffic to the domain controller on port 464. This port is reserved for KPASSWD, which is a standard protocol used for setting passwords over a Kerberos-encrypted channel.
