Troubleshoot LDAP Server Integration Errors
Most LDAP problems will result in a single Failed to Authenticate message when trying to log in.
The best way to troubleshoot a failed login is to test the settings in the security provider's configuration page. The section below helps you to understand the messages you may receive.
If testing a username and password from the Security Providers page provides no errors but the user cannot log into BeyondTrust using those same credentials, please check that at least one of the following sets of criteria is met.
- The user has been expressly added to an existing group policy.
- A default group policy has been set for the security provider configuration created to access the server against which the user is authenticating.
- The user is a member of a group that has been expressly added to an existing group policy, and both user authentication and group lookup are configured and linked.
Message 1: Authentication Failed
- The username and password that you are testing do not match.
- Reenter the credentials or attempt another username and password.
Message 10: Server Unavailable
- Your DNS information may be incorrect. You can test if your DNS server resolves by using the tools on the Support > Utilities page in your BeyondTrust /appliance interface.
- Port 389 for LDAP or port 636 for LDAPS must be open on any firewall that may be between your server and your Secure Remote Access Appliance or between your server and a connection agent you may have installed. BeyondTrust also supports global catalog over port 3268 for LDAP or 3269 for LDAPS.
- If using LDAPS or LDAP with TLS, the hostname you entered must match the hostname used in your LDAP server's public SSL certificate's subject name or the DNS component of its alternate subject name.
- For example, if the certificate is issued to support.example.com and the hostname you entered is remote.example.com, the connection will fail because the server does not know that remote.example.com is the same site as support.example.com.
- In this case, you must change the hostname entered on the configuration page.
- You can use a wildcard certificate to certify multiple subdomains of the same site. For example, *.example.com would certify both support.example.com and remote.example.com.
- Your server and your Secure Remote Access Appliance must be able to communicate.
- For example, if your server is behind your company firewall but the Secure Remote Access Appliance is in the DMZ, they will not be able to communicate directly.
- In this case, install a connection agent to enable communication.
- Logging can help to identify if there is a problem with the connection agent. To enable connection agent logging, follow the steps below.
- Browse to the directory in which your connection agent is installed and open the bomgar.ini file.
- At the end of the [General] section, append the line agent_log_filename="[path]\[provider]_Con_Agnt.log" where [path] is the filepath to your connection agent and [provider] is the configured name of your security provider. Save and close the file.
- To activate the connection agent change, open your services management console by typing Services.msc in your Run dialog. Select and restart the BeyondTrust connection agent.
- The log will be created in the directory that holds your connection agent files.
- Ensure that the connection agent is online and able to connect outbound to the appliance.
- It is recommended that you install the agent on a system with high availability.
- The best way to prevent failed authentication if the connection agent's host system should go down is to use BeyondTrust to cluster two or more security providers in top-to-bottom (failover) mode. This will allow a single domain controller to have some redundancy.
- One way to verify if the connection agent has lost connection to the server is to open a configured group policy. If the Group Policy Members field displays @@@ in front of a random string of characters, the connection agent has likely gone offline or lost communication.
- If a connection agent loses communication, the connection agent logs should indicate that it could not make a secure outbound connection to the appliance.
- The security provider name and password you entered when installing a connection agent must be exactly the same as those you entered when you set up the security provider configuration.
- It is a common mistake to use the controller's name and administrative password when setting up the connection agent rather than the name and password you set in the security provider configuration.
- Verify the value defined as the server name by opening the bomgar.ini file in the connection agent directory and checking the ldap_agent_name value.
- To change the server name or password referenced by the connection agent, first uninstall the existing connection agent and then install a new copy of the connection agent.
- When prompted for the security provider name and password, be sure to enter the values you defined in the security provider configuration on the BeyondTrust /login interface. Complete the installation.
Message 11: User Not Found
- The bind credentials and search base DN must all be in the correct format on the security provider's configuration page.
- If using Active Directory, the account specified by the bind credentials must have permission to read other users' group memberships in the Active Directory store.
- The search query must be correct for your specific configuration. Please refer to your security provider's documentation for further help with this configuration.
Error 6ca and Slow Logins
- A 6ca error is a default response signifying that the Secure Remote Access Appliance has not heard back from the DNS server. It may occur when attempting to log into the representative console.
- If users are experiencing extremely slow logins or are receiving the 6ca error, verify that DNS is configured in your /appliance interface.
Troubleshooting Individual Providers
When configuring an authentication method tied to group lookup, it is important to configure first user authentication, then group lookup, and finally group policy memberships. When troubleshooting, you will want to work in reverse.
- Verify that the group policy is looking up valid data for a given provider and that you do not have any @@@ characters in the Policy Members field.
- Next, if a group provider is configured, verify that its connection settings are valid and that its group Search Base DN is in the proper format.
- If you want to use group lookup, verify that the security provider is set to look up group memberships of authenticated users.
- To test the user provider, set a default policy and see if your users are able to log in.