Skip to main content
Code42 Support

Troubleshoot LDAP

Applies to:
  • Code42 CrashPlan (previously CrashPlan PROe)

Overview

LDAP provides a powerful and flexible way to manage your user base. Its flexibility and features, however, mean that your Code42 environment's LDAP implementation may sometimes experience problems or invalid configurations. This article will help you troubleshoot a number of LDAP issues.

Affects

Private master servers configured with LDAP

Before you begin

This article includes advanced instructions on your Code42 environment's LDAP configuration. Familiarize yourself first with these foundational articles on LDAP and your Code42 environment:

Considerations

The Code42 environment's LDAP implementation provides many settings and features. If one of these settings is inadvertently changed, or if the associated Microsoft Active Directory, Apple Open Directory, or LDAP server is offline or experiences a configuration change, then your Code42 environment's LDAP functionality may be affected. Network and firewall settings are also common sources of problems.

This article will help you try to determine the source of LDAP issues and suggest solutions for them.

Diagnosing

Your Code42 environment has a number of ways to alert you to LDAP problems:

Each of these items is discussed in greater detail below. Keep in mind that LDAP is a complex subject, and that it may take some time, research, and effort to isolate a problem related to LDAP.

Alerts overview page and emailed alerts

The Alerts Overview page contains two alerts relevant to LDAP. The emailed alerts are identical, and are sent to the email addresses configured at Settings > Notifications.

Refer to these alert description articles for more details and possible solutions.

LDAP configuration page

The LDAP configuration pane, located at Settings > Security > LDAP > LDAP Servers contains information on your LDAP configuration and mapping. If values are configured incorrectly, warning icons will appear to indicate an LDAP problem.

Testing values or options
In order to force your master server to test a value or option, and display errors and possible issues, tab through the LDAP configuration fields.

A configuration pane with no visible issues looks like the example below:

LDAP configuration with no obvious errors

LDAP logs

LDAP activity appears in com_backup42_app.log.[0-9], which is located in the Code42 server log directory:

  • Linux: /var/log/proserver
    Applies to Code42 servers installed as root on Ubuntu
  • Windows: C:\Program Files\CrashPlan PROe Server\logs
  • OS X: /Library/Logs/PROServer

Using your favorite text editor or textual search tool (e.g., grep in Linux/Unix), search for the keyword "DIRSYNC".

For example, from a terminal window in the Linux operating system, you could enter the following command to find all LDAP related entries in the latest log file:

root@omega:/var/log/proserver# grep DIRSYNC com_backup42_app.log.0
[07.07.14 16:50:50.567 INFO    jetty-web-665        .directory.impl.sync.DirectorySyncOrgCmd] DIRSYNC:: Running for org:2/Default
[07.07.14 16:50:50.579 INFO    jetty-web-665        .directory.impl.sync.DirectorySyncOrgCmd] DIRSYNC:: Completed for org:2/Default users:2, deactivated:0, activated:1, moved:0, rolesChanged:0
[07.07.14 16:50:50.580 INFO    jetty-web-665        ore.directory.impl.sync.DirectorySyncCmd] DIRSYNC:: Summary for orgIds:, [2,3], users:2, deactivated:0, activated:1, moved:0, roleChanges:0, simulated:false
[07.07.14 16:50:50.580 INFO    jetty-web-665        com.backup42.history.CpcHistoryLogger   ] HISTORY:: Subject[1/admin, orgId:1] DIRSYNC:: Unblocking and activating user:5/jdoe@code42.com in org:2/Default simulated:false
[07.07.14 16:50:50.661 INFO    jetty-web-665        ore.directory.impl.sync.DirectorySyncCmd] DIRSYNC:: summary email sent to:[todd+vm@code42.com], users:2, deactivated:0, simulated:false
[07.07.14 16:52:24.008 INFO    jetty-web-666        ore.directory.impl.sync.DirectorySyncCmd] DIRSYNC:: Submitting for orgs: , [2,3]
[07.07.14 16:52:24.012 INFO    jetty-web-666        .directory.impl.sync.DirectorySyncOrgCmd] DIRSYNC:: Running for org:2/Default
[07.07.14 16:52:24.017 INFO    jetty-web-666        .directory.impl.sync.DirectorySyncOrgCmd] DIRSYNC:: Error synchronizing 2/toddojala, SYSTEM com.code42.core.directory.DirectoryException: Exception while attempting to search LDAP
[07.07.14 16:52:24.026 INFO    jetty-web-666        .directory.impl.sync.DirectorySyncOrgCmd] DIRSYNC:: Error synchronizing 5/jdoe@code42.com, SYSTEM com.code42.core.directory.DirectoryException: Exception while attempting to search LDAP
[07.07.14 16:52:24.027 INFO    jetty-web-666        .directory.impl.sync.DirectorySyncOrgCmd] DIRSYNC:: Completed for org:2/Default users:2, deactivated:0, activated:0, moved:0, rolesChanged:0
[07.07.14 16:52:24.027 INFO    jetty-web-666        ore.directory.impl.sync.DirectorySyncCmd] DIRSYNC:: Summary for orgIds:, [2,3], users:2, deactivated:0, activated:0, moved:0, roleChanges:0, simulated:false
[07.08.14 05:39:37.658 INFO    GuiceCoreRuntime 13  ore.directory.impl.sync.DirectorySyncCmd] DIRSYNC:: Submitting for orgs: , [2,3]
[07.08.14 05:39:37.663 INFO    GuiceCoreRuntime 13  .directory.impl.sync.DirectorySyncOrgCmd] DIRSYNC:: Running for org:2/Default
[07.08.14 05:39:37.678 INFO    GuiceCoreRuntime 13  .directory.impl.sync.DirectorySyncOrgCmd] DIRSYNC:: Completed for org:2/Default users:2, deactivated:0, activated:0, moved:0, rolesChanged:0
[07.08.14 05:39:37.678 INFO    GuiceCoreRuntime 13  ore.directory.impl.sync.DirectorySyncCmd] DIRSYNC:: Summary for orgIds:, [2,3], users:2, deactivated:0, activated:0, moved:0, roleChanges:0, simulated:false

The actual messages you see in your log files will depend on the LDAP settings and activity in your Code42 environment.

Log files
Your Code42 environment rotates log files when they reach certain size. The current application log is com_backup42_app.log.0. Older logs are signified by com_backup42_app.log.1, and so on.

Changing the logging level

You can change the logging level of the LDAP activity of your master server in order to help gather information when troubleshooting.

To change the logging level to include the most detailed information, enter the following command in the administration console CLI:

log com.code42.core.ldap trace

The logging levels will return to the default level (info) when the Code42 server restarts. You can manually change the LDAP logging levels back to default without a server reboot by entering the following command in the administration console CLI:

log com.code42.core.ldap info

For more information on the log command, see the Administration console command-line interface reference.

Troubleshoot LDAP

Each section below describes an LDAP issue, its symptoms, and a solution.

URL unreachable

If the LDAP server is unreachable for any reason, you will see a warning icon to the right of the URL and search base field. Hover over it to see the tooltip Unreachable:

URL Unreachable

Solution
  1. Check that you have entered the correct URL or IP address
  2. Read LDAP Connection Problem for further troubleshooting

Bind failure

If your master server is unable to bind to the LDAP server, you will see the message "Bind failed" to the right of the Bind DN field. If you hover over the warning icon to the right of the "Bind password field", you will see a tool tip reading "Bind failed":

BIND failure

False Bind Failed Warnings Possible

Due to a known issue, the administration console sometimes displays a Bind failed message and/or a warning icon Warning icon next to the Bind password field, even though the values for Bind DN and Bind password are correct.

If you think your Bind DN and Bind password values are correct and that the warning icon is being displayed in error, you should take the following steps:

  1. Confirm that your search base and search filter are correct
  2. Check the Attribute Mapping section of the LDAP configuration pane. If user information is being returned from your directory server and displayed, then you can safely ignore the Bind failed message and/or warning icon.
Solution

If the binding process fails, the master server is unable to authenticate with the LDAP server. This could be caused by a number of issues:

  • The Bind DN (distinguished name) is not correct
  • The password for the Bind user may not be correct
  • The entry for the Bind DN may have changed on the LDAP server
  • The password for the Bind DN may have changed on the LDAP server

Confirm that the Bind DN and Bind password values are correct, and that the Bind user has the privileges needed to read entries from the LDAP server and search base.

If binding still fails, confirm that the Bind DN and password have not been inadvertently changed on the LDAP server. Contact your LDAP administrator, if necessary.

Search filter issues

Search filter invalid

Invalid search filter

If the search filter contains syntax errors or formatting errors, you will see the error message "Invalid. Example: (mail=?)" to the right of the search filter field.

Solution

Use valid formatting for your search filter. Search filters can contain multiple parameters joined by logical "and" statements. For example, here is a valid filter that looks for entries with the object class inetOrgPerson, and returns entries based on email address:

(&(objectclass=inetOrgPerson)(mail=?))

 

Search filter returns multiple results for each username

Search filter must return unique results
In order for your master server to successfully sync with an LDAP server, the search filter must return unique results for each user entry in the configured search base. For example, if the search filter looks for users based on the uid, then there must be a one-to-one relationship between users and uids.

Because you can create a search filter based on any combination of object classes and attributes, it is possible to create a search filter that returns multiple results for a single combination of attributes and objects. This will cause the master server to skip the affected user or users during sync.

In the example screenshot below, there are two users with entries in the configured LDAP server who have the same last names:

  • Jane Doe
  • Joe Doe

If the search filter is set to look for just the last name (using the sn or surname attribute), then one or both of these users are skipped during syncs:

Multiple search filter results

Solution

Choose a search filter that returns unique results. In the example above, changing the search filter to the following search string solves the problem, because each user has a unique email address:

(mail=?)

Corrected search filter

Search filter returns no results

Search filter returns no results

Search filter must return results
If your search filter returns no search results on the LDAP configuration screen, then the search filter is incorrect, or a serious problem has occurred within your LDAP server.

This isssue prevents new users from registering (or shunts them into the organization designated for registrants who are not found in the LDAP search). If the search filter on your master server finds no users, then all active users in the affected organizations could be deactivated, and become unable to backup, restore, or sync.

Solution
  • Ensure that your search filter uses the appropriate combination of attributes to find unique entries for each user
  • Confirm on the LDAP server that users are present and in the appropriate LDAP locations

Search base error

If the search base is not correct or is omitted, no search results will be returned. Your users will be deactivated, and new users will not be added (or will be added to the organization configured to receive non-LDAP users).

This problem may be hard to detect, because the LDAP server will still appear to be reachable as long as the URL is correct. In the screenshot below, the URL is correct, but the search base is incorrect:

URL reachable but search base wrong

If you tab through the "Search filter" field, however, the search will fail, and you will be alerted with the message "Error performing search," to the right of the "Search filter" field:

URL reachable but search base wrong search fails

Solution

Study your LDAP schema with an LDAP browser in order to choose an appropriate search base. See the example LDAP schema below, as displayed by an open source LDAP browser (JXplorer):

Sample Jxplorer browser

In this example, a valid search base would be "dc=testdomain,dc=c42". The entire URL and search base would be:

ldap://ldap:389/dc=testdomain,dc=c42

Another valid search base would be:

ldap://ldap:389/ou=people,dc=testdomain,dc=c42

This is because the desired users are within the "people" container of the LDAP hierarchy. You should have a good understand of your organizations LDAP hierarchy before setting the search base.

Unable to retrieve users

If the LDAP search is unable to retrieve users after you have confirmed that the URL, search base, Bind DN, password, and search filter are correct, you can enable a command-line setting to troubleshoot the user retrieval.

Solution
  1. Enter the following command in the administration console CLI:
    • prop.set b42.ldap.ignore.partialResultException true save
  2. Restart the Code42 server with the following command:
    • node.restart

Reactivation of manually deactivated users

If you use the administration console to directly deactivate users from an LDAP-enabled organization, these users will be reactivated at the next LDAP sync.

Solutions

You may choose one of the following solutions:

  • For all users and devices in LDAP-enabled orgs, you must deactivate or remove the users from the LDAP server, rather than directly from the master server.
  • Create a new organization that is not linked to any LDAP servers, and move users to that organization before deactivating them. They will then not be reactivated by LDAP syncs.
  • Change the user's username, or whatever attribute is mapped to the LDAP search filter in your master server. The user will no longer be affected by LDAP syncs.

Move a large number of users

If an LDAP administrator moves large numbers of users at a time from an organization within your Code42 environment (or the LDAP container that corresponds to the organization based on the Org Name script), then your master server may enter an unresponsive state.

Solution

Contact our Customer Champions for Code42 CrashPlan support or CrashPlan for Small Business (previously CrashPlan PRO) support.

Referrals to remote LDAP servers

If your LDAP environment refers clients to remote LDAP servers, then you may want to change the following property on your master server using the administration console CLI. Otherwise, clients may not have access to the most current information for an organization or user:

  1. Enter the following command in the administration console CLI:
    • prop.set b42.ldap.referral follow save
  2. Restart the Code42 server with the following command:
    • node.restart

Your master server will now follow LDAP referrals.

User management script problems

The Active, Org Name, and Role scripts provide powerful ways to manage users' status, organization membership, and roles. However, if the scripts use incorrect syntax or formatting, unintended results can occur during LDAP sync. Read the article User Management With LDAP Integration, and verify that your scripts are performing as intended.

External resources