How PRO Server Integrates with LDAP

LDAP support stands for Lightweight Directory Access Protocol and is commonly used on many different platforms to authenticate users with information stored in an LDAP directory. It is becoming more widely accepted because administrators can extend the standard LDAP objects (org, person, group, etc) with new attributes.

By default, Crashplan lets users create their own username (usually email) and password which are stored internally to the PRO Server. These are not synchronized with any usernames or passwords elsewhere. Therefore, users must remember the password they used when they registered their CrashPlan client.

On the other hand, you can setup PRO Server to authenticate users against an external LDAP directory (possibly running on the same server, but not necessarily) before registering the user or giving them access to the application. This allows users to register and log into CrashPlan using their network account password.

If you delete a user from your LDAP directory, PRO Server makes note of that (it checks every few hours) and blocks that user from backing up in the future.

The following illustration shows the authentication path between the client, PRO Server and LDAP:

Yes, PRO Server still has to add each user to it's database even if the user is already in the LDAP directory. In other words, after installing a client always use the “New Account” option unless you know that the email address is already in PRO Server's database.

Never. Ever. All password management features are disabled for users that are authenticated via LDAP so if users want to change their password, they have to do it through their system administrator in the LDAP server.

The old passwords will stay in our database, however they won't be used while LDAP authentication is enabled. If you turn off LDAP, the old passwords will be used. Any new users registered after LDAP is enabled will have a random password stored in the PRO Server database and they will need to make a password reset request.

Any previously authenticated clients should continue working because they store a security key that will still be valid.

However, any users not in the LDAP database will have their accounts deactivated the next time the LDAP synchronization service runs. That means they'll have to login again. And if the server's Archive Retention Days setting is zero they will have to resend their backup data because it will have been removed from the server.

Clients never contact the LDAP server directly. Clients continue to authenticate with the PRO Server as always so the only difference is on the PRO Server side where there is an extra step to validate against your existing LDAP server.

If the client was already authenticated when the LDAP password is changed, then the client can continue backing up. The next time the user is asked to log in, he or she must enter the new LDAP password.

PRO Server regularly (on a configurable basis) compares its user base with the specified LDAP server. When it finds a user has been removed or disabled then that user is blocked and all its computers are deactivated.

If you don't want blocked users archive data immediately deleted, make sure you set the archive retention days to something greater than zero. That value is on the Server General Settings page.

The PRO Server release that will go in the spring of 2009 has an auto-accept feature for self-signed SSL certificates. In the meantime, here is a brief technical explanation of how to add a self-signed certificate to your JVM's certificate keystore.