Users for a tenant with an on-prem Active Directory integration with Okta report they are unable to log in. Reviewing the Okta logs around the time the logins were denied, you observe the following was logged:
Event: Authenticate user with AD agent
Reason: Delegated authentication request was not processed. No agents are connected to Okta.
Result: FAILURE
Cause
This message indicates that Okta is unable to communicate with any AD Agents.
Resolution
Work through the following steps in order to identify and resolve the connectivity issue.
Verify the AD agent status
In the Okta Admin Console, navigate to Directory > Directory Integrations.
Select your Active Directory instance and click the Agents tab.
Confirm that at least one AD agent is listed as Active. An agent must have a stable connection to Okta servers and a valid configuration to be considered operational.
Confirm the agent is running version 3.18 or later. Okta no longer accepts telemetry from legacy versions of the agents. You can use the Okta API to check the version of agents on a per-tenant basis.
Check AD Agent service on the host server
Log in to the server where the Okta AD Agent is installed.
Open the Services management console.
Locate the Okta AD Agent service and confirm its status is Running.
If the service is stopped, attempt to start it. If it fails to start, review the agent logs located at
C:\Program Files (x86)\Okta\Okta AD Agent\logsfor error messages. An error indicating that the service could not start may suggest a corrupted or encrypted configuration file. In this case, we recommend reinstalling the agent.
Review agent logs for errors
Access the agent logs at
C:\Program Files (x86)\Okta\Okta AD Agent\logs.Look for entries indicating issues, such as:
Response from server: 401 UNAUTHORIZEDResponse from server: 403 FORBIDDENinvalid_dpop_proof_jwt_issued_in_futureinvalid_dpop_proof_jwt_too_old
Errors and resolutions:
A
401 UNAUTHORIZEDresponse may indicate that the Okta Super Administrator account used to install the AD Agent has been deactivated.A
403 FORBIDDENresponse may indicate that the account has lost its Super Administrator privileges.An
invalid_dpop_proof_jwt_issued_in_futureorinvalid_dpop_proof_jwt_too_olderror may indicate a clock skew issue specific to AD Agent version 3.18.0 and above — see Connection issues for Okta AD Agent versions 3.18.0 and above for resolution steps.
Confirm Okta Administrator account status
Confirm that the Okta Super Administrator account associated with the AD Agent is active and retains the necessary privileges.
If the account has been deactivated or its privileges altered, reactivate it and restore the Super Administrator role.
If reactivating the account is not possible, consider reinstalling the AD Agent using an active Okta Super Administrator account to generate a new API token.
Enable verbose logging for detailed diagnostics
Navigate to the AD Agent installation directory, typically
C:\Program Files (x86)\Okta\Okta AD Agent.Open the
OktaAgentService.exe.configfile with a text editor.Locate the line and change it to
<add key="VerboseLogging" value="True" />.Save the changes and restart the AD Agent service.
Verbose logging will provide more detailed information in the logs, aiding in troubleshooting. Remember to disable verbose logging after resolving the issue to prevent excessive log generation.
Check network connectivity
Confirm that the server hosting the AD Agent can reach Okta's servers over the network.
Verify that there are no firewall rules or network policies blocking outbound connections from the AD Agent to Okta.