Keeper Teams allow you to share privileged accounts among pre-defined user groups
The purpose of creating teams is to give users the ability to share the records and folders within their vaults with logical groupings of individuals. The administrator simply creates the teams, sets any Team Restrictions (edit/viewing/sharing of passwords) and adds individual users to the team. Users can be added to teams either manually or using several different automated methods.
Teams can also be used to easily assign Roles to entire groups of users to ensure the consistency of enforcement policies across a collective group of individuals.
Navigate to the Teams tab and select the + Add Team button. Just like Roles, the teams will be added to the specific node that is selected. Enter the team name and click Add Team to save.
Select the team you would like to edit from the Teams tab. From here you can make edits to the team such as change the name, disable record re-shares, disable record edits, and apply privacy screens. You can also change the Node the team belongs to as well as add Users and Roles to the team. To delete the team, simply click the Delete button.
Teams can be configured with several restrictions that will override any folder-level permission settings.
With this restriction in place, passwords shared to this team cannot be re-shared by team members. This restriction will override any permissions set at the Shared Folder level.
With this restriction in place, passwords are usable and viewable but cannot be edited. This restriction will override any permissions set at the Shared Folder level.
Keeper's Privacy Screen feature gives you the ability to control the viewing (unmasking) of all passwords at the team level. With this policy in place, passwords are not visible from the user interface serving as a deterrent from casual observation. This feature is commonly used to limit viewing of passwords for the non-technically savvy users. It is important to note that password masking is only visual in nature and the password is still stored in the user's vault and accessible via API communication and browser inspection. Privacy Screen can also be configured at the role and website domain level in Keeper's Role Policies.
Watch the video below to learn more about the Privacy Screen feature.
Users can be added to teams several ways:
Manually through the Admin Console
Automated through the Keeper Bridge (for AD/LDAP)
Automated through SCIM provisioning (Azure, Okta, etc)
Automated through Keeper Commander CLI
Click the + Add User button to add users to a team.
If you would like to queue invited users into Keeper Teams, you can accomplish this using Keeper Commander's enterprise-team
command. In the example below, we are adding an invited user to a team. This shows in the "Queued User(s)" output.
Queued Teams and Users will be processed using one of the methods described in this page:
https://docs.keeper.io/enterprise-guide/user-and-team-provisioning/approval-queue
Teams can be provisioned in other ways as described in the Keeper Enterprise guide, including:
Keeper AD Bridge https://docs.keeper.io/keeper-bridge/
Automated Provisioning with SSO and SCIM https://docs.keeper.io/enterprise-guide/user-and-team-provisioning
Keeper Commander API https://docs.keeper.io/secrets-manager/commander-cli/overview
Teams and team-user assignments are accomplished through the use of public/private key encryption. Teams have a public/private key. Adding a user to a team involves encrypting the Team Key with the user's Public Key. When creating teams and assigning users to teams using the Admin Console interface, all of the encryption occurs locally because the Admin has the necessary rights and access to the keys required to perform the encryption actions.
Teams and team assignments created by automated methods such as the Keeper AD Bridge and SCIM API don't have the necessary encryption keys in order to fully create the assignments. Therefore, these teams and assignments go into a "queue" system.
Queued Teams and Team-User assignments are processed upon one of the following actions:
Admin logs into the Admin Console (and optionally clicks "Full Sync")
User from the respective team logs in to the Web Vault or Desktop App
Admin runs team-approve commands from Keeper Commander
Admin sets up the Keeper Automator service (version 3.0+)
SCIM and Commander APIs can be approved by following the instructions from the Approval Queue page.
If users are managed through SCIM or the Active Directory Bridge in a particular node within the Enterprise, we recommend performing all team management through the automated methods and the associated identity provider. Manually creating or editing teams from the Admin Console could interfere with your identity provider and generate syncing issues.