LDAP integration troubleshooting
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 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:
Install the Okta LDAP agent from a command line.
- On the host server, sign in to Okta using an Okta adminAn abbreviation of administrator. This is the individual(s) who have access to the Okta Administrator Dashboard. They control the provisioning and deprovisioning of end users, the assigning of apps, the resetting of passwords, and the overall end user experience. Only administrators have the Administration button on the upper right side of the My Applications page. account with Super admin permissions, to access the Admin Console.
- Download the Okta LDAP agent:
- Click Directory > Directory Integrations.
- Click Add Directory > Add LDAP Directory.
- Review the installation requirements, and then click Set Up LDAP.
- Click Download Agent and select Download EXE Installer and download it to your Windows server.
- Open a command line and run this command:
- Complete the installation:
- If the message displays Do you want to allow the following program to make changes to this computer?, click Yes.
- Click Next.
- Accept the license agreement and click Next.
- Accept the default installation folder location, or click Browse to select another location, and click Install.
- Optional. If you want to enable LDAP over SSL (LDAPS), complete Enable LDAP over SSL, and then continue with this procedure.
- On the LDAP configuration screen, enter the following information:
- LDAP Server — Enter the LDAP host and port in the form of host:port. For example: ldap.mycompany.com:389.
- Root DN — The root distinguished name of the DIT from which users and groups are searched.
- Bind DN — The distinguished name of the bind LDAP user that is used to connect to the LDAP directory by the agent.
- Bind Password — The password of the bind distinguished name that is used to connect to the LDAP directory by the agent.
- Optional. Use SSL connection — Select if you have enabled LDAP over SSL (LDAPS). (Note: If you select this without performing the steps in Enable LDAP over SSL, the error Failed to connect to the specified LDAP server displays.)
- Click Next.
- Optional. Enter a proxy server for the Okta LDAP agent on the Okta LDAP Agent Proxy Configuration page, and then click Next.
If the LDAP proxy server returns its own schema, issues importing user data can occur when the proxy server schema and LDAP server schemas are different. To avoid data importation issues, make sure the LDAP proxy server and LDAP server schemas are identical.
- To register the Okta LDAP agent with the Okta service, enter your Okta subdomain name, and then click Next.
- On the Okta Sign In page, enter the username and password for your Okta admin account, and then click Sign In.
- Click Allow Access to access the Okta API. Note: If an error message appears, see Locate the Okta LDAP agent log.
- Click Finish.
- Configure the LDAP integration settings.
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.
When verifying your username, you receive this error
Username: Does not match required pattern
The username must be in an email format. Verify the import settings are set correctly. See Install and configure the Okta LDAP agent.
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). See Enable LDAP over SSL.