Skip to main content

Who is this article for?

Code42 for EnterpriseSee product plans and features
CrashPlan for Small Business 

CrashPlan for Small Business, no.

Code42 for Enterprise, yes.

Link: Product plans and features.

This article applies to versions 6 and 7.

Other available versions:

CloudLink: What version am I on?

Code42 Support

Configure Azure for SSO in your Code42 environment

Who is this article for?

Code42 for EnterpriseSee product plans and features
CrashPlan for Small Business 

CrashPlan for Small Business, no.

Code42 for Enterprise, yes.

Link: Product plans and features.

This article applies to versions 6 and 7.

Other available versions:

CloudLink: What version am I on?

Overview

To configure your Code42 environment to use Azure AD for single sign-on (SSO), you must create a new enterprise application in Azure. This tutorial explains how to create the application in Azure and how to configure your an on-premises authority server to use Azure AD for SSO. For more information about how Code42 implements SSO, see our introduction to single sign-on.

If you use Active Directory Federation Services (AD FS) for SSO on an Azure instance, see Configure Microsoft AD FS for SSO in your Code42 environment.

Considerations

Code42 authority server
  • The authority server's SSO entityID is generated based on the administration console Website protocol, host and port and Require SSL to access console fields. Do not modify these settings after configuring SSO.
  • Your authority server must be able to access the Identity Provider metadata file.
  • The Code42 platform supports service provider-initiated SSO but does not support identity provider-initiated SSO. This means that:
    • Users cannot log in to your Code42 environment from an identity provider website or application.
    • You cannot automatically provision Code42 platform user accounts from the identity provider.
Authentication and user management
  • Users that sign in with SSO must exist in your Code42 environment, and their usernames must match SSO.
  • SSO provides user authentication but does not provide user management. One of the following directory services provides user management:
    • Local Code42 platform directory
    • LDAP
Code42 app

You do not need to modify Code42 app to enable SSO. By default, users can sign in using SSO.

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

Verify identity provider configuration
  • Make sure the SSL certificate of your SSO identity provider has been signed by a trusted Certificate Authority (CA).
  • Make sure you have administrative access to the identity provider or have contact with an identity provider administrator.
Verify network configuration
  • 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.
  • Confirm the required ports with your identity provider to determine if custom ports are being used.

Step 1: Prepare your authority server

Configure SSO certificate settings

  1. If your SSO identity provider uses encryption keys longer than 128 bits, configure your authority server to accept longer encryption keys.
  2. If your security policy requires a CA-signed certificate for SSO, replace the SSO certificate on your authority server.

Configure administration console security

  1. Install an SSL certificate that has been signed by a trusted Certificate Authority (CA).
  2. If your identity provider does not allow ports in SSO metadata, forward port 443 to port 4285 for inbound connections to the authority server.
  3. Update your authority server's default administration console address to use SSL:
    1. Go to Settings > Server.
    2. Change your authority server's Website protocol, host and port to use https and port 4285.
      If port port 443 is mapped to 4285, exclude the port.
      • Example without port forwarding: https://master-server.example.com:4285
      • Example with port forwarding: https://master-server.example.com
    3. Click Save.
  4. Require SSL for administration console access to your authority server:
    1. Go to Settings > Security.
    2. Select Require SSL to access console.
    3. Click Save.
    4. Restart the authority server.
Port mapping
If you mapped port 443 to 4285, omit 4285 from the example URLs listed in this article.

Set the authentication request property

Because Azure uses the "exact" RequestedAuthnContext comparison method for its SAML settings, you must also configure this method to "exact" on the Code42 authority server. For more information about the RequestedAuthnContext method, see the SAML 2.0 specification.

  1. Sign in to the administration console.

  2. Double-click the logo in the upper left corner of the administration console.
    The command-line interface appears in the administration console.
  3. Use the following prop.set command to set the comparison to "exact":

prop.set c42.auth.saml2.authnrequestctx.comparison exact save all

  1. To verify the new setting, run the following prop.show command:

prop.show c42.auth.saml2.authnrequestctx.comparison

  1. To ensure the new settings take effect on your Code42 server, run the node.restart command.

Step 2: Prepare Azure

Register an app in Azure

  1. Sign in to your Azure portal
  2. Go to Azure Active Directory.
  3. Select Overview.
  4. Click App Registration.
    Azure screen showing how to select "App registration".
  5. Enter a name for the new application in the Name field of the Register an application panel.
  6. For Supported account types, select Accounts in this organization directory only (Default Directory only - Single tenant).
  7. For Redirect URI, select Web and enter the URL for the authority server in your Code42 environment, and direct it to /api/SsoAuthLoginResponse.
    For example:  https://master-server.example.com:4285/api/SsoAuthLoginResponse
  8. Click Register.
    Azure screen showing how to register an application.

Expose an API for the app registration in Azure

  1. In the app registration you created in Step 1, select Expose an API.
  2. Next to Application ID URI, click Set.
    Azure screen showing how to set an application ID URI.
  3. In the Application ID URI field, enter the URL for the authority server in your Code42 environment. 
    For example: https://master-server.example.com:4285
  4. Click Save. 
  5. Make any other settings changes your app registration requires and add users to the new application. 
    See Microsoft's documentation for more information on configuring app registration settings in Azure.
    Azure screen showing how to set the "Application ID URI".

Copy your Azure federation metadata URL

  1. In the app registration you created in Step 1, select Overview.
  2. Click Endpoints.
    Azure screen showing how to select Endpoints.
  3. Copy the Federation metadata document. You will enter this in the Code42 administration console. 
    Azure screen showing how to copy the Federation metadata document.

Step 3: Add Azure to your authority server

The Azure metadata file must be accessible to your authority server to complete this step. If your network configuration prevents URL-based metadata exchange, or if you need to manually edit the identity provider's metadata file, see Make the Azure metadata file accessible below.

  1. Sign in to the Code42 administration console on your authority server.
  2. Navigate to Settings > Security > Single Sign-On.
  3. Click Add Identity Provider or Federation.
  4. In Identity Provider metadata URL, enter the URL for the identity provider metadata XML file.
  5. Click Continue.
    Additional identity provider settings appear.
    Identity provider settings
  6. In Display name, enter an identity provider name to display to users that sign in with SSO.
    If more than one SSO identity provider is offered by your Code42 environment, users are presented with a list of identity providers to choose from. The list includes all identity providers offered throughout your Code42 environment because the users' organizations are not known until they sign in.
  7. Customize mappings between Code42 platform user attributes and identity provider SSO assertion attributes.
    1. Deselect Use default mapping.
    2. Configure mapping settings for each Code42 platform user attribute:
  • Username: Select Use attribute tag and enter: http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name
  • Email: Enter one of the following: 
    • If users sign in using their Azure UPN: http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name
    • If users sign in using their email: http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress
  • First Name: http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname
  • Last Name: http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname
  1. Click Save.

Step 4: Test SSO authentication

To avoid impacting your production environment, use a test organization to verify that SSO is working properly.

  1. If necessary, add a test user to the identity provider.
  2. Sign in to the administration console on your authority server.
  3. Create a test organization.
  4. Create a user in the test organization that matches the identity provider test user.
  5. Configure the test organization to use SSO.
    1. Navigate to Organizations, then select the organization.
    2. From the action menu, select Edit.
    3. Click Security.
      Organization SSO configuration
    4. Deselect Inherit security settings from parent.
    5. From Select an authentication method, choose SSO.
      The configured SSO identity providers appear.
    6. Select the identity providers that you want to offer for the organization.
    7. From Select a directory service, select Local for testing purposes.
      Additional steps must be performed to use SSO with LDAP.
    8. Click Save.
  6. Sign in to the administration console as the test user to verify that SSO is working.

 

Step 5: Configure organizations to use SSO

Enable SSO for one or more organizations to start using SSO in your Code42 environment. If two or more identity providers are offered in your Code42 environment, tell the users in each organization which identity provider they should choose when they sign in.

Disabled inheritance
If you disable inheritance for an organization, that organization is not affected by changes to its parent organization.

Option A: Enable SSO for a specific organization

  1. Sign in to the administration console on your authority server.
  2. Navigate to Organizations, then select the organization.
  3. From the action menu, select Edit.
  4. Click Security.
    Organization SSO configuration
  5. Deselect Inherit security settings from parent.
  6. From Select an authentication method, choose SSO.
    The configured SSO identity providers appear.
  7. Select the identity providers that you want to offer for the organization.
  8. From Select a directory service, select Local.
    Additional steps must be performed to use SSO with LDAP.
  9. Click Save.

Option B: Enable SSO for all organizations

Modify the system-wide organization settings to enable SSO for all organizations.

  1. Sign in to the administration console on your authority server.
  2. Navigate to Settings > Organization.
  3. Click Security.
  4. From Select an authentication method, choose SSO.
    The configured SSO identity providers appear.
  5. Select the identity providers that you want to offer to your organizations.
  6. From Select a directory service, select Local.
    Additional steps must be performed to use SSO with LDAP.
  7. Click Save.

Step 6: Add new users that sign in with SSO

New users can create their own accounts when they first sign in to a SSO-enabled Code42 app. Alternatively, you can use the administration console to create user accounts.

Option A: Deploy the SSO-enabled Code42 app

Distribute the SSO-enabled Code42 app installer to new users.

  • New users can register accounts in your Code42 environment by signing in with SSO credentials.
  • New users begin backing up the default file selection immediately without authenticating if all of the following conditions are met:
    • The organization is configured to auto-start backups.
    • The Code42 app is modified to contain the correct organization registration key.
    • The Code42 app is modified to defer the user's password.
      Users are not able to sign in to the Code42 app or restore unless they have a valid SSO account.

Option B: Add users in the administration console

Use the administration console to add users to an organization that uses SSO.

  • Verify that the users in the organization exist in the SSO identity provider used by the organization.
  • Make sure that the Code42 environment usernames match the SSO usernames.

What to expect

Sign in with SSO

Multiple identity providers

If you offer multiple SSO identity providers in your Code42 environment, users are presented with a list of identity providers to choose from. The list includes all identity providers offered throughout your Code42 environment because the users' organizations are not known until they sign in.

Reduced authentication prompts

When a user signs in with SSO, the user does not need to reenter credentials for subsequent authentication attempts until the SAML authentication token expires. A SAML token applies to an application rather than a device, which means that a user might need to enter credentials again when signing into a different app. For example, signing in to the Code42 app does not also authenticate the administration console because one is an app on the device and the other is accessed via a web browser.

Lost access to an identity provider

A user might lose access to an identity provider for the following reasons:

  • A user is moved to an organization that does not offer his or her identity provider
  • An identity provider is removed from an organization or federation

In either case, all user devices associated with that identity provider are automatically deauthorized by your authority server. Users cannot sign in until they are added to the authentication service configured for the organization.

Make the Azure metadata file accessible

If your identity provider or network configuration prevents URL-based metadata exchange, or if you need to manually edit the identity provider's metadata file, you must make the identity provider metadata file accessible to your authority server. There are several ways to make the metadata file available:

  • Place the metadata file in the download directory on your authority server.
  • Make the metadata file available on your corporate web server.

Option A: Place the metadata file on the authority server

  1. Add the identity provider metadata file to the download directory on your authority server. Create the directory if it does not already exist on your authority server:
    • Linux: /opt/proserver/content-custom/Default-custom/download/
      Applies to Code42 servers installed as root on Ubuntu
    • WindowsC:\Program Files\CrashPlan PROe Server\content-custom\Default-custom\download\
  2. Set file permissions so that the SAML metadata file is readable by the Code42 server service. In Linux, the numeric file mode 755 should suffice, although the ideal settings for your environment might differ.
  3. Use a web browser to verify that you can access the metadata file.
    For example: https://master-server.example.com:4285/download/<metadata_filename>
    • Replace master-server.example.com with the fully qualified hostname or IP address of your authority server.
    • Replace <metadata_filename> with the name of the metadata file.
    • If you mapped port 443 to 4285, do not include the port in the URL.

Option B: Place the metadata file on a corporate web server

  1. Add the identity provider metadata file to a web server that is accessible to your authority server.
  2. Record the URL for the metadata file.
  3. Use a web browser to verify that you can access the metadata file.
  • Was this article helpful?