To troubleshoot LDAPLightweight Directory Access Protocol (LDAP) is a lightweight client-server protocol for accessing directory services, specifically X.500-based directory services. LDAP runs over TCP/IP or other connection oriented transfer services. issues, obtain an LDAP browser such as Apache Directory Studio.
Note that the schema templates are merely suggestions based on common values. Each LDAP environment is unique and might require you to override the default values with your environment-specific settings. You can use Apache Directory Studio to examine attributes for existing users and groupsGroups allow you to organize your end users and the apps they can access. Assigning apps to large sets of end users is made easier with groups. to verify the template values, or you can select the appropriate setting.
Changing templates modifies all template default values. Settings that you override are not changed.
During agentA software agent is a lightweight program that runs as a service outside of Okta. It is typically installed behind a firewall and allows Okta to tunnel communication between an on-premises service and Okta's cloud service. Okta employs several agent types: Active Directory, LDAP, RADIUS, RSA, Active Directory Password Sync, and IWA. For example, users can install multiple Active Directory agents to ensure that the integration is robust and highly available across geographic locations. installation, after clicking Allow Access, the following error message displays:
Failed to parse response from Okta and Unable to register the agent. Error code 12.
Check the log and look for the entry,
javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException: No valid public key found in certificate chain.
If the log contains the above entry, then you are probably attempting to install Java LDAP agent version 5.3.1 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 domainA domain is an attribute of an Okta organization. Okta uses a fully-qualified domain name, meaning it always includes the top-level domain (.com, .eu, etc.), but does not include the protocol (https). okta.com to a whitelist.
Alternatively, you can choose to disable SSL pinning as described below, but be aware that doing so disables a security enhancement provided by the agent.
To disable support for SSL certificate pinning, perform the procedure below appropriate for your operating system:
Note: Some of these steps use the Okta Active DirectoryActive Directory (AD) is a directory service that Microsoft developed for the Windows domain networks. It is included in most Windows Server operating systems as a set of processes and services. Initially, Active Directory was only in charge of centralized domain management. agent setup modules. This is strictly for functionality; Active Directory is not required to use LDAP.
Install the agent from a command line as follows:
- Perform steps 1 through 5 of the procedure Installing the LDAP Agent on Windows.
- Instead of double-clicking the file as directed in step 6, open a command line and enter the following:
- Press Enter.
- Complete the installation as described in Installing the LDAP Agent on Windows.
If you want to re-enable support for SSL certificate pinning if it was disabled:
- Locate and open the AD agent configuration file:
C:\Program Files (x86)\Okta\Okta AD Agent\OktaAgentSetup.exe.config
- Change the SSL pinning enabled setting to True:
- Save the configuration file and restart the agent.
- From a command line, change the SSL pinning enabled setting to false:
$ sudo /opt/Okta/OktaLDAPAgent/scripts/configure_agent.sh -sslPinningEnabled false
- Save the configuration file and restart the agent.
If you want to re-enable support for SSL certificate pinning after you have completed installation, open OktaLDAPAgent.conf and change the SSL pinning enabled setting to true.
For more information about SSL certificate pinning, see the article by the Open Web Application Security Project.
You created a new role in your LDAP directory, but the role is not imported into Okta when users assigned to the role sign in to Okta, even though JIT is enabled.
When does Okta bring LDAP roles into Okta?
Okta brings LDAP roles into Okta only during imports, not during JIT. Once brought into Okta, LDAP roles are represented as groups.
When does Okta bring LDAP groups into Okta?
Okta brings LDAP groups into Okta during imports and JIT.
If you don’t want to import all user accounts into Okta, consider implementing any of the following workarounds in your Preview orgThe Okta container that represents a real-world organization.. If you get the results that you expect, you can then implement the workaround in your Production org.
Import a group into Okta that has the same membership as a particular LDAP role
Create a group in LDAP that has the same membership as the role in LDAP that you want to import.
Using either JIT provisioning or an LDAP Import, bring that group and its membership into Okta and assign it to the desired application or integration.
Perform an LDAP import into Okta without confirming undesired objects
In Okta, go to Directory > Directory Integrations > LDAP > Settings > Import Settings.
In the Import Matching Rules section, scroll down to When no match found and select Manually confirm new user. This ensures that no new user accounts are created in Okta automatically when you run an import.
Run an import against your LDAP directory to import the group you created in Step 1. Group members are added to the group later when they JIT into Okta.
Temporarily segregate inactive LDAP accounts
If you don’t want to perform an import because your LDAP directory contains a large number of inactive user accounts, you can perform the following workaround to identify likely inactive accounts and segregate them before you import:
Run a query against your LDAP directory for the attribute lastlogon (or another attribute that filters for inactive accounts).
Move the inactive user objects out of their synchronization container to ensure they are not introduced into Okta during import. You can move these objects back in after the import is finished.
You selected the Use SSL connection check box and you receive the error
Failed to connect to the specified LDAP server displays.
Make sure that you have enabled LDAP over SSL (LDAPS) when configuring the LDAP agent.