Okta Active Directory (AD) Agent versions 3.18.0 and above require precise time synchronization with a Network Time Protocol (NTP) server to maintain OAuth 2.0 authentication. Syncing the member server to a standard NTP server resolves connection disruptions caused by clock skew.
The AD Agent may appear as disrupted after an auto-update to version 3.18.0.
Observable symptoms include the following error messages in the Okta System Log or Agent logs:
invalid_dpop_proof_jwt_issued_in_future
invalid_dpop_proof_jwt_too_old
{"error":"invalid_dpop_proof","error_description":"The DPoP proof JWT is issued in the future."}
- Okta Classic Engine
- Okta Identity Engine (OIE)
- AD Agent versions 3.18.0 and above
- Directories
Starting with version 3.18.0, the Okta AD Agent uses OAuth 2.0 (OAuth 2.0) authentication to verify the connection to the Okta org. This method replaces the legacy method using a persistent API token. OAuth 2.0 requires the agent server clock to be synchronized with the Okta server time within 30 seconds. If the clock skew exceeds this limit, the system rejects the client token as invalid.
This issue can be confirmed in the Okta System Log using the search string:
actor.id eq "urn:okta:agents:ad-agent" and (outcome.reason eq "token_timestamp_invalid" or outcome.reason eq "invalid_dpop_proof_jwt_issued_in_future" or outcome.reason eq "invalid_dpop_proof_jwt_too_old")
The system log shows OIDC token request FAILURE: invalid_dpop_proof_jwt_issued_in_future or FAILURE: invalid_dpop_proof_jwt_too_old, depending on the direction of time skew.
These errors will also appear in the Okta AD Agent logs:
"Unexpected response status (400 BadRequest) for request URI
Response from server: {“error”:“invalid_dpop_proof”,“error_description”:“The DPoP proof JWT is issued in the future.“}
Could not fetch a new access token"
To determine the clock skew, compare the local server time to the Official U.S. Time.
NOTE: The maximum allowable clock skew for successful OAuth token requests is currently 30 seconds. This value is subject to change.
How is the Okta AD Agent clock skew resolved?
To resolve this issue, sync the agent server to any standard NTP server and restart the agent service.
The commands below may be useful in troubleshooting and resolution:
Use this command to check the current time status:
w32tm /query /status
Use the following command in an elevated command prompt to force a synchronization with the configured NTP source:
w32tm /resync
If the time remains out of sync, the commands below can be run in an elevated command prompt to manually configure the NTP peer list:
net stop w32time
w32tm /config /syncfromflags:manual /manualpeerlist:"0.it.pool.ntp.org 1.it.pool.ntp.org 2.it.pool.ntp.org 3.it.pool.ntp.org"
net start w32time
w32tm /config /update
w32tm /resync /rediscover
NOTE: The AD Agent must be restarted after running the time synchronization commands to enable a successful sync with Okta.
