Syncing password from AD without delegated authentication
We currently have delegated authentication enabled with our AD such that everyone who signs in to Okta would on-the-fly authenticate against AD via AD agent, so we can ensure password update and user activation/deactivation status are always in-sync with AD. However, the drawback of this approach is that we actually need to set up multiple AD agents ourselves in order to achieve HA and this is what we want to avoid. My understanding is that an alternative is to disable delegated authentication but then only rely on scheduled import from AD at a frequent basis (e.g. hourly) to synchronise password and user activation status from AD to Okta - this way even though our AD agent is down, user can still sign in to Okta. My question is, under such setup do we need to enable the "Sync password" option in order to make sure to get the latest password from AD into Okta during scheduled import? I read the description and am not sure whether this option is for synchronising user password from AD into Okta, or the other way round.
I guess to full answer the question I would need to understand the real concern you have here about placing a few light weight Okta agents amongst your domain controllers. We have many customers with 30+ domains that have trust relationships between them sharing a number of active/active Okta agents, and as it only takes 10-15 mins to install an Okta agent on a member server this is seen as less troublesome than providing HA for you internal domain controllers.
To mitigate problems of your directory connecting to Okta, we internally persist your directory authenticated (DelAuth) session. This helps in many scenarios - when all DCs go down (that might happen), when all Okta AD agents go down, or when internet connectivity drops altogether.
To ensure system availability and customer access to apps, we store a one-way irreversible hash (SHA-256) of user ID, username, and password from prior DelAuth requests. This is not the hash stored by AD. It's a separate hash that's calculated by and only used within Okta. The hashed session data is cached in our database for 10 days and is valid for authentication for 5 days.
The next time the user logs in, Okta checks the connection to AD. If available, Okta delegates authentication to the directory. If successful, we update the cached session data and the time stamp. DelAuth requests proceed as normal.
If the connection is NOT available, Okta authenticates to the cached session for the remaining time of the 5 day period. This is something that you might not have been aware of, so thought I'd share this first before digging in to your specific question.
Yes, in your use of switching off delegated authentication you would need to sync the user's AD password with Okta to perform th authentication directly with the Okta directory.
Almost all customers tend to prefer the delegated authentication and make use of the knewledge that if the connection to the domain controllers is lost, Okta can still perform an authentication against the Okta cache.
Thanks for the detailed reply. To make it clear, my concern about enabling delegated authentication is only that I prefer not to rely on the high availability of the Okta agents which are installed in our own facilities. I didn't know about the Okta cache which you mentioned.
To ensure I understand it, did you mean that when Okta lose connection to all agents, user should still be able to login to Okta as long as he/she has logged in once in the past 5 days, while at the same time those users who didn't log in within past 5 days will not be able to log in until connection with at least one Okta agent is resumed?
Hi Vincent, yes your summary is correct. If users have been stored in the cache they can still authenticate to Okta with no available Okta agent communications. Once one or more agent(s) come back up, then the delegated authentication will become available again.