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:
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.
Your Code42 environment has a number of ways to alert you to LDAP problems:
- Alerts that appear on the Alerts Overview page
- Emailed alerts
- Icons on the LDAP configuration page
- Logs within the Code42 environment
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.
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 activity appears in com_backup42_app.log.[0-9], which is located in the enterprise server log directory:
- Linux: /var/log/proserver
Applies to enterprise servers installed as root on Ubuntu
- Windows: C:\Program Files\CrashPlan PROe Server\logs
- OS X: /Library/Logs/PROServer
- Solaris: /var/log/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:email@example.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:[firstname.lastname@example.org], 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 email@example.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.
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 three commands in the administration console CLI:
log ldap trace log com.code42.ldap trace log com.code42.core.ldap trace
The logging levels will return to the default level (info) when the enterprise server restarts. You can manually change the LDAP logging levels back to default without a server reboot by entering the following three commands in the administration console CLI:
log ldap info log com.code42.ldap info log com.code42.core.ldap info
For more information on the
log command, see the Administrator Console Command-Line Interface reference.
Each section below describes an LDAP issue, its symptoms, and a solution.
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:
- Check that you have entered the correct URL or IP address
- Read LDAP Connection Problem for further troubleshooting
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":
Due to a known issue, the administration console sometimes displays a Bind failed message and/or a 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:
- Confirm that your search base and search filter are correct
- 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.
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
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.
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:
Search filter returns multiple results for each username
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:
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:
Search filter returns no 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.
- 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:
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:
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):
In this example, a valid search base would be "dc=testdomain,dc=c42". The entire URL and search base would be:
Another valid search base would be:
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.
- Enter the following command in the administration console CLI:
prop.set b42.ldap.ignore.partialResultException true save
- Restart the enterprise server with the following command:
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.
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.
Moving 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.
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:
- Enter the following command in the administration console CLI:
prop.set b42.ldap.referral follow save
- Restart the enterprise server with the following command:
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.