Configure Microsoft AD FS for SSO in your CrashPlan cloud environment

This article applies to CrashPlan Professional, Enterprise, and MSPs.png

Overview

This tutorial explains how to configure your CrashPlan cloud environment to use single sign-on (SSO) with Microsoft Active Directory Federation Services (AD FS) 3.0. 

This article assumes you are already familiar with SSO and the SAML standard. For more information about how the CrashPlan platform implements SSO, see Introduction to single sign-on .

Compatible CrashPlan platform components

Compatible with SSO
  • CrashPlan app for Windows, Mac, and Linux
  • CrashPlan console

Considerations

External authentication systems
Our technical support engineers can help with authentication issues caused by interaction with CrashPlan products. However, troubleshooting authentication issues outside your CrashPlan environment is beyond the scope of our technical support team. For assistance with external authentication systems, contact your authentication vendor.
  • To use this functionality, you must be assigned the Identity Management Administrator role. 
  • CrashPlan usernames must match SSO usernames. How you accomplish this depends on how you deploy CrashPlan apps.
  • CrashPlan supports service provider-initiated SSO but does not support identity provider-initiated SSO. Therefore, users cannot sign in to your CrashPlan environment from the identity provider's website or application, but instead must log in using a browser bookmark. 
  • SSO provides user authentication but does not provide user management. Set up SCIM provisioning or use the CrashPlan console to manage users
  • CrashPlan does not support Single Logout (SLO). Users must sign out of the identity provider to end their single sign-on session.
  • The CrashPlan console expects SAML assertions to be signed. To configure CrashPlan to support advanced SAML request configurations, see Set SAML attributes for SSO in CrashPlan.

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 port 443. Test client connectivity to the identity provider before you proceed.
  • If you want to use URL-based metadata exchange to configure CrashPlan and the identity provider to work together, make sure two-way communication is available between them on TCP port 443. If two-way communication is not available or not allowed, you must download the identity provider's metadata file and make it accessible to CrashPlan.
  • Confirm the required ports with your identity provider to determine if custom ports are being used.

Determine whether you need to configure multiple CrashPlan tenants

Before you begin configuring SSO for CrashPlan, consider whether your company has more than one CrashPlan tenant that you need to connect to your SSO identity provider. Large companies and organizations often have separate, dedicated CrashPlan cloud instances (or "tenants") in use by different groups or departments. 

If you have more than one CrashPlan tenant to connect to your SSO identity provider, you need to obtain an entity ID URL for each CrashPlan tenant. An entity ID is a unique string that identifies a specific tenant to your SSO identity provider. The tenant-specific entity ID URL is composed of the CrashPlan domain followed by the tenant ID, and can be found in the CrashPlan service provider metadata URL file in each tenant. For example:

"entityId": "https://example.com/42424daa-424c-4e42-42c4-c424242420d4" 

 Metadata displays incorrectly in Safari

The Crashplan service provider metadata page will not load correctly in Apple's Safari browser. Paste the metadata URL into the address bar of an alternative browser if you need to view the correct output such as the entityID.

Step 1: Add AD FS as an authentication provider

To complete this step, you must first verify that AD FS is deployed according to Microsoft's instructions.

  1. Sign in to the CrashPlan console.
  2. Navigate to Administration > Integrations > Identity Management.
    CloudSSO-identity-mgmt-authentican-provider-new_no_nav.png
  3. Click Add Authentication Provider.
    CloudSSO-add-authenticaion-provider-dialog.png
  4. In Display name, enter an identity provider name to display to users that sign in with SSO.
    If your CrashPlan environment provides more than one SSO identity provider, users see a list of providers to choose from. They must select the provider configured for their CrashPlan organization.
  5. In Provider's Metadata, choose one of the following options:  
    •  Enter URL: Paste the URL for the AD FS metadata XML file, for example:https://<adfs-server>/federationmetadata/2007-06/federationmetadata.xml
    • Upload XML  File: Upload the AD FS metadata XML file to your instance of the CrashPlan console.
      Custom domains are not supported
      When entering the URL for the XML metadata file, custom domains are not supported. You must use the standard domain of your identity provider. 
  6. Click Create Provider.
    Authentication provider settings appear.
  7. Copy the CrashPlan Service Provider Metadata URL. You will use this in the Step 2 to create a relying party trust between AD FS and your CrashPlan console. Alternatively, you can right-click the URL and save the metadata as a .xml file to upload directly to AD FS.
    Identity Management Already Configured Metadata.png
Provider information message

Note the following message on the dialog:
This provider will not be applied to an organization until you update the organization security settings.

Do not apply this authentication provider to organizations yet. You will apply this provider to a test organization and to production organizations in later steps.
  1. If you choose not to use the default mapping, you can use Attribute Mapping to customize mappings between CrashPlan platform user attributes and authentication provider SSO assertion attributes.
    1. Click the Edit icon. 7.0_console_edit_icon.png
    2. Deselect Use default mapping.
    3. Configure mapping settings for each CrashPlan platform user attribute.
      Each field supports up to 128 characters. 
      • Username: Specify the SSO identifier or attribute that maps to the CrashPlan platform username.
        • Select Use nameId to use the SSO name identifier.
        • Select Use attribute tag to enter a custom SSO attribute.
      • Email: Enter the SSO attribute that contains user email addresses.
      • First Name: Enter the SSO attribute that contains user first names.
      • Last Name: Enter the SSO attribute that contains user last names.
    4. Click Save.
  2. Local Users displays the current user. If there are any other users you want to exempt from using this authentication provider to log in, enter them here.

Step 2: Add the CrashPlan service provider metadata URL to AD FS

  1. If there is a mix of Windows, Mac, and Linux computers in your CrashPlan environment, go to Edit Global Authentication Policy in AD FS, and enable both Windows authentication and Forms authentication. See Microsoft's instructions
  2. Create a relying party trust between AD FS and your CrashPlan console.
    1. Follow the wizard steps to configure the relying party trust.
    2. When you are prompted for the relying party metadata, provide the URL you copied or upload the metadata .xml file you downloaded from the CrashPlan Service Provider Metadata URL in Step 1.
  3. Create a claim rule to send LDAP attributes as claims.
    The claim rule maps Active Directory attributes to CrashPlan user attributes.
    1. Map the LDAP e-mail addresses attribute to outgoing claim type uid.  This maps directory email addresses to CrashPlan usernames.
      In the CrashPlan cloud usernames must be email addresses. 
    2. Map other outgoing claim types such as givenNamesn, and mail.
  4. Ensure that Active Directory uses the SHA-256 hash algorithm:
    1. Right-click the relying party trust, then select Properties.
    2. Click Advanced.
    3. Verify that Secure hash algorithm is set to SHA-256.
      CrashPlan uses SHA-256 for the hash algorithm by default. For information about changing the signature and digest algorithms, see Set SAML attributes for SSO in CrashPlan.

Step 3: Test SSO authentication

To start, create a test user in AD FS. Then create a test organization in the CrashPlan console.

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

  1. Create a test user in your identity provider. 
  2. Sign in to the CrashPlan console
  3. Create a test organization.
  4. Create a user in the test organization who matches the identity provider test user. 
  5. Configure the test organization to use SSO:
    1. Navigate to Administration > Integrations > Identity Management.
    2. Select the authentication provider.
    3. Click Edit 7.0_console_edit_icon.png next to Organizations in use.
    4. Select the test organization. 
      Note that you can also use an organization's settings to select an authentication provider to use for SSO.
    5. Click Save.
  6. In the upper-right of the CrashPlan console, select Account Account_top_nav.png > Sign Out
  7. Sign back in to the CrashPlan console as the test user to verify that SSO is working. 

Step 4: Apply this provider to production organizations

  1. Sign in to the CrashPlan console
  2. Navigate to Administration > Integrations > Identity Management.
  3. Select the authentication provider.
  4. Click Edit 7.0_console_edit_icon.png next to Organizations in use.
  5. Select organizations to use the authentication provider for SSO.
    If applicable, select Inherits settings to identify whether an organization inherits the setting from its parent organization. To enable SSO for all organizations, select the top-most organization. (Note that you can also use an organization's settings to select an authentication provider to use for SSO.)
  6. Click Save.

Step 5: Add new users who sign in with SSO

  1. In AD FS, add new users for whom you want to enable login to CrashPlan. See Microsoft's documentation for information about adding users.
  2. Ensure the same users are set up in CrashPlan. You can add users manually with the CrashPlan console to an organization that uses SSO, enable SCIM provisioning, or deploy CrashPlan apps to users in an organization that uses SSO.

What to expect

Reduced authentication prompts

When users sign in with SSO, they do not need to re-enter 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, the single sign-in process differs whether users sign in to the CrashPlan console or the CrashPlan app:

  • CrashPlan console: When users sign in to the CrashPlan console, they are redirected in the web browser to sign in to their SSO identity provider. As soon as they sign in to their identity provider, the CrashPlan console launches. 
  • CrashPlan app: When users sign in to the CrashPlan app, following message appears: "To complete the sign in process, go to your web browser. This screen updates automatically once login is successful." A web browser window is automatically opened so they can complete the sign-in process in their SSO identity provider.  As soon as they sign in to their SSO identity provider in the provided web browser window, the CrashPlan app launches.

Lost access to an identity provider

If a user loses access to the identity provider, the CrashPlan app continues to back up, uninterrupted.

Troubleshoot authentication errors

Follow this procedure if SSO authentication for the CrashPlan app works externally but not internally, or if you see the following error In the AD FS event viewer: MSIS7102: Requested Authentication Method is not supported on the STS

Diagnosing

Search the AD FS logs to verify the error:

  1. Navigate to your AD FS event viewer.
  2. Search for the following log: MSIS7102: Requested Authentication Method is not supported on the STS

If you see the above error, continue to the solution described below to configure AD FS to use the proper authentication method with CrashPlan. 

Solution

Edit the Authentication Policies in AD FS: 

  1. Navigate to Authentication Policies.
  2. Under Primary Authentication, click Edit next to Global Settings.
  3. Under Intranet, enable both Forms Authentication and Windows Authentication.
  4. Click Apply.

Edit-global_authentication_policy-ADFS.png

Was this article helpful?
0 out of 0 found this helpful

Articles in this section

See more