How to provision users to Code42 from Okta
Who is this article for?
Incydr, yes.
CrashPlan for Enterprise, yes.
Code42 for Enterprise, yes.
CrashPlan for Small Business, no.
This article applies to Code42 cloud environments.
Overview
Provisioning automatically adds and deactivates users in your Code42 environment as well as assigns users roles and permissions. This article explains how to connect Okta provisioning and Code42. Once configured, Code42 automatically adds, updates, and removes users based on syncs from Okta to Code42.
This article assumes you are familiar with the concept of provisioning. To learn more, see our introduction to provisioning. If you want to add Okta as an authentication provider, see Configure Okta for SSO in your Code42 cloud environment.
Considerations
- To enable Okta's provisioning in Code42, your Okta environment must be licensed for the Lifecycle Management feature. If you are not licensed for the feature, you can still use Okta for authentication.
- Configure your private network, Internet, and VPN settings to allow client devices to communicate with your provisioning provider on port 443. Test client connectivity to the provisioning provider before you proceed.
- Local users cannot be created, updated, or deleted from the provisioning provider. These users can only be managed in the Code42 console.
User Provisioning
The following user provisioning features are available in the Code42 Okta application in the cloud. For more information on these provisioning features, see Okta's documentation.
Supported
- Create Users: New users created in Okta are also created in Code42
- Deactivate users: Deactivating the user in Okta deactivates the user in Code42
Note: For the Code42 application, deactivating a user means removing the user's account and placing the user's data into cold storage. Learn more about deactivating a user. By default, there is a 15 minute delay before Code42 deactivates a user. - Push groups: Adds groups and users from Okta to Code42
- Update user attributes: Okta updates users' profiles. Okta profile values overwrite any changes made in Code42.
Not Supported
- Import users from Code42 to Okta
- Password sync
Block, deauthorize, and deactivate users
There are a few special considerations when blocking, deauthorizing, and deactivating users.
- Blocking is a non-destructive action that prevents access to the Code42 app. A blocked user or device cannot sign in.
- Deauthorizing is a non-destructive action that simply signs a user out of a specific device. Users can sign in again at any time.
- Deactivating is a destructive action that removes a user from your Code42 environment. An active user can sign in again to a deactivated device, but a deactivated user cannot sign in. The user's archives on destinations are placed into cold storage for the configured cold storage period. Once the cold storage period has passed, the archive is permanently deleted.
Users on legal hold cannot be deactivated
If you place users under legal hold, the provisioning provider cannot deactivate them. Their data is retained for the legal hold process. Users are blocked instead of deactivated. Once your release users from legal hold, they are automatically deactivated.
Deactivation delay
When a provisioning provider sends an update to deactivate a user, Code42 waits 15 minutes before deactivating the user. This helps protect against moving users backup archives into cold storage if the users are accidently deactivated in the provisioning provider. You can adjust the delay time in the Code42 console. Note that the delay only applies when deactivating users using provisioning. When you manually deactivate users in the Code42 console, there is no delay.
Okta suspended state
You can suspend users via Okta. Suspended users cannot sign in to the Code42 console or Code42 apps on their devices. However, suspending users does not deauthorize them (sign them out of the Code42 app) if they are currently signed in. When you suspend users in Okta, you must go to the Code42 console and manually block those users. Blocking users signs them out, and prevents them from signing back in to the Code42 apps on their devices.
Before you begin
Step 1: Create Code42 organizations
Step 2: Add a provisioning provider in the Code42 console
Step 3: Add the Okta application for Code42
Do not assign people to Okta's Code42 application yet. First complete the organization mapping (Step 7) and role mapping (Step 8). If you assign people to the Code42 application before you configure mapping, Okta cannot automatically map users to Code42 organizations and roles.
Step 4: Configure Okta's provisioning tab
- In the Okta dashboard, select the Provisioning tab of the Code42 app.
- Click Configure API Integration.
- Select Enable API Integration.
- Enter the Base URL, Username, and Password generated from the Code42 console (Step 2).
- Click Test API Credentials.
A success message appears. - Click Save.
- Under Settings, click To App.
- Select Edit.
- Enable the following settings:
- Create Users
- Update User Attributes
- Deactivate User
- Click Save.
- Add additional attributes if needed in the Code42 Attribute Mappings section.
For example, if you use the Departing Employees list and would like to display employee information for the departing employees, you must first add the attributes to the Code42 app in Okta. (These attributes must be mapped to fields with valid values. For reference information about attribute mapping, see Okta's regex documentation or the SCIM specification.)- In the Provisioning tab of the Code42 app, scroll to the Code42 Attribute Mappings section.
- Click Go to Profile Editor.
- Click Add Attribute.
- Add the following supported attributes. After adding each one, click Save and Add Another.
-
Country
- Data type: country code
Country codes mapped to Code42 must be valid 2-character codes. To convert non-2 character codes to 2-character codes, see Okta's documentation. - Display name: Country
- Variable name: country
- External name: addresses.^[primary==true].country
- External namespace: urn:ietf:params:scim:schemas:core:2.0:User
- Data type: country code
-
Department
- Display name: Department
- Variable name: department
- External name: department
- External namespace: urn:ietf:params:scim:schemas:extension:enterprise:2.0:User
-
Division
- Display name: Division
- Variable name: division
- External name: division
- External namespace: urn:ietf:params:scim:schemas:extension:enterprise:2.0:User
- Locality
- Display name: Locality
- Variable name: locality
- External name: addresses.^[primary==true].locality
- External namespace: urn:ietf:params:scim:schemas:core:2.0:User
- Region
- Display name: Region
- Variable name: region
- External name: addresses.^[primary==true].region
- External namespace: urn:ietf:params:scim:schemas:core:2.0:User
-
Title
- Display name: Title
- Variable name: title
- External name: title
- External namespace: urn:ietf:params:scim:schemas:core:2.0:User
-
UserType
- Display name: UserType
- Variable name: usertype
- External name: usertype
- External namespace: urn:ietf:params:scim:schemas:core:2.0:User
-
- When finished adding the last attribute, click Save.
- While still in the Profile Editor, map an Okta value to each Code42 attribute by clicking Mappings and selecting Okta to Code42. When done, click Save Mappings.
Note the following:
- Username should be a syntactically valid email address value. Primary email should be a syntactically valid value identical to Username.
- Some Okta values may not have the same name as the Code42 attributes:
- Map the City value in Okta to the Locality attribute in Code42.
- Map the State value in Okta to the Region attribute in Code42.
-
Push attributes for existing users to Code42.
Use of the Manager attribute from Okta requires additional setup. To add the Manager attribute, contact your Customer Success Manager (CSM) to engage our Professional Services team.
(Optional) Step 5: Edit deactivation delay
Step 6: Push user groups from Okta to Code42
From the Okta dashboard, push user groups from Okta to Code42. See Okta's documentation for more details. If you are not using groups, continue to Step 7.
If you want to map SCIM groups to Code42 organizations in Step 7 or roles in Step 8, you must first push or provision SCIM groups and their users to Code42 so they are available in the Code42 console.
However, this means that initially the users are provisioned in the default organization and are assigned default roles rather than the ones you want to map them to. To move these users to the desired organizations and roles, ensure that you map SCIM groups to organizations (Step 7) and roles (Step 8) and then apply the mappings using the Apply Org and Role Settings action.
Step 7: Choose an organization mapping method
Step 8: Configure role mapping
Role mapping allows you to automatically assign Code42 roles and permissions to provisioned users based on their SCIM group. Learn more about Code42 roles and permissions. Users who are not mapped inherit the default roles for their organization.
Role Mapping is only available if you are using SCIM groups.
- Click Edit
to the right of Role Mapping.
The Edit Role Mapping dialog appears.
- To map SCIM groups, select Map SCIM groups to Code42 roles.
If you do not want to manage roles with SCIM groups, select Manually to manage roles in Code42. - Click Save.
An Add Mapping button appears under Role Mapping. - Click Add Mapping.
The Add Role Mapping dialog appears.
- Select a SCIM group from the dropdown.
Only groups that have not been mapped appear in the dropdown. - Choose one or more roles from the list to apply to this SCIM group. Learn more about Code42 roles and permissions.
Basic Code42 Roles
We recommend including the roles Desktop User and PROe User for all users who are backing up their computers to Code42. These roles allow users to sign in to the Code42 app and Code42 console. If you are giving external groups access to your Code42 environment (for example, outside legal council) they do not need these roles. - Click Add.
The role mapping appears under the provisioning provider detail. - Repeat until all of your SCIM groups have been mapped to Code42 organizations.
The message All SCIM groups are mapped appears.
There are no SCIM groups available
This message appears if SCIM groups have not been synced with the Code42 console. Push groups to the Code42 console to begin role mapping.
Do not assign people to the Code42 app in the provisioning provider yet. Wait until after you have completed the organization mapping and role mapping. If you assign people to the Code42 app before you configure mapping, the users are not automatically mapped to Code42 organizations and roles.
Step 9: Assign the Code42 application to users or groups in Okta
Users will not appear in Code42 until you assign them the Code42 app in Okta. We recommend creating a test user in Okta, and assigning the Code42 app to the test user before assigning the app to all users or groups. Once you assign the Code42 app to a user or group, Okta immediately syncs with Code42 and provisions the users.
See Okta's documentation for more information on assigning users and groups to applications.
Troubleshooting
Recommendations for troubleshooting provisioning:
- Once provisioning is configured in Code42, you should make all user changes in Okta. Code42 does not sync changes back to Okta, so any changes you make on the Code42 side causes the two apps to become out-of-sync.
- Updating the Code42 console does not start a sync between Okta and Code42. Only changes made in Okta can start a sync.
- To view more information about provisioning changes and logs, see the Sync Log in the Code42 console. It gives details of all of the users that have been created, updated, or deleted due to provisioning.
Contact our Customer Champions for Code42 for Enterprise support.