Skip to main content

This article applies to CrashPlan PROe version 3.

Other available versions:

Cloud | Version 6 | Version 5 | Version 4icon.qnmark.png

Code42 Support

Setting Up Single Sign-On With Okta

This article applies to CrashPlan PROe version 3.

Other available versions:

Cloud | Version 6 | Version 5 | Version 4icon.qnmark.png

This tutorial explains how to integrate your Code42 environment to work with the Okta identity management provider. Okta provides a standards-based service to enable centralized user access control using Single Sign-On (SSO) technologies such as SAML. Okta's cloud-based SSO service also supports integration with an existing directory service, such as Google Apps or Active Directory.


Identity Provider
Network Considerations

  • You may need to modify your firewall rules to allow the use of SSO:
    • Configure your private network, Internet, and VPN settings to allow client devices to communicate with your Identity Provider on ports 80 and 443. Test client connectivity to the identity provider before you proceed.
    • Two-way communication on TCP ports 80 and 443 between the Identity Provider and and your master server is required. The Service Provider (your master server) and Identity Provider need to be able to communicate with each other to perform metadata exchange.
    • Confirm the required ports with your SSO provider, in the unlikely event that custom ports are being used
  • Your master server needs to be able to access the Identity Provider metadata file, which may be stored in one of two locations:
    • Locally, on your enterprise server's file system
    • On a web server in your LAN, or via WAN
      • In this case, your enterprise server must be able to access the web server hosting the Identity Provider metadata on the port and protocol you have chosen (either http or https)

External authentication systems
Our Customer Champions can help with authentication issues caused by interaction with Code42 products. However, troubleshooting authentication issues outside your Code42 environment is beyond the scope of our Customer Champions.

For assistance with external authentication systems, contact your authentication vendor.

Before you begin


The integration of Okta with the Code42 environment requires the configuration of two systems:

  • Your Okta account and dashboard
  • Your enterprise server

The following steps take you through the setup process.

Step 1: Create a custom SAML template on Okta

First, you must set up your Okta account to provide appropriate information for your Code42 environment.

  1. Sign in to to your Okta account, go to the Applications tab, and click Add Application.
  2. Select the Template SAML 2.0 App. Okta's search feature can help you locate the Template SAML 2.0 App.Okta Template Search
  3. Configure the template by filling in the following fields with the indicated values. Replace the example IP address ( with your enterprise server's actual IP address or FQDN (fully qualified domain name):
    If your master server is configured to require SSL to access the administration console, then you must use https instead of http and 4285 instead of 4280. For example, the "Post Back URL" in the example above would now be:
  4. Skip the user assignment step
    Okta displays a confirmation message: "Setup is complete. No users will be assigned this application now."
  5. Click Done Okta Configuration Complete

Step 2: Copy IdP metadata file to your web server

The IdP (Identity Provider) metadata must be available on your web server to all your devices running the CrashPlan app.

  1. In your Okta dashboard, go to Applications>Template SAML 2.0 App (SAML_Proe)>Sign On, then click View Setup Instructions.
  2. Copy the metadata to your web server as a file with the filename idp.xml.
    • The IdP metadata is presented on Applications>Template SAML 2.0 App>Sign On>View Setup Instructions within the text box under the heading "Provide the following IdP metadata to your SP provider:"Okta Copy Metadata
  3. Test the URL to the metatadata file to verify that it is accessible.
    • The IP address in the image below is shown as an example. Your IP address is different.
    • You must replace the IP address with the IP address or FQDN of your web server.Okta IDP Metadata Test
      • One technique is to use a text-editor such as vim (Linux) or notepad (Windows) to create the file by pasting the text into the editor, then saving the file as idp.xml within the root directory of your web server, or in the directory that you plan to make accessible to CrashPlan apps.

Step 3: Add a test user to Okta

Add a test user to your company's Okta account in order to test authentication.

  1. From your Okta dashboard, go to People>Add Person:Okta Add Test User
  2. Create the test user by filling in the required values, then click Add Person.

Step 4: Assign the SAML_proe application to test user

Okta requires you to assign to each SSO user the application that you created in Step 1: Create A Custom SAML Template On Okta.

From the People screen, click the user's full name, then assign the newly configured application to the user:

  1. Click Assign Applications
  2. Choose the application Template SAML 2.0 App: SAML_Proe
  3. Click SaveOkta Assign App To Test User

Step 5: Configure your Enterprise Server's SSO settings

  1. Sign in to your enterprise server and go to Settings > Security > Single Sign-On, then click the Enable checkbox.
    If SSO is already enabled, continue to the next step.Okta Enable SSO
  2. Configure your Code42 environment's SSO settings:
    1. Enter a value for Identity provider name, such as Okta
    2. Enter the URL to the IdP metadata file, as configured in Step 2: Copy IdP Metadata File To Your Web Server.
    3. Click Save.
      A message will appear in the lower left of your administration console: "Your changes have been saved."
      The Service provider metadata URL will now be visible in your administration console.
      Okta SSO Configuration Success
  3. Click on the Service provider metadata link, and view the XML file in your browser.
  4. Confirm that the "AssertionConsumerService" element uses the Location URL that you configured in Okta (in this example, Okta Confirm Assertion Via Consumer URL
  5. Open the administration console CLI.
  6. In the administration console CLI, enter the following command: prop.set b42.ssoAuth.nameId.enable true save
  7. The CLI will respond with the following message:

The system property has been set.
Some system properties require a restart before they are recognized.
b42.ssoAuth.nameId.enable=true (saved)

Step 6: Configure an organization to use Okta

Your Code42 environment must be configured to use Okta's SSO authentication instead of the native user authentication system. This example will configure a single organization to authenticate with Okta, but you can also apply these steps with the top-level organization in order to use Okta with your entire Code42 environment.

  1. If the parent organization already uses SSO: make sure that the option Inherit security settings from parent is enabled.
  2. If the parent organization does not use SSO: disable the Inherit security settings from parent option.
  3. Enable the Use Okta for authentication option (If you gave your Okta SSO service a different name, the message will reflect that name):Okta Enable SSO For Organization
  4. Click Save.

Step 7: Add a test user to the SSO-enabled organization

Add a test user to the organization that is enabled to use Okta as an SSO Identity Provider. This test user must have the same username as the test user created within Okta.

Step 8: Test the Okta SSO configuration

  1. Sign out of the Okta administration console (if you are logged in)
  2. Sign out of the Code42 environment administration console
  3. Click the Sign in using Okta buttonOkta Configuration Test Sign In
  4. You will be redirected to the Okta sign in page. Sign in using your test user's username and password:Okta Sign In Test
  5. If the test is successful, you will be successfully signed in to the enterprise server's administration console as the test user.

Step 9: Configure the CrashPlan app

In order to enable SSO on the CrashPlan app, a custom installer must be used during installation. Complete instructions on the creation of a customized CrashPlan app can be found in the article Customizing The CrashPlan app. Read and understand the process of creating a customized CrashPlan app before proceeding with the steps outlined below, which are specific to SSO.

During the creation of a custom installer, the '' script is run, or the file '' is edited, in order to set the value of a number of customizable properties. The following properties pertain to SSO:

Property Name Values Notes
ssoAuth.enabled true or false SsoAuth will not be available unless this is true. Default is false.
ssoAuth.required true or false If set to true, SSO authentication is enforced, and the standard login fields are hidden. Default is false.
ssoAuth.provider Display name of your SSO provider (label). Name of the SsoAuth identity provider. Only used if ssoAuth.enable=true. Default is Shibboleth. This value is user-facing.

Set the properties in the table above to the desired values:

  • ssoAuth.enabled must be set to 'true'.
  • ssoAuth.required may be set to either 'false' (the default) or 'true'. Set to 'true' if you want to force users to use SSO for authentication.
  • ssoAuth.provider should be set to the name you wish to be displayed to users as the name of the identity provider upon successful login.

Once you have set these properties, and the other properties as described in Customizing The CrashPlan app, continue with the standard process to create the custom installers.

Further considerations

  • SSO currently does not handle logout (single sign-off). Thus, if a user logs out of the Code42 environment, the master server does not notify other service providers, and vice-versa.
  • There is no control available in the administration console or the CrashPlan app to sign out of the SSO system. To force a user to sign out of the SSO identity provider, clear the ldp.c42 cookie from the web browser used to log in.
  • LDAP supports automated user management with the "Active Script", "Org Name Script" and "Role Name Script." However, SSO does not support custom scripts.
  • Multiple identity providers in the same environment are not supported.
  • SSO authentication may fail if the master server does not have a valid SSL certificate. If a self-signed certificate does not work, a certificate from an official Certificate Authority (CA) is required.
  • Your master server validates the SSL certificate of your SSO identity provider. If your identity provider's digital certificate does not contain the signature of a trusted Certificate Authority, validation may fail. To resolve this, install a CA-signed digital certificate on the identity provider.
  • The CrashPlan mobile apps on all platforms do not support SSO at this time.
  • SSO supports the use of the “auto register” option during CrashPlan app installation, using the value '${deferred}' for the password property in the custom installer. However, unlike the case with LDAP, the Code42 environment is not able to verify the user at the time of installation. Instead, the new user is allowed to back up immediately, without authenticating. However, users are not able to sign in to the CrashPlan app or restore unless they have a valid SSO account. If the password property is not set to deferred, the user is prompted to sign in upon first usage, as with LDAP.
  • The following warning message (found in logs on your master server) is normal: “Not syncing SSO metadata at this moment due to rate limiting." Rate limiting prevents syncing with your identity provider more than once per minute.
  • The Code42 environment supports SP (service provider)-initiated SSO. The Code42 environment does not support IdP (identity provider)-initiated SSO at this time. The user agent (either the CrashPlan app or the CrashPlan web app) initiates a session by accessing the enterprise server (acting as the SP), which then issues a SAML 2.0 AuthnRequest for the user to be delivered to the IdP.
  • In the IdP metadata file, the Code42 environment supports HTTP-POST (but not HTTP-REDIRECT). You must enable HTTP POST bindings in the IdP metadata.

If any of the caveats above are not acceptable, we recommend using LDAP or Radius for authentication and authorization instead of SSO.

Advanced topics

A number of Code42 environment system properties affect SSO behavior.

External resources

For other questions relating to Okta's identity management products, please see Okta's support site.