Hi Clay,

I believe you'll want to log into the server that you installed the AD Agent on, do a Windows Run command with WindowsKey+R. Type services.msc. When the window pops up, look for Okta AD Agent, right click Properties, go to the "Log On" tab.

The interesting thing for us is the account we used for the AD Agent install (in the Logon tab) isn't a user inside Okta, or at least we don't import it in, so I'm not so sure there's a connection.

I remember seeing similar issue in the past, where we had to add "Authenticated Users" to the Users group on the machine where AD agent was installed. And that did worked. Not sure if you would would like to try that.

Regards,

Jatin

The only time the actual credentials (username/password) were used was during the AD agent installation. When you entered those credentials, Okta used them to create an API token, and that's what the agent uses to make that persistent connection back to Okta. An API token inherits the role/rights of the account used to create it, so when you removed the super admin role from the Okta account, the API token also lost that role.

If you wish to replace the account that the AD agent uses to connect to your Okta org, my recommendation would be to uninstall and reinstall the agent, specifying the new service account next time around. I did this a few years ago when I realized that, during our initial implementation, I had used my own super admin account during the agent install, and so the system logs show all this activity for my account for every import and authentication event, for all users. It's also important to use an account that is not tied to an actual user, because if that user leaves the organization and his/her account gets deleted, the associated API key will stop working, permanently.