## TL;DR
The AD agent is a bridge between on-prem AD and Okta, and it goes Not running when its Windows service dies, when the network path to Okta breaks, or when its service-account credentials expire. Check the service on the host server first, read the agent logs for the actual error, verify outbound HTTPS to your Okta tenant, and confirm the service account can still log on. The console flips back to Running within minutes once the underlying cause is fixed.

## What you see
```text
Status: Not running
```

## Steps
1. On the server hosting the agent, open Services and find the Okta AD Agent service. Expected: it is running. If it is stopped, start it and watch whether it stays up.
2. If the service stops again immediately, read the agent logs on the server for the error. Expected: a concrete error such as bad credentials, no network route, or a blocked port, rather than a silent crash.
3. Verify the server can reach Okta: test outbound HTTPS to your Okta tenant from that box. Expected: the tenant URL loads. Proxy or firewall changes are the usual silent killer.
4. Check the service-account credentials the agent uses to bind to AD: expired passwords break the agent. Expected: the account can still log on and is not locked or expired.
5. In the Okta admin console, confirm the agent status flips to Running within a few minutes. Expected: green status, and the next scheduled import or delegated authentication succeeds.

## Use this when
- The Okta admin console shows the AD agent as Not running
- Delegated authentication against AD suddenly fails for everyone
- AD user imports stop arriving in Okta

## Not for this skill when
- The agent shows Running but imports show zero changes (check OU scoping in the agent config)
- The problem is a single user's authentication (account-level issue, not the agent)
- You are setting up a brand-new agent (follow the install guide, not this fix)

## Compatibility
- Okta AD Agent on Windows Server, Okta Identity Engine
- Delegated authentication and AD-sourced provisioning

## Variants
### The agent runs but imports show zero changes
Different problem: check the OU scoping in the agent configuration. It may be pointed at an empty or wrong OU.
### The service will not stay started
Look for a crash loop in the logs after a server patch. A reinstall of the agent over the top usually clears corrupted state.

## Why it happens
The agent needs three things to stay alive: a running Windows service, working credentials for its AD bind, and an open HTTPS path to Okta. Server reboots without auto-start, password expirations, and firewall or proxy changes each take out one leg.

## Edge cases
- Multiple agents for failover: if one is down the other should cover. Check both statuses, not just one.
- TLS inspection on the corporate proxy can break the agent's HTTPS to Okta. Allowlist the tenant.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_G8UlA5PRggiPs37CP1VZYg