Install and Configure the Active Directory Password Sync Agent
Install the Active Directory (AD) Password Sync agent on domain controllers in your domain to synchronize AD password changes and send them to Okta automatically. This functionality keeps your users' AD passwords in sync with apps that are configured to use Sync Password, such as SWA apps set up to use the user's Okta password.
However, for mobile workflows, AD password resets from the Active Directory Password Sync Agent do not require sync password to be enabled. Reset password notifications trigger distribution of an updated Exchange ActiveSync (EAS) email configuration to the corresponding devices enrolled in Okta Mobility Management (OMM). In such cases where sync password is not enabled for any application, the encrypted AD password is removed from Okta after pushing it to the device.
If you've integrated AD and desktop SSO, configured apps to delegate authority to AD, and your users change their AD passwords through their machine sign-in prompt, the AD Password Sync agent detects this change and sends it to Okta automatically so that when your users sign in, change their passwords, and click on apps they use, their new passwords are automatically synced.
If you have integrated AD and configured provisioning with sync password enabled (for example, pushed your Okta password to Google Apps), the AD Password Sync agent detects a user's password change and makes sure the passwords are automatically synced. For devices enrolled in Okta Mobility Management (OMM), sync password does not need to be enabled.
Implementing the Password Sync agent requires you to install the agent on each domain controller. As agent updates are released, each domain controller must then have its agents updated. As a result, you may wish to balance the benefits which the Password Sync agent offers against the internal cost of maintaining the agents on your domain controllers. This decision will vary based on end user behavior within your organization, your application environment and your IT infrastructure.
When making your decision, consider these scenarios which may occur if Password Sync is not employed:
To use the agent, see Using Sync Password.
You can also use a script or command line to perform an unattended install of the agent. The unattended mode will not restart the system after the installation is complete. You must restart the system manually or using the shutdown /r command. The syntax is as follows:
If installing on multiple servers, you may wish to create a registry file that sets the Okta username format used by the Password Sync Agent. Creating a DWORD Value called Okta Username Format will allow you to choose between SAM Account Name (value = 1) or UPN (value = 0).
For example, to set the Username format to SAM Account Name, create a .reg file with the following:
[HKEY_LOCAL_MACHINE\SOFTWARE\Okta\AD Password Sync]
"Okta username format"=dword:00000001
Installing the AD Password Sync Agent on Windows Server Core, Release 2
Before you can install the Active Directory (AD) Password Sync agent on Windows Server Core, you must do the following:
You can now install the AD Password Sync agent as described in Installing the AD Password Sync Agent above.
To use the agent, see Using Sync Password.
Launch the Active Directory Password Sync Agent (Start > All Programs > Okta > Okta AD Password Sync > Okta AD Password Synchronization Agent Management Console). Click Verify URL to check the Okta URL is correct and the target server is reachable. If the URL is valid, a success message will appear under the Okta URL field.
Note: If an error message displays, see Troubleshooting.
You can optionally change the Log severity level setting. You can control the information that goes into logging reports by selecting one of the following options:
This section describes error conditions and how to correct them.
The agent is installed on all Domain Controllers, user's AD password has changed, but user is not able to log in to apps via desktop SSO
The problem may be that the Okta username format for your org is not set to User Principal Name (UPN) or sAMAccountName. In most cases, the Okta username format must be set to User Principal Name (UPN) or sAMAccountNamein order for the AD Password Sync Agent to work.
To check the setting, do the following:
Filter was loaded successfully, but is not enabled
If you launch the AD Password Sync agent and a message displays stating that the agent is not enabled, you must enter your Okta URL (for example, https://mycompany.okta.com) and click Verify URL.
Note: You must use the https:// prefix in your entry.
Password filter failed to load
If you launch the AD Password Sync agent and a message displays stating that the password filter failed to load, contact Okta support.
If you launch the AD Password Sync agent and the message displays The underlying connection was closed. Could not establish trust relationship for the SSL/TLS secure channel, then you installed AD Password Sync agent version 1.3.0 or later and your environment is one in which the agent's support for SSL certificate pinning prevents communication with the Okta server. This is most likely to occur in environments that rely on SSL proxies. To allow installation to complete in this case, Okta recommends that you bypass SSL proxy processing by adding the domain okta.com to a whitelist.
Alternatively, you can choose to disable SSL certificate pinning as described below, but be aware that doing so disables a security enhancement provided by the agent.
To disable support for SSL pinning, edit the Windows registry as follows:
For more information about SSL certificate pinning, see the article by the Open Web Application Security Project.