Leverage your organization's existing directory services environment by enabling LDAP integration in Code42 CrashPlan (previously CrashPlan PROe). You must have an on-premises master server to use LDAP with Code42 CrashPlan.
LDAP integration provides the following advantages in Active Directory, OpenDirectory, or LDAP environments:
- Simplifies the rollout and ongoing administration of your organization's users and devices
- Simplifies the user experience because the user’s existing LDAP username and password are used to sign in to Code42 CrashPlan
With LDAP integration enabled:
- The master server handles all communication with the LDAP server. Devices never communicate with the LDAP server directly, which means your directory services environment can remain behind your firewall.
- An LDAP-integrated master server is only allowed to perform search and retrieval operations. LDAP entries in your directory services environment are never modified by Code42 CrashPlan.
The following illustration shows the authentication path between devices, the master server, and directory services:
Once LDAP authentication is enabled, any password changes for LDAP-enabled users must be accomplished using the LDAP server.
Enabling LDAP integration enhances user management by:
- Adding flexibility
- Simplifying onboarding and offboarding
- Automating user management
A single Code42 environment can utilize a mix of authentication methods on a per-organization basis:
- Local accounts
- Single Sign-on (SSO)
This provides great flexibility for customizing each organization's environment and simplifies the processes of adding, removing, or suspending user privileges.
The parish that oversees two private high schools has deployed a single Code42 environment for both schools. The parish IT staff manage the Code42 environment. However, each school has its own, separate Active Directory environment.
Administrators have configured their Code42 environment so that the faculty at the boys' school are placed into the boys' school organization and authenticate against the boys' school's Active Directory server. The faculty at the girls' school are placed into the girls' school organization and authenticate against the girls' school's Active Directory server. The administrators are thus able to manage a single Code42 environment without sacrificing flexibility or functionality.
The master server synchronizes with the defined LDAP servers on a regular basis, according to the customizable synchronization schedule. When the master server synchronizes with an LDAP server, it compares the list of active users in its internal database with the entries in the LDAP directory, and applies rules to determine which users should be deactivated, which org a user should be placed in, and which roles to assign to users. An LDAP-enabled Code42 environment never changes any LDAP entries or attributes.
By default, synchronization automatically deactivates users who are not in the set of users returned by the search filter. In addition, you can configure your master server to perform other user management operations based upon user LDAP information.
LDAP integration helps to manage users, but it does not create them on its own. Create users alongside LDAP integration in one of three ways:
- Self-service: When users install the CrashPlan app and sign in as a new user, their accounts are automatically created. If their organizations are configured to use LDAP, then they must use their LDAP credentials, registration key, and Code42 server address to create their account.
- Deploy custom installers: Deploy preconfigured custom installers with software like Microsoft System Center Configuration Manager or Jamf Pro (formerly Casper Suite).
- Create users manually: Administrators can create users manually or by uploading a CSV list.
LDAP settings in the administration console
|a||LDAP Servers||List of your configured LDAP servers. Click the name to edit.|
|b||Add||Add a new LDAP server.|
|c||Registrants not found||Defines how your Code42 environment handles cases new account registration attempts for users that are not found in the LDAP search. Options are to Deny Registration or to place the user into an organization that does not use LDAP for authentication.|
|d||Every||Defines the LDAP synchronization schedule for the CrashPlan app. The CrashPlan app will communicate with the defined LDAP servers according to this schedule. Users who no longer match the search filter, or who are flagged as inactive by the Active Script, will be deactivated during synchronization. If Never is selected, the CrashPlan app will never synchronize and run the Active, Org name, or Role name scripts automatically, although initial authentication will still occur.|
|e||Last Sync||Displays how long ago the most recent LDAP sync ran.|
|f||History||View results of previous LDAP sync jobs.|
|g||Synchronize now||Initiate LDAP synchronization immediately. Users and associated devices that no longer match the search filter, or which are flagged by the Active Script, will be deactivated immediately.|
|h||Simulate Synchronize||Perform the LDAP synchronization search, but does not deactivate users. Run this job to see who would be deactivated if the sync actually ran right now.|
|a||Server Name||Label used to describe this LDAP server.|
|b||URL and search base||The protocol, host, and port used to communicate with the LDAP server, plus the search base within the LDAP structure where LDAP queries will begin.|
|c||Reachable/Unreachable||Result of the connection test to verify that the LDAP server is accessible on the defined protocol, host, and port. Possible values are Reachable or Unreachable.|
|d||Bind Anonymously||Disabled by default. Enable this option to perform LDAP binds without authenticating.|
|e||Bind DN||Used when Bind Anonymously is disabled. Enter the full DN for the LDAP user that will bind and perform LDAP queries.|
|f||Bind password||Password of the LDAP user (e) performing the bind.|
|g||Bindable/Bind failed||Results of the test used to verify that the bind user is actually able to bind to LDAP server. Possible values are Bindable or Bind failed.|
|h||Search filter||Defines which LDAP attribute your Code42 environment uses to search for users. The attribute mapping process uses the search filter to determine usernames.|
|i||Matches||Count of LDAP users that match your LDAP search parameters.|
|j||Timeout seconds||How long the authority server should wait for a response before the LDAP lookup times out.|
Attribute mapping defines how users' LDAP attributes relate to users in your Code42 environment.
|k||Search results||LDAP search results populate on the right of the window to show how the user's LDAP information maps to the user's account information within your Code42 environment.|
Attribute used to determine the username within your Code42 environment. Value is taken from the Search filter field (h).
|m||Select which LDAP attribute to set as the user's email address.|
|n||First name||Select which LDAP attribute to set as the user's first name.|
|o||Last name||Select which LDAP attribute to set as the user's last name.|
The Active script must not be left blank. The default entry is
|q||Org name script||
Using LDAP Org name script organization mapping requires that each organization in your Code42 environment has a unique name.
|s||Distinguished name||The full distinguished name of the user presented in the search results.|
|t||Username search||Search for a specific username within the returned LDAP query results.|
|u||Search pagination||Page through search results.|
Use of regex syntax causes LDAP sync to take much longer to complete than using other string functions.
History shows the results of past synchronization instances, including which users were deactivated during the sync.