Basic
Overview
We're excited you have chosen Keeper to protect your business. This guide will provide valuable information on how to quickly onboard your employees and use the powerful features of the Keeper Administration Console.
Within this guide are screenshots of the Admin Console and the Web Vault. When demonstrating features and functionality within the end-user Vault, we focus all examples on the Web Vault, however most features are also available within Keeper's native mobile, tablet and desktop applications.
| Component | Description |
|---|---|
| Keeper Web Vault | Browser-based end user vault. Users login to the Web Vault to access and manage their passwords and private information. |
| Keeper Admin Console | Administrators and "Delegated Admin" roles with Administrative Permissions can login to the web-based console to manage their organization. |
| Cloud Security Vault | Keeper's backend cloud-based infrastructure hosted with Amazon AWS. Details on Keeper's security architecture included in this document. |
| AD Bridge | Windows application that connects to Active Directory or LDAP and synchronizes users, roles and teams with an existing organizational structure. |
| Native Mobile App | iOS, Android, Windows Phone, Surface applications available for download from their respective app store. |
| Native Desktop App | Windows, Mac & Linux desktop application. |
| Thin Client App | Web Vault application which does not provide offline access. |
The Keeper Admin Console
Customers who purchase Keeper for Business are provided administrative controls in a highly secure zero-knowledge architecture called the Admin Console. The Admin Console is a cloud-based application that provides full configuration and management of your Keeper for Business account including user onboarding, role-based enforcement policies, delegated administration, team creation, two-factor authentication and other advanced account settings.
Admin Console Link
Creating your Keeper Admin Console Account
After purchasing Keeper for Business (or upon launch of your Free Trial) you will receive an email invitation that contains a link to the Keeper Admin Console to complete your account profile. This Keeper account that you create will inherit the Keeper Administrator role. For this reason, we suggest that you chose a strong master password, security question and immediately enable Two-Factor Authentication from the Account Settings screen within the Vault or Admin Console.
Admin Tab
When you first login to the Admin Console it will bring you to the "Admin" tab. From here, you can access Nodes, Users, Roles, Teams, Keeper Bridge and License. On-screen guides will highlight the main functional area.
Planning your Keeper Rollout
Keeper is easy to deploy to your users in the organization, and our flexible tools provide many options in your rollout plans. To get started, we recommend that you consider the organizational structure of your Keeper account. The building blocks of Keeper's security model are Nodes, Users, Roles and Teams which are covered in detail throughout this document.
All users who join the organization's Keeper subscription will be responsible for managing their own encrypted vault. Their vault is protected by a self-chosen Master Password which is used to encrypt and decrypt the user's "data key" which is then used to encrypt their data.
We recommend separating your personal, private records from your business records by creating two separate user accounts. When enforcements are applied to the enterprise (such as Account Transfer privileges), users who have personal records mixed with business information risk having their personal information transferred.
When preparing for a rollout, you can consider one of the following options:
1. Manual invitation (One-by-one or CSV import)Organizations with a small number of users can simply add users manually through the Admin Console by clicking on the "Users" tab. Users will then be added to the Root Node. For a more advanced node structure, refer to the advanced section on nodes.
2. Keeper Bridge (for AD/LDAP integration)To provide larger organizations a more seamless onboarding and offboarding process Keeper has the ability to mirror and map the organizational structure in Active Directory / LDAP with the Keeper AD Bridge software. To download and authorize the Keeper Bridge, click on the "AD Bridge / SSO" tab within the Admin Console.
3. Keeper SSO ConnectFor organizations that currently use a SAML 2.0-compatible SSO identity provider (such as Okta, F5 Access Policy Manager, OneLogin, etc...), Keeper SSO Connect can be deployed as a SAML 2.0 service provider. Users on the SSO Connect platform do not need to manage their own master password, and onboarding is achieved dynamically upon successful SAML authentication. To set up and access the SSO Connect functionality, please contact your Keeper account manager at business.support@keepersecurity.com.
Users
To manually add a user, first select the node where the user will be placed (by default, users will be added to the Root Node). Click the “+” button and a “Add User” window will appear. Add the name of the user in the “Name” Field, the email address in the “Email Address” field, and select the “Add User” button. The email address will represent the user's Keeper user ID.
User Import
Users can also be imported via CSV file using the following format: Email, Address, Name, Role.
User Invitation
When users are added, they will receive an email invitation that contains an activation code and link to the Keeper Web Vault where they can complete their account registration. Any Keeper native app or web app can be used for account signup.
When a user accepts the invitation to Keeper, they choose their own Master Password, Security Question & Answer and optional Two-Factor Authentication method. If Two-Factor Authentication enforcements are turned on for their assigned role, the user will be forced to choose a method.
Searching for a User
In the Search Field, click on "Show Filter." Ensure the Users radio button is selected in the Filter and type the name of the user to be searched. Additional filter selections can be made on "Active," "Invited," "Locked" and "Disabled."
Editing/Making Changes to a User
Once the user has been added, the Administrator can edit or make changes to a user's profile. Select the user that you want to modify by clicking on the user. On the popup, you will see the fields that can be edited, such as Name, Roles, or Team.
User Status
Users can be in one of 4 states: Invited, Active, Locked, Blocked.
| Status | Description |
|---|---|
| INVITED | User has been invited to join Keeper but has not completed their account setup yet. User can be re-sent the invitation by clicking on the "Resend Invite" button. |
| ACTIVE | User has created their Keeper account and joined the organization. |
| User has been invited to join Keeper but has not completed their account setup yet. User can be re-sent the invitation by clicking on the "Resend Invite" button.5 | User has been invited to join Keeper but has not completed their account setup yet. User can be re-sent the invitation by clicking on the "Resend Invite" button.6 |
| LOCKED | User has been suspended (either manually by clicking on the Lock Account button or automatically via AD Bridge). To manually lock a user account, click on the "Lock" button. |
| BLOCKED | If Account Transfer enforcement policy is applied to the role which the user belongs, they have 7 days to accept the consent request that is presented to them from within their vault. If a user has not accepted the consent, their account will be blocked. Clicking the "Extend Transfer Acceptance Consent" icon will extend the time limit for another 7 days. |
User Actions
Additional user actions that can be performed from the "Users" screen. Icons only show if an action is relevant to that user's account.
 Edit a user |
Allow the change of a user's name. |
 Transfer Account |
If Account Transfer is active on the user's role and the currently logged-in administrator has the Administrative Permission to perform a transfer, this action will move all records and shared folders from the user's account to a destination user account. Account must first be locked before you can perform a transfer. After transfer is completed, the user account is deleted. More information on the Transfer Account action is detailed throughout this document. |
 Delete User |
Click the Trash Can Icon to delete a user account. Note: this action cannot be undone. All of this user's owned vault records will be immediately deleted, and they will be removed from all Roles, Nodes and Teams. |
 Lock Account |
To suspend an account to prevent the user from accessing their Vault, you can just lock the account by clicking on the Lock Icon. This retains the user's owned records but blocks their access to their Keeper Vault. Any records and Shared Folders created by that user will still be accessible to other shared users and teams. |
 Expire Master Password |
To expire a user's master password outside of the enforcement policy periodicity click on the master password expiration icon. This functionality allows the administrator to specifically target a user to rotate their master password if a potential compromise is suspected. |
 Extending Transfer Acceptance Consent |
If Account Transfer enforcement policy is applied to the role which the user belongs, they have 7 days to accept the consent request that is presented to them from within their vault. If a user has not accepted the consent, their account will be blocked. Clicking the "Extend Transfer Acceptance Consent" icon will extend the time limit for another 7 days. |
 User has been invited to join Keeper but has not completed their account setup yet. User can be re-sent the invitation by clicking on the "Resend Invite" button.7 |
User has been invited to join Keeper but has not completed their account setup yet. User can be re-sent the invitation by clicking on the "Resend Invite" button.8 |
Transferring a User's Account
IMPORTANT: Account Transfer is an optional feature that should be configured by the Keeper Administrator during the initial deployment phase of the Keeper rollout. The reason for this is because Account Transfer relies on the sharing of encryption keys between users that have rights to perform the transfer. The exchange of keys occurs when the user logs into their vault to retain Keeper's Zero Knowledge infrastructure. Therefore, the Account Transfer setup must be configured prior to the user's account being transferred. A successful transfer requires that the users had logged in at least once prior to the transfer action.
When an employee leaves the organization, an administrator with the proper Administrative Permissions can transfer a user's vault to another user within the organization. This account transfer functionality is an important and powerful way to take ownership of the content within user's vault while retaining a secure role-based hierarchy in the organization.
Setting up Account Transfer is described in detail in the "Account Transfer Functionality" section below. Account Transfer is configured with very specific paths based on the user's role. For example, an Engineer could only be transferred by the Engineering Manager, and the Engineering Manager's account can be transferred only by the CEO.
To perform an account transfer, first LOCK the user account which you will be transferring (this is to ensure that you don't transfer the account by accident). Then click on the Transfer button: Only active users which you currently have the rights to perform the transfer on will appear in the dialog. Select the user who will receive all of the records and click OK to perform the transfer. The user being transferred will be immediately deleted and their vault records are now owned by the new user, including any shared records & folders.
Roles
Roles provide the organization the ability to define enforcements based on a user's job responsibility as well as provide delegated administrative functions. By default the account registered to the Keeper for Business company profile is assigned the "Keeper Administrator" role underneath the "Root Node". Other users can be assigned this role as well.
The number of roles a business creates is a matter of preference and/or business need. At its simplest configuration the default role “Keeper Administrator” is applied to the initial administrator who set up the Keeper account for the organization as well as any other user who you wish to grant full admin rights. Roles can be assigned enforcement policies, and they can be assigned administrative permissions for access to the admin console. The creation of other roles is not required, but highly encouraged.
Adding Roles
You can add roles manually through the Admin Console or via Active Directory through the Keeper Bridge. To learn more about how to add users through Active Directory, please refer to our Keeper AD Bridge section in this guide.
To add roles manually, click on the "Roles" tab. Once on roles tab you can navigate to the specific node in which the role is to be part of. Click on the “+” button. An “Add Role” window will appear. Verify or select the appropriate Node in the organization tree (or set to Root Node). Add the name of the role you are creating in the “Role Name” field and click on save. After the role has been created, you can configure the role enforcement settings, select the users to assign the role and set administrative permissions.
Role Enforcement Settings
Click on the role that you want to configure enforcement settings for. The role dialog box will appear on the right. Now click on the “Enforcement Settings” button. The “Enforcement Setting” dialog box will appear. The settings are structured into seven different areas: Login Settings, Two-Factor Authentication, Platform Restrictions, Sharing & Uploading, Account Settings, Email Invites, and Advanced Settings.
Login Settings
User has been invited to join Keeper but has not completed their account setup yet. User can be re-sent the invitation by clicking on the "Resend Invite" button.9
On this screen you have the ability to configure the Master Password Complexity settings for users that are assigned the selected role. Settings include: password length, special characters, how many uppercase letters, and how many digits will be required.
Master Password Expiration
Turning on this policy will require users to change the master password at the selected time interval. When this option is turned on the “Master password expires every” option appears. To configure the number of days that the master password must be changed click the setting and choose one of the selections from 10 to 150 days.
Biometrics
iOS, Mac OS (Mac Store), Windows 10 (Microsoft Store) and Android platforms support fingerprint login. By default, all fingerprint logins are allowed.
Two Factor Authentication
Turning on this policy will require users to select and set up a 2FA method when setting up their Keeper profile. Existing users will be forced to enable 2FA if this enforcement is applied.
More information on DUO Security and RSA SecurID can be found here.
Platform Restriction
An admin can restrict the use of certain platforms (Web Vault, Extensions, Mobile and Desktop devices). By default all platforms are allowed.
Sharing & Uploading
Prevent record sharing outside of Keeper
Turning on this policy will ensure records are not shared with users outside of your organization.
Prevent record sharing with anyone
Enabling this option will prevent your users from sharing records with anyone.
Prevent exporting of records from Web App and Desktop App
This will prevent your users from exporting their data from their Keeper Web and Desktop Apps.
Prevent user from uploading files
When this is enabled, your users will not be able to upload any files (e.g. photos, documents, attachments) to their Keeper vault.
Account can be transferred to another user only by a specified role
When turned on, this enforcement allows a user's account encryption key to be shared with a selected role, such as the Keeper Administrator. The purpose of this enforcement is to provide "Account Transfer" functionality in which the user's vault can be transferred to another user within the organization in the future, if the employee leaves the company.
When the Account Transfer enforcement is turned on, you are presented with a list of users for which the account transfer operation can be performed. For example, you might want the Engineering Manager to be able to login to the Admin Console and transfer a developer's vault to a new employee if the developer leaves the company.
Account Settings
Restrict offline access
Turning this on will prevent users from accessing their Keeper vault without internet access. Toggle this on to enforce.
Restrict email change
Turning this on prevents users from changing their email address.
Automatic Backup
You can select how often your users backup their data to Keeper's Cloud Security Vault. Simply click the drop down menu to select how frequently you would like this to happen.
Restrictions Based on IP Address
Users within the specified role can be restricted from using Keeper outside of a specified IP address range. The IP address must be your external (public) address as seen by the Keeper infrastructure at the time of user login.
Logout Timer
Time limits can be set before a platform logs out the user. Time limits from 1, 2, 5, 10, and 30 minutes can be set on specific platforms.
Advanced Settings
PBKDF2 Minimum Iterations
The number of rounds performed during the client-side encryption login process. A higher value will increase your security but also increase your login time. Note that users may be required to install Keeper Desktop software locally on their computer in order to support higher iteration levels on Edge, Safari and Internet Explorer web browsers.
Role Enforcement Conflicts
If a user is a member of multiple roles with differing enforcements, all enforcements must be satisfied for all the roles she is a member of. For example: Role A does not allow sharing. Role B does not allow sharing outside of the Keeper Account. The user will be unable to share to anyone because Role A does not allow it.
Adding Users to a Role
Selecting the “+” button next to the User section within the Role settings will bring up a “Select User to Add to Role Name” window. This will allow you to search for users, in any node, and add them to the selected role.
Note: Only active users can be added to a role with any administrative privilege. If a user is still in the “invited” state, he or she must activate their account profile from the invitation email.
Teams
The purpose of creating teams is to have logical groupings of individuals for the ability to share folders within the Keeper Vault to collective group of individuals. The administrator simply creates the team, sets any Team Restrictions (edit/viewing/sharing of passwords), and adds the individual users to the team.
The administrator who creates the team is automatically added to the team in order to have the permissions to manage the team users and set the global settings on the team. Removing the admin from the group will orphan the group if there are no other users with the Administrative Permission to manage teams.
In summary: Nodes are organization containers, Roles define enforcement policies and grant admin permissions to users who are their members, and Teams are grouping of users for the purpose of seamlessly sharing records within the Keeper Vault.
Adding a Team
Navigate to the "Teams" tab and click on the “+” icon.
The “Add Team” window will appear and you can add the team name that you are creating. Just like Roles, the teams will get added to the specific node that is selected.
Editing Teams
Once the team is created, select the team name on the left, and in the right panel it will display editable options. The Team name, "disable record re-shares", "disable record edits", "disable viewing passwords", Node and Users can be configured. To delete a team, click on the trashcan icon.
Team Restrictions (Disable record edits, etc) are explained in detail below in the section titled "Team-Level Shared Folder Restrictions."
Hide Shared Folder
Clicking the "Hide Shared Folders" checkbox will hide Shared Folders which have been shared to this team for a particular user within the team. The purpose of this is to allow an admin to be a member of a team so that she can share the team encryption keys, but not have to receive the records associated with the team. This is not for security, since she could always click off the Hide Shared Folders, but rather for convenience so she doesn't get a lot of unwanted records in her vault.
Teams and Shared Folders
Shared Folders are created within the user's Vault. Team sharing provides a quick and easy way to share a folder from a user's vault to a group of users, without having to name each individual user. A Team can be provided specific permission on the folder (e.g. "Can Manage Records" or "Can Manage Users"). In the example from the Web Vault, the Shared Folder called "MySQL Databases" is shared with the Team called "Help Team" and it's also shared with an individual user.
User Permissions
There are 2 permissions available from the Shared Folder screen when adding users and teams, "Can Manage Records" and "Can Manage Users".
 |
Can Manage RecordsWhen this setting is checked, the user is able to add and remove records from the shared folder. |
 |
Can Manage UsersWhen this setting is checked, the user is able to add and remove other users & teams from the Shared Folder. |
Creating a Shared Folder
To create a Shared Folder (using the Web Vault for demonstration):
3. Give a unique Shared folder name (i.e. Marketing team - Social Media). In the "Users" tab select the Team or individual users. Select permission level of "Can Manage Records" and "Can Manage Users" based on your preference.
4. Click on the "Records" tab and search for the record titles (e.g. Twitter) that you would like to add to this folder.
5. Set the permission level for this record within the shared folder ("Can Share" or "Can Edit") based on your preference.
6. Click "Save" when finished. A dialog will appear that informs you of the changes made to the shared folder.
In summary, the below permissions can be applied from the Shared Folder level:
| Location Permission | Icon | Description |
|---|---|---|
| Users Tab: "Can Manage Records" | |
Users or teams added to the shared folder can add and remove records from the folder. |
| Users Tab: "Can Manage Users" | |
Users or teams added to the shared folder can add and remove other users and teams from the folder. |
| Records Tab: "Can Share" |  |
Users or teams added to the shared folder can share the individual records in a different shared folder or with another individual. |
| Records Tab: "Can Edit" |  |
Users or teams added to the shared folder can edit the record contents. |
Default Folder Settings
Any user with "manage" privileges can set default permissions to a shared folder under the "Default Folder Settings" screen. When a new user or record is added to the shared folder, the permissions selected will apply to all new entries. This feature is useful when large amounts of records or users are added that use the same permissions. Note: The owner or user with "manage" privileges can override the default settings.
Individual Record Sharing and Ownership
In addition to sharing an entire folder, users can easily share a vault record directly to another user. To share an individual record, click on the "Share" button and then select "Share with User".
Clicking "Share"
In the example, a record was shared from scottcasper@thecompany.com to blakejohnson@thecompany.com. The owner of the record is able to manipulate the permissions of other users who are directly shared to the record. Only the record owner can make these changes.
A record that already exists within a Shared Folder can be shared at the individual level, if the user is permitted based on the configured permissions of the shared folder and owner of the record (e.g. "Can share").
Transfer Record Ownership
In addition to sharing a record either as a stand alone entity or as part of a shared folder, a record can be transferred to a user making them the owner. Once ownership is transferred to another user, it will no longer be accessible from your vault.
To transfer ownership follow the following steps:
1. Highlight the record to be transferred.
4. Either select a user from recommendations or type in a user's email address. Check “Make Owner” and then click Send.
5. After clicking send confirm the transfer of the record to finalize the transfer by clicking “OK.”
Ownership and Deleting Records
Only the owner of a record is able to delete a record. A non-owner may see a "Delete" button but this will only remove the record from the non-owner's vault.
When the owner of a record deletes it from their vault, it will delete it from everyone's vault and across the system.
Moving Records Between Shared Folders
A record can be assigned to a single shared folder, moved between shared folders, or linked to multiple shared folders.
Moving a record from one shared folder to another can be accomplished from both the Web App as well as the Desktop App.
From within the Web App the steps are to un-assign the record from the existing shared folder and re-assign to the new folder.
1. Highlight the shared folder that record currently is linked to.
2. Click on the edit button to edit the shared folder properties.
3. Click on the Record tab of the Shared folder.
4. In the lower window, highlight the record to be removed and then click the trash can. (This does not delete the record, but rather remove it from the shared folder).
5. Click save to retain changes.
7. Click on folders edit icon.
8. Click on the record tab and then type in the name of the record you wish to add to the shared folder.
9. Assign the appropriate record permissions.
10. Click save.
Steps 6-10 can be repeated to add the record to as many shared folders as desired.
Vault Backup and Recovery
A user's encrypted vault is synchronized via the Keeper Cloud Security Vault to ensure the contents of their vault are always accessible from any client (web app, desktop app, mobile app), in essence being backed up all the time. To add an additional layer of protection, backups can be performed on a routine basis to empower the end user to perform a restore from a snapshot in time.
As part of a role enforcement policy, the interval to which prompted backups are required for the end user can be configured by the Keeper Administrator in the admin console.
We recommend setting a the automatic backup time to no less than 10 days, because users will be interrupted in their workflow to create the backup on the web-based applications.
The steps to perform a backup are as follows:
1. The user will log into their vault and will be prompted for a backup.
2. The user fills out the fields: Title/Description, Security Question, and Answer.
3. Once completed the user will click on the “Backup Now” button.
4. The the user will receive success notification on screen.
The steps to perform a restore:
1. Within the Web App, click on the backup icon.
2. On the Cloud Backup & Restore window click on the “Restore Now” button.
3. On the Cloud Data Restore window, click the “Send Verification” button to send the verification code to the email address used for backup.
4. In the email that was sent copy the verification code.
5. Paste the code received in the email into the Cloud Data Restore window and click proceed.
6. Select the backup snapshot you wish to restore.
7. Answer the question that was selected/created in the backup process and click “Restore Now."
Important Restore Considerations
The backup and restore functionality of Keeper is a full vault restore - all records are replaced by the records contained in the backup file for the records owned by the user performing the restore. This will have consequences on the workflow in the organization due to the fact that outgoing shares (both direct shares and records in Shared Folders) will be removed by the restore action. Shared records will need to be re-shared by the user who performed the restore to the designated users and Shared Folders.
詳細設定
Nodes and Organizational Structure
Nodes are a way to organize your users into distinct groupings, similarly to organizational units in Active Directory. The administrator can create nodes based on location, department, division or any other structure that makes sense. By default, the top-level node, or "Root Node" is set to the organization name, and all Nodes can be created underneath.
Nodes are not visible or configurable by default. To activate the Node configuration, click on "Advanced Configuration" and then enable "Show Node Structure". If you do not require organizational units leave this feature turned off.
Smaller organizations might choose to administer keeper as single level, meaning no additional nodes are created by the Keeper Administrator. In this scenario, all provisioned users, roles, and teams are accessed from the default Root Node. The advantage to this configuration is there is no additional navigation required to find objects as they are listed under the default root level and easily accessed by navigating to the appropriate tab (user, role, teams).
Larger organizations may find benefit in organizing locations or departments into organizational containers called "Nodes". Users can then be provisioned under their perspective node and have roles configured to match the specific needs of the business. One of the advantages in defining nodes is help support the concept of delegated admins. A delegated administrator can be granted some or all of the Administrative permissions but only on their perspective node (or sub nodes) to help reduce administration from the primary Keeper Administrators.
When the Keeper Bridge is installed for Active Directory synchronization, AD Organizational Units are identified as Nodes. Users and security groups within specific organizational units in Active Directory will be placed in the corresponding Node in the Keeper Admin Console.
Adding Nodes Manually
To manually create Nodes and Sub Nodes, click the “+” button. The “Add Node” window will appear. Type the name of the Node in the “Node Name” field and select the node where you want the new node to be added in the tree structure.
Nodes and Administrative Permissions
If nodes are enabled either via Active Directory integration or configured from the Admin Console, the placement of the role is important with regards to where the administration permissions begin.
Placement of the role at the top level, “AD Root” will allow the permissions to flow down to any of the sub-nodes if the “Cascade Node Permissions” attribute is checked. If the role is placed in the “Sacramento” node, with the “Cascade Node Permissions” attribute checked then the permissions apply to that node and its two sub-nodes but not to the “East Coast” node. If the “Cascade Node Permissions” attribute was not checked in the above examples then the role permissions is only applied the the specific node to which it belongs.
Team-Level Shared Folder Restrictions
Restrictions set at the team-level from within the Admin Console take precedence over the permissions set at the folder level within the vault. In addition to Shared Folder permissions, there are additional restrictions that can be applied at the Team level from within the Admin Console.
To access the team-Level shared folder restrictions, click on the Team. In this example, the "Sacramento" team is unable to share, edit or view the passwords (e.g. password masking is turned on).
| Restriction | Description |
|---|---|
| Disable record re-shares | Teams added to a shared folder with this restriction will not be able to share the records to other folders or users. |
| Disable record edits | Teams added to a shared folder with this restriction will not be able to edit the records. |
| Disable viewing passwords | Teams added to a shared folder with this restriction will not be able to view passwords (it will be starred out). However, the password will be usable for auto-filling into websites and apps. This feature is called "Password Masking." |
| Hide shared folders | Just for the selected user, this will hide any shared folders that are shared to the team. |
Team restrictions only apply to records shared via the team to a user. For instance, if a user is a member of two teams, and those teams are a member of the same shared folder. If one team has “Restrict Editing” enabled, but the other does not, and a record in the shared folder has edit permissions, then the user CAN edit the record. But if the team with the restriction was the only member of the shared folder, or the user was not a member of the team without the restriction, then she would be unable to edit the record. If a record was shared to the user not via a team (direct share, or the user is a direct member of the shared folder), then the permissions granted via the share apply and no restrictions override those permissions because the permissions were not granted via a team.
Masked Passwords
A popular use case for Team-level restrictions is to allow users ability to "use" a password without seeing or being able to copy the password. For example, it may be desired to share the company social media login information to the marketing team for posting content on behalf of the business, but mask the password to deter users from recording the password outside of the Keeper vault. This functionality can be set up with the use of the "Disable viewing passwords" Restriction.
Users will be able to use the record in conjunction with the browser extension to facilitate the login of the account. However, they will not have the capability of viewing or copying the password from the password field from either the vault or the browser extension.
Delegated Admin via "Administrative Permissions"
A role can be given Administrative permissions over the node (or sub-nodes) for which a role exists. This delegated administration allows different roles to have different permissions inside of the Admin Console.
An example of a role that can be created would be a “Delegated Admin" role. In this role the administrator can set up one or more Administrative Permissions that allow that user in the role to login to the Keeper Admin Console and perform administrative functions. For example, the delegated admin can be given permission to create teams, add users, create or edit roles, run reports and perform account transfers. These permissions can be limited to a single node or they can cascade or traverse down the tree structure to all the sub-nodes. In order to have the role applied to multiple nodes, simply click the + button after “Administrative Permissions” (see below) and add the node the role will manage. Each node a role manages has its own set of permissions and those permissions can cascade down from that node. For example: If the role was created in the top root level node and the there were three other nodes created each under the top level node. The Administrative Permission can be added as the top node, the privileges added, and “cascade node permissions” selected. This would then give those permissions to all 4 nodes to members of that role.
1. To give Administrative Permissions to a Role, click on the “+” button on the Role screen.
2. Select a node from the breadcrumb trail. Click on Save.
3. Click on the gear next to the node you added.
When "Cascade Node Permissions" is selected, the permissions will be applied to all sub-nodes of the parent node. It is important to note that Administrative Permissions cannot be added to a Role if one or more of its users are still in the "INVITED" status.
When "Cascade Node Permissions" is selected, the permissions will be applied to all sub-nodes of the parent node. It is important to note that Administrative Permissions cannot be added to a Role if one or more of its users are still in the "INVITED" status.
| Manage Users | The ability to add, remove, or edit users. |
| Manage Nodes | The ability to add, remove, or edit nodes. |
| Manage Licenses | The ability to manage and upgrade the organization's license capacity. |
| Manage Roles | The ability to add, remove, or edit roles. |
| Manage Teams | The ability to add, remove, or configure the Enterprise Bridge settings. |
| Manage Bridge | The ability to add, remove, or configure the Enterprise Bridge settings. |
| Run Reports | The ability to run and configure reports on usages within the admin console. |
| View Tree | The ability to see the node structure. |
| Transfer Account | The ability to transfer a user's vault. Note: Only administrators who are a member of this role are able to check that box. If needed, you can add yourself to the role or another administrator within the role can set this permission. Once this box is selected, only members of this role can add members to this role. |
Administrative Permission versus Role Enforcements
Both Administrative permissions and enforcements are configurable from within a role. "Enforcements" are rules or policies that apply to the end user's Vault experience and security. "Administrative Permissions" grant rights to perform certain actions within the admin console (also known as "delegated administration").
We recommend that only specific roles are given Administrative Permission, and the permission level should be based on the least amount of privilege required by that role.
For example, the default Keeper Administrator may have created a role called “Users” specifically to handle the policies that are desired for all the users that have been onboarded to the Keeper platform. If one of those users are intended to be able to perform some of the administrative permissions it wouldn't make sense to configure the “Users” role with the additional entitlements for that one user as it would be applied to all the users and not congruent with a least privilege security model. So instead of editing the “Users” role to add in additional administrative permissions, it would make the most sense to create a new role called “Delegated Admin”, grant the administrative permissions, and make the user a member of that role.
2 段階認証
Two-Factor Authentication (aka "2FA") is a powerful feature built into the Keeper ecosystem for protecting access to your account by using a second factor in addition to your Master Password. Keeper's 2FA technology is fully integrated across web, mobile and desktop applications. Keeper supports multiple methods of 2FA including Text Message, Google Authenticator, Duo Security, RSA SecurID and Keeper DNA (using Apple Watch and Android Wear devices). Each user is able to individually configure their Two-Factor Authentication settings from their vault 'Settings' screen. Certain 2FA methods such as Duo Security and RSA SecurID require the Keeper administrator to login to the Admin Console and perform some up-front configuration.
Duo Security
To activate Duo Security, follow the below steps:
1. Make an account and login to Duo.com. Select “Applications” on the left side menu list.
2. Click "Protect An Application" to bring up a list of applications. Then select "Keeper Security" from the list.
3. Copy the provided credentials from Duo's website (including the Secret Key which needs to be clicked on to view)
4. Return to Keeper's admin console and click on the 2FA tab. Click on the gear icon under Duo and paste in the info copied information from Duo's site. Slide the switch to enable and click save.
Once activated, each individual user can enroll in Duo by logging into their Keeper app and going to Keeper's "Settings" or "DNA" screen, select "One-Time Passcodes" (or Two-Factor Authentication) and selecting Duo Security. User is walked through a process to activate their device.
RSA SecurID
To enable RSA SecurID, additional customer integration points are necessary. Please contact your Keeper account manager to initiate this integration.
Text Message
Keeper supports Text Message (SMS) delivery of two-factor authentication codes. To select Text Message method, visit the "Settings" or "DNA" screens within the Web App or Mobile App.
Google/Microsoft Authenticator (TOTP)
Keeper supports Google Authenticator (and any compatible one-time-passcode generator) as a two-factor authentication method.
Download the Google Authenticator or compatible application on your mobile device and add a new entry by scanning the barcode Keeper provides.
Keeper DNA
Keeper DNA uses the connected devices you own to create your unique profile which serves as a second factor to verify your identity and log you in. Keeper supports Apple Watch and Android Wear devices. To enable Keeper DNA 2FA method, visit the "DNA" screen on your iPhone or Android app.
Existing Password Migration into Keeper
Customers with existing password records can import them into the Keeper vault through the Desktop App or Web Vault.
Before importing data, we recommend that you consider the organizational structure as instructed throughout this document. Nodes, Users, Roles and Teams should be configured prior to importing password records.
The "Import" feature of the Keeper Web App can be used to import records into the vault from a CSV file. The records will be "owned" by the user who performed the import. Records can be imported directly into the user's vault without being shared, or they can be directly imported into Shared Folders. The fields that are supported by the CSV import are as follows:
1. Folder - This is the personal folder name (not a Shared Folder)
2. Title - Title of the record, e.g. “My Bank Website”
3. Login - Email or username
4. Password - The password you used for the specific account
5. Login URL - e.g. “https://mybankwebsite.com” - this field is used by KeeperFill functionality
6. Notes - Custom written notes by the user
6. Notes - Custom written notes by the user
7. Shared Folder Name - This is for importing directly into Shared Folders (existing or new)
8. Custom Field Name/Value Pairs - Did the record have a custom field? This is where it goes.
Select the same mapping for multiple columns to merge fields. You can also ignore columns from import. After 7 columns, each additional 2 columns will be mapped as custom name/value field pairs.
You can specify sharing and edit permissions for "Shared Folder" by appending #yes or #no tags to the Shared Folder Name, for example: My Shared Folder#no#yes will add the record to "My Shared Folder" with a permission to edit.
Prepare your file in CSV format. An example file is below:
Login to the Web App then Click on "Import."
If you are importing directly from another password manager or web browser, choose the format and follow the instructions to retrieve the import file.
Drag and Drop the file into the Web App screen as indicated. You will get a list of field mappings. Make sure to align the field with the proper column.
After the mapping is completed, click on "Import". In the example, two shared folders were created with specific edit and share permissions, and the records were added to those shared folders. Once the import is completed, you can assign records to shared folders manually through the vault user interface.
Account Transfer Functionality - Employee offboarding
The Account Transfer function was developed to give businesses the ability to recover passwords and files that are stored in a user's vault that otherwise would be abandoned if that user was unable or unwilling to access their vault.
When to Enable Account Transfer
By default the Account Transfer permission is off. The Keeper Business administrator can optionally turn on the permission which permits the ability to take the contents of a user's vault and transfer it to another user. One important note is that this permission will need to be enabled prior to the need of using it. For example, if “User A” has a password that gains access to a business essential application or account in their vault that no one else in the organization has access to, and “User A”, for any number of reasons is no longer able to authenticate to their vault, the business may find they are left in a tough situation to recover access. However, if the Account Transfer permission had been enabled in the default “Keeper Administrator” role (and any other role that is desired to have the permission to transfer capability) and applied to the role that “User A” is a member of, the Keeper Administrator would have the ability to transfer the full contents of “User A's” vault to another user.
Why is the initial setup required?
When the decision is made to enable the Account Transfer feature on a particular role, all the users that are a member of that role will be subjected to the possibility of having the entire contents of their vault transferred and their account deleted at will by the Keeper Administrator. After the enforcement setting is enabled, the users within the managed role will receive a pop up message inside of their vault informing them that the business has chosen to enable the capability of transferring their vault if needed. Each user will need to Accept that consent notification. Upon acceptance, Keeper performs the necessary encryption key exchange between users and roles to facilitate the data transfer in the future, if needed. Without this encryption key exchange, the user within the Admin Console would be unable to decrypt and transfer the data. The reason for this process flow is to maintain zero knowledge, and to also ensure that only specified users are able to be transferred or perform the transfer. Once the vault has been transferred to another user, the transferred user's vault is deleted.
Will the administrator have full access to a user's vault?
No. While the Account Transfer feature does give the administrator the ability to migrate the entire contents to another user, it does not give the admin the capability to access the vault whenever they feel like it. The vault being transferred has to be locked first and after the contents are transferred the account gets deleted. The end user will receive notification when their account is locked by the admin and when it's transferred and deleted.
How to Enable Account Transfer Functionality
"Account Transfer" functionality must be enabled and the user must login to their vault (and accept the account sharing consent) prior to performing a transfer by an administrator. Below are the steps that must be performed.
1. Enable the Transfer Account in the Administrative Permissions of the role that will have to ability to initiate the account transfer.
Note: If the "Transfer Account" checkbox cannot be checked, it is because the user must be logged into an account that is a member of the role, like the default Keeper Administrator, that has the “Transfer Account” permission enabled.
Simply add yourself to the role by clicking the plus button. After you are added to the role, you will be able to select the "Transfer Account" permission on that role. A role (e.g. the Keeper Administrator role) must have the permission enabled before any other role can be granted transfer account permission.
Performing an Account Transfer
1. Lock the account of the user by clicking on the lock icon inside user's configuration panel (The configured admin will only have the ability to transfer records from a locked user).
2. The administrator will click the transfer icon inside user's configuration panel. A window will open with a list of users. Select the user that will receive the transfer of records and click OK.
3. The user's account is transferred and their account is permanently deleted.
Keeper Bridge
Keeper Bridge allows businesses running Microsoft Active Directory to integrate Keeper password management software within their current systems, automatically adding any number of Nodes (organizational units), Users, Roles and Teams to Keeper.
Keeper Bridge is designed to use the Lightweight Directory Access Protocol (LDAP and LDAPS) to communicate with LDAP based Directory Services for the purpose of onboarding and offboarding users to the Keeper platform.
Overview
Keeper Bridge consists of a tray application and a windows service. The tray application allows the user to configure settings specific to the Directory Service and also functions as a service controller allowing the user to adjust LDAP Filter settings and publish to the service for updates.
The windows service is designed to Poll the Active Directory Tree for Nodes, Roles, Teams and Users, providing a familiar structure for Role, Team and User management within the Keeper Admin Console and inviting users to join Keeper. The Polling Interval can be configured from 5 to 1440 minutes. The Tray Application can be installed on multiple systems for use by multiple admins. The service must be installed only on one host system per Keeper Bridge instance. All tray applications access the single instance of the service.
Prerequisites
4. Windows Server 2016
Note: The Domain functional level must be at Windows 2008 R2 or higher in order for the bridge to properly integrate.
The following data needs to be known in order to configure the Tray Application:
1. Domain or Forest name of the Active Directory
2. An account used to bind the Keeper Bridge to Active Directory (e.g. keeperbind@yourcompany.com ). This is an Active Directory account which requires at least read only access to the Active Directory domain. No other special privileges are needed.
3. A Security Group called “Keeper Admins”. Only users that are member of the “Keeper Admins” Security group will be permitted to login to the Tray application and configure the service. This group name can be changed and the Admin Security Group setting in the Keeper Admin Security configuration modified accordingly later. For a multi-domain forest create this group as a universal group so that users in this group are cached in the Global Catalog.
4. Ensure the Email Property (typically “mail” or “userPrincipalName”) in Directory Service Options is set to the correct value to pick up the user's Email address.
AD Bridge on the Admin Console
1. Before installing the executable on the server, the Admin console will need to be prepared to register the Keeper Bridge. The bridge cannot be registered to the Root Node (top level) of the organization tree structure, therefore a sub node will need to be created in order to register the bridge. To enable the Node structure, click on the "Advanced Configuration" at the bottom of the console. Turn the "Show Node Structure" to the on position.
2. Once the Node Structure is enabled, create a new node underneath the Root Node of the organization by clicking the + symbol to bring up the Add Node window.
3. Type in the name of the Active Directory node and click create.
4. Select the node created in step 3 above. In the below example, the node name is called "AD Root."
5. Select the "AD Bridge / SSO" tab and Click on the "+ Bridge Connection" button.
6. Verify the status is “Pending”
7. The Keeper Bridge executable can be downloaded from the "AD Bridge" panel and staged on the computer that the bridge will be installed on.
Note: Recommend the Bridge be installed on a member server located on the same network as a domain controller. A domain controller can be used in lieu of member server.
Keeper Bridge Server Installation
2. Process the UAC window.
3. On the Select Setup Language screen choose your language and click next.
4. Choose “I accept the agreement” and click “Next” on the Setup - Keeper Bridge screen.
5. Either choose the default installation location or browse for a new one and then click “Next”. Installing in Program Files is recommended.
6. Select the Components that are going to be installed on the computer. The Keeper Bridge Client can be installed on multiple computers but the Keeper Bridge Service should only be installed on one computer.
7. If desired, check the create a desktop shortcut and Run application after install and click Next.
8. On the Ready Screen click “Install."
9. Click Finish to complete the installation.
Configure The Bridge Client
1. Run the Bridge Client.
2. Log into the Bridge application:
a. Domain\User Name : Input the domain and AD\LDAP username of the user that is a member of the “Keeper Admins” group created in the prerequisites.
b. Password : Input the password of the user.
c. Use Global Catalog: In multi-domain forest configurations you should uncheck “Use Global Catalog” option other wise keep it check to locate the username in the Global Catalog.
d. SSL : If using Secure Socket Layer (SSL port 636) for LDAP authentication ensure the SSL box is check. If not, ensure the check box is not checked to use standard LDAP authentication (port 389)
e. Settings : If the client is running on a different computer than the service, select Settings to specify the hostname and port of the Keeper Bridge Service.
3. Select Login. If you get a Login Failed message, it means either of the following:
a. The username/password is not correct
b. The user is not a member of the Keeper Admins Security Group
c. The server does not support SSL and SSL is checked
d. The username was not found in the Global Catalog. In multi-domain forest configurations if the Keeper Admins group is a Global Security Group the “Use Global Catalog” option should be unchecked or the Keeper Admins group can be made to be a Universal Security Group. In a multi-domain forest only users in Universal Groups are added to the Global Catalog.
Bridge Client Configuration
If login is successful, the bridge application will launch.
1. On the Connections tab fill in the following information:
a. Domain Name: The domain that the bind account is part of in Active Directory.
b. LDAP Port: Check SSL for port 636 or unchecked for port 389.
c. User Name: Input the username of the bind account (as recommended in the prereqs).
d. Password: the password of the bind user account.
2. Click "Test Connection" to validate the AD bind.
If test was successful, the next step is to retain the settings by clicking the "Save" button at the bottom of the "Connections" tab.
Under Connection Status, Directory Services, changes color to Green and displays "Online."
Register Bridge with Keeper
1. On the Keeper Bridge client, click Register on the Keeper Bridge section. This will prompt the user to log in with the Admin‘s email address and password.
2. After authentication, the Bridge Registration window will appear. Select the Bridge Node and click "Apply.”
3. Once the Keeper Bridge is registered the Keeper Cloud Status will be green and "Online.”
Configure Options
Before proceeding with LDAP/AD configuration, please click on the "Options" tab of the AD Bridge to ensure that the "Email Property" is set correctly according to your organization's environment. This will ensure that the proper Keeper email maps to the organization email address.
To assist in the monitoring of events in AD Bridge during the testing and configuration phase, we recommend enabling the Logging feature:
To open the logging window, right-click the Tray Icon in the right hand corner of your screen, then click on "Show Log."
The Bridge Log window will open. When activity in the AD Bridge is activated from clicking "Publish" you will start to see the logging information.
Configure LDAP/AD Domains
Once the connection status is Online for the Keeper Service and Directory Service, configure the domains which will be exported to the Keeper Admin Console. Click on the "LDAP/AD" tab and then select either the "Export Forest" option or select individual domains.
When making changes to this screen, you'll notice the "Publish Required" on the bottom right corner of the screen. We recommend that you do NOT publish the changes until you have completed all steps in this guide and that you also verify that the "Options" screen is fully Configured.
Export Forest
Using the "Export Forest" option includes all domains for which the user defined in "LDAP Connection" settings is a member. Selecting Export Forest will automatically select the root forest domain and enable that domain. All other domains will not be visible. When "Export Forest" is selected all domain object queries are done using Global Catalog. The "Top Level Node" is not editable when using this option.
Selecting Individual Domains for Export
Checking the box for any domain enables that domain for export, Top Level Node and Filters become editable for that domain. Selecting the row will display the top level node and filters for that domain.
The "Top Level Node" filters is the DN path that will filter all objects from that path downwards. For example, a top level node might be:
Note: It is recommended to use this Top Level Node for initial rollout to test your configuration and limit the scope of the deployment to a small number of users.
Domain Filters
A variety of filters are available to enable admins to map specific objects from Active Directory to Nodes, Roles, Teams and Users which can then be Managed by the Keeper Admin Console. It is important to understand what the individual filters do and how to apply them. Each domain can configure a Top Level Node which defines the root object where all filters will be applied. Each domain enabled can then set a Node filter, a Role filter, a Team filter and a User filter. These filters are used to define the objects which will be exported to the Keeper Admin Console.
Top Level Node
The Top Level Node can be set to a Distinguished Name path at any point in the Domain Tree. All applied filters will start from this path. As the name implies the DN Path defined becomes the Root of the organization in the Keeper Admin Console allow the Admin to define which portion of the tree to export. If the whole domain tree is to be exported the Top Level Node should be left undefined.
Domain Filters - Node
Nodes define the Tree in the Keeper Admin Console. This provides a familiar organizational structure when managing Roles, Teams and Users. The default filter defined for all domains will map all Organizational Units with the exception of the Domain Controllers OU. Using standard LDAP filter syntax the OUs map can be reduced or additional objects such as containers could be mapped if necessary.
Domain Filters - Role
Roles provide the organization the ability to define enforcement policies for Users grouped in Roles. Having a large number of roles will require more maintenance than having only a few roles. The organization should plan how enforcements will be applied and how many Roles will be required to manage those enforcements. For this reason the default role filter is left blank.
By default all Users will be mapped to a default role when they create their account. This default role is visible in the Admin Console and is not part of AD.
See "Filter Examples" section for example Role filters if additional Roles are to be defined based on specific security groups. When defining a Role filter only the objects mapped which are present in the Nodes mapped by the Node Filter will be returned.
Domain Filters - Team
Teams provide the ability to share folders within the Keeper Vault to a collective group of individuals. By default the Team filter maps all security groups to Teams which are present in the Nodes mapped by the Node filter. When Teams are exported to the Admin Console they are not distributed to their home location in the Node tree as they are in Active Directory. All Teams are distributed to the Bridge node where the Bridge was created. This keeps all Teams within sharing scope of each other. Teams can then be manually distributed in the Admin Console so as to only allow sharing between certain teams.
Domain Filters - User
The primary function of the Keeper Bridge is to onboard users by sending them an invitation to join the Keeper account. The default filter returns all user objects which are present in the Nodes mapped by the Node filter. The AD Bridge exports users while also maintaining the Role and Team membership status. The AD Bridge will Lock a user's account when the User account has been disabled in AD. If an Active User is removed from the Role filter, the user account is locked, pending deletion by the Keeper Administrator.
Default Filters
Default filters are provided which are expected to work for most organizations. Only the Role filter should need modification in a basic implementation. The Node filter maps Organizational Units to Nodes which are used by the Keeper Admin Console to provide a familiar tree structure.
Default Node Filter
The default node filter maps objects with objectClass organizationalUnit. In Active Directory Domain Controllers is an organizationalUnit but there is no benefit to mapping this object.
(&
(objectclass=organizationalunit)
(!name=Domain Controllers)
)
Default Role Filter
The Default role filter is blank. In order to manage user enforcements users must be grouped into Roles. Each Role must be configured in the keeper Admin Console to set enforcements for the specific User Role. It is suggested that some Security Groups in Active Directory are mapped as roles containing the users which will be joining the keeper organization. For maintenance reasons it is suggested that a select number of groups are used for this purpose. Mapping a large number of Role will require more configuration on the part of the keeper Admin. See custom filter for an example on how to add a role.
Default Team Filter
The default Team filter maps all security groups to Teams. This allows all members of the organization to share records between teams. The objectClass specifies group type object and (using an AND operator: &) any one of (using an OR operator: |) the group types Local, Global or Universal.
(&
(objectclass=group)
(|
(grouptype=-2147483640)
(grouptype=-2147483644)
(grouptype=-2147483646)
)
)
Default User Filter
The default user filter maps all user objects. In Active Directory some objects such as domain controllers also have an objectClass of User. To get only User objects an additional parameter is added, (with an AND operator: &) objectCategory of Person.
(&
(objectclass=user)
(objectCategory=Person)
)
Custom Filters - Examples
Each filter is defaulted so that most organizations can easily export their domain structure and map objects to Nodes, Roles, Teams and Users. In many cases filters will need to be customized to meet the needs of some organizations. If an Organizational Unit is not mapped as a Node, all objects in that OU path will not be exported even if the Filter for the object type maps the object.
Custom Node Filters
Example to map all Organizational Units as Nodes and excludes the specific OUs “Office Users” and “Home Users”. In the example below the OUs “Office Users” and “Home Users” and all objects within them will not be mapped even if other filters (Role, Team, User) target the objects within these OUs.
Example to map only specific Organizational Units as Nodes. Only “Office Users” and “Home Users” are mapped as Nodes. When including specific nodes the grouping with the OR (|) operator is necessary. In the example below only the OUs “Home Users” and “Office Users” and objects within them if targeted by other filters (Role, Team, User) will be exported.
An important rule with Node Filtering is that if the OU is not exported, all objects targeted by other filters (Role, Team, User) within the OU will not be exported.
(&
(objectclass=organizationalunit)
(!name=Domain Controllers)
(!ou=Office Users)
(!ou=Home Users)
)
(&
(objectclass=organizationalunit)
(!name=Domain Controllers)
(|
(ou=Office Users)
(ou=Home Users)
)
)
Custom Role Filters
Roles are required to apply enforcements on the Users in the Keeper organization. By default the filter is blank. Since the Active Directory names for groups are specific to the organization a default filter cannot be supplied. It will be necessary to decide which Security Groups in Active Directory will be used as roles.
If all Security Groups are to be mapped as roles then copying the default Team filter is an easy way to export all groups as Roles. This means the Admin will need to manage each group as a Role and each Group as a Team. Maintenance on many Roles can be unnecessary and a time consuming for the keeper Admin. In this case only one or a few roles may be necessary.
Example mapping all Security Groups as Roles and excluding the specific groups “Local Admins” and “Regional Admins”.
Example mapping only specific Security Groups as Roles. This example groups “Local Admins” and “Regional Admins” with an OR (|) operator when including only specific groups.
An important rule with Role filtering is that if a group the user is in is not exported the user will still be exported, just not assigned to the Role.
(&
(objectclass=group)
(!CN=Local Admins)
(!CN=Regional Admins)
(|
(grouptype=-2147483640)
(grouptype=-2147483644)
(grouptype=-2147483646)
)
)
(&
(objectclass=group)
(|
(CN=Keeper Admins)
(CN=Keeper Users)
)
(|
(grouptype=-2147483640)
(grouptype=-2147483644)
(grouptype=-2147483646)
)
)
Custom Team Filters
Teams are required to share folders and records to other Users in the keeper organization. By default the Team filter maps all security groups to Teams. Roles and Team filters act on security groups. It is valid that some groups would be mapped as both a Role and a Team. For instance an Organization may have LA Admins and LA Users mapped as Roles and then also have all security groups mapped as teams. This would mean LA Admin and LA Users are also a team.
Since Roles also act as team please refer to roles for custom filtering examples.
Custom User Filters
The User filter maps User objects in Active Directory. If the user is a member of a security groups which is mapped as a role or team the Bridge will Invite the user and assign them to Roles and Teams of which they are a member based on the Active Directory group membership.
Example mapping all Users in Active Directory except specific users. User52 and User58 are excluded by Common Name.
Example mapping only specific Users in Active Directory. User52 and User58 are included exclusively by Common Name.
(&
(objectclass=user)
(objectCategory=Person)
(!CN=Regional Admins)
(!cn=User52)
(!cn=User58)
)
(&
(objectclass=user)
(objectCategory=Person)
(|
(cn=User52)
(cn=User58)
)
)
Example mapping all Users in Active Directory which are part of specific groups. Members of the “RDP Users” & “Office Admins” group are included.
(&
(objectclass=user)
(objectCategory=Person)
(|
(memberOf=CN=RDP Users,OU=Office Users,DC=keeper,DC=local)
(memberOf=CN=Console Users,OU=Office Users,DC=keeper,DC=local)
)
)
Example mapping all Users in Active Directory except users which are part of a specific group. Members of the “RDP Users” and “Office Users” group are excluded.
(&
(objectclass=user)
(objectCategory=Person)
(!memberOf=CN=RDP Users,OU=EDH Office Users,DC=keeper,DC=local)
(!memberOf=CN=Office Admins,OU=EDH Office Users,DC=keeper,DC=local)
)
Example mapping all Users in Active Directory except users which are part of a specific group or any group nested below the specific group. Members of groups “RDP Users” and “Office Users” are included as are members of all sub groups of these two groups due to use of the Active Directory OID (:1.2.840.113556.1.4.1941:).
(&
(objectclass=user)
(objectCategory=Person)
(|
(memberOf:1.2.840.113556.1.4.1941:=CN=RDP Users,OU=Office Users,DC=keeper,DC=local)
(memberOf:1.2.840.113556.1.4.1941:=CN=Console Users,OU=Office Users,DC=keeper,DC=local)
)
)
To map only users which are part of a specific OU, or not map users who are in a specific OU please refer to Node filter.
Preview Filter Results
The Preview option under the filter edit box will display the effective result of the filters defined showing the Tree defined by the Node filter and the objects to be exported by the other filters within the tree structure. Teams always display regardless of the tree node selected. Roles and Users display based on their location in the tree. A total count of objects is also displayed below the tree structure.
Selecting a Node, Role, Team or User will display the associated Active Directory properties for the object selected. This information is helpful to determine properties and property values that can be used to filter for the object.
Publish Changes
Once your configuration is complete, click on "Save" to to retain your current settings. Once all settings are complete use “Publish” to push the changes live and activate the integration.
Always preview after editing filters before publishing your changes to ensure the filter is implemented as intended.
Approval Queue
As described in the previous section, the AD Bridge will provision new Users, Roles and Teams to the Keeper Admin Console based on the configuration and filters applied.
The creation of NEW teams and the action of adding users to a team require an encryption key generation and key exchange that can only occur within the Keeper Admin Console. In addition to the encryption aspect of this process, a level of security is in place to prevent the AD Bridge administrator from adding himself to a team which is privileged.
The Bridge will Notify the Admin of Pending Team Approvals through the Bridge Notification feature.
The Team notification will always sort to the top. This notification summarizes the Teams and Team User Assignments which are pending approval.
For this reason, the Keeper Admin Console contains an "Approval Queue" which prompts the Administrator to quickly approve the creation of new teams and addition of users to teams.
If there are pending approvals, you will see a red indicator at the upper right side of the Admin Console interface:
Click on the indicator to open the Approval Queue. There are two approval queues - "Teams and Users.
Team Approval Queue
Teams that are dynamically created by the AD Bridge must be approved by the administrator in the Admin Console. Click the red alert indicator and select the "Teams" option to display all pending team names.
Approvals can be processed in one batch by clicking the "Approve" column header checkbox, or by selecting individual checkboxes. In the "Disable" columns, this represents the Team Restrictions of Record Re-shares, Record Editing and Password Viewing (this maps to the team restrictions "Disable record re-shares", "Disable record edits" and "Disable viewing passwords" described in the Team screen.)
User Approval Queue
Users that are invited to Keeper within teams must be approved by the administrator in the Admin Console. Click the red alert indicator and select the "Users" option to display all pending user accounts. Note: Users will only appear in the Approval Queue after they have accepted the invitation to the Keeper account and set up their profile.
Approvals can be processed in one batch by clicking the "Approve" column header checkbox, or by selecting individual checkboxes. Upon approval, the user will immediately have access to any Shared Folders which have been shared to the team.
Automating Team Approval
The Keeper Bridge can automate Team approval. This feature requires that the admin be logged into the bridge client locally with their keeper credential. The admin is added to every team in Keeper which they approve. This allows the bridge to use the admin credential to automate User Team assignment. The Admin credential is only retained in memory and is not stored for as this account will have all team keys. If the admin is not logged in during a Publish cycle the Team or Team User Assignment will be queued. A Notification will appear alerting the Admin to log in the Bridge client. Teams and Team users can be approved from the console ad-hoc if needed. It is best to use the same Admin account as is set up for bridge registration. An Admin can only approve teams for which they are members. It a team is approved by a different admin than is used for Bridge Registration and the Bridge admin is not specifically added to that team, the bridge will not be able to approve member to that team.
To enable automated team approval selection the Option on the Options tab.
Team Notification
The Team notification will always sort to the top. This notification summarizes the Teams and Team User Assignments which are pending approval. The notification can be cleared manually, but will also clear itself when no Teams or Team Users require approval after the most recent Publish event has run. If Automated Team Approval is enabled this notification will only appear when the Admin login is not available or a Team User cannot be approved because the Registered Admin is not part of the Team.
Admin Login
Once selected Save the change. The use the Admin Login button on the Connections tab to provide the Admin password. Only the Admin which registered the Bridge can be used.
The Admin Login does not allow the user name to be changed. It is important that the Same admin be used across all team approvals. This ensured the admin is part of an approved team so that they have permission to assign users to the Team.
Two Factor Authentication will be prompted when enabled for the Admin account. The Admin login will be retained by the bridge service in volatile memory and used to assign users to their teams as required.
The Admin remains logged in until the Keeper Bridge Service or the system to which it is installed is restarted. A new login is then required.
Keeper SSO Connect™
Keeper SSO Connect is a SAML 2.0 compatible Service Provider (SP) application that allows Keeper Business customers to seamlessly login to their Keeper Vault using their existing identity provider (IdP). This application complies with Keeper's zero-knowledge security architecture while giving business customers the ability of providing seamless SSO login to their Keeper Vault.
Keeper SSO Connect is a software application that is installed on the enterprise customer's on-premise, private or cloud servers. User's account master passwords are generated dynamically by Keeper SSO Connect and encrypted/stored locally on the installed computer.
System Architecture
End-User Experience
System Requirements
- Mac OS 10.7+
- Windows 7+
- Linux OS with Java 8
Installation & Setup
The steps for setting up Keeper SSO Connect are below:
1. Enable SSO Connect on a node from the Keeper Admin Console
2. Install Keeper SSO Connect on your server (supports Windows, Mac, Unix/Linux)
3. Configure Keeper as a service provider on your existing Identity Provider
IdP Provide-Specific Instructions
Keeper integrates out-of-the-box with several top Identity Providers. Please see the below guides for step-by-step integration with popular IdP providers:
For a general Keeper SSO Connection setup, see the below documentation. If you require additional assistance, please contact your Keeper account representative for installation and training on Keeper SSO Connect.
Business Support
You can reach support by phone at +1 312.829.2680, email at business.support@keepersecurity.com or live chat from our support site.