VictorK.52186 (Customer) asked a question.
Current setup: hybrid on site AD with Microsoft 365. On site AD is the source of truth for authentication.
Issue: most users are hybrid home/office, some are remote, many forget to connect with VPN, their passwords expire, and they don't know it until Okta doesn't let them in. Many of them try the password reset option in the Okta splash page, which doesn't work. As simple as it is to connect the VPN and update the password, some still have issues.
Best solution: allow Okta to be the source of truth and write the password to AD?
So I'm confused about how to implement it. The article "Manage self-service password reset" (https://help.okta.com/en-us/content/topics/users-groups-profiles/usgp-manage-password-reset.htm) says "Delegated authentication...is recommended for Active Directory sourced users". But the article "Synchronize passwords from Okta to Active Directory" (https://help.okta.com/en-us/content/topics/directory/security_using_sync_password.htm) says "To allow Okta to synchronize with AD, the delegated authentication setting for the AD domain must be off". This has me confused.
Also, one thing that I was wondering about is this, which is also in the article mentioned above: "All password changes should be initiated in Okta and propagated to AD. Users should be prohibited from changing their passwords directly in AD." How does that work when users are on site? They can't change their passwords with Windows like we've been doing for millennia?
And lastly, in our AD / 365 hybrid setup, how does Entra ID play a part, if at all? Entra also has the capability of writing back passwords.
My head is about to explode. Any guidance will be greatly appreciated.
Hi @VictorK.52186 (Customer) , Thank you for reaching out to the Okta Community!
It all boils down to what your source of truth is.
You mentioned that your case AD is the source of truth, this means that you can disregard the "Synchronize passwords from Okta to Active Directory" feature. That is used when you do not use Delegated Authentication, and want to push the “Okta password” to downstream apps/AD.
While using Delegated Authentication, AD sourced users do not have an “Okta password” - authentication is deferred to AD via the Okta AD Agent connection. This is what will allow you to manage the password self-service functionality provided that you granted the proper permission to the service account used for the Agent setup.
See AD integration prerequisites here.
You will need to configure a password policy (or multiple depending on your needs) & rules to that allow self-service specifically for AD users. See documentation here and the screenshot below:
You will need to ensure that the policy (complexity, minimum age, etc) configured in Okta is the same as the password policies configured on the AD side, otherwise you run the risk of self-service attempts failing. For Example the Okta UI will reflect its configuration, telling the users they need 8 characters, but the AD only accepts a minimum of 10 characters. Pay particular attention to the password minimum age, as I’ve seen plenty of people being confused by failures when testing self-service because they kept trying it when the minimum age was in fact set to 1 day.
If my answer helped, remember to mark it as best to increase its visibility for other members of the Okta Community who might have the same questions as you.
Hope my answer helps!
--------------------------------
Ask the Experts: Okta Device Access Product Team Now Thru 3/22