ご利用中の Keeper アカウントならびに保管されたデータは、EU（欧州）データセンター（ダブリン）所属となります。
このフォームへの記入を完了すると、Keeper の 利用規約 に同意したものとみなされます。
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.
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
https://keepersecurity.com/ja_JP/console
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.
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.
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:
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.
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.
For 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.
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.
Users can also be imported via CSV file using the following format: Email, Address, Name, Role.
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.
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."
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.
Users can be in one of 4 states: Invited, Active, Locked, Blocked.
Additional user actions that can be performed from the "Users" screen. Icons only show if an action is relevant to that 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 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.
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.
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.
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.
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.
iOS, Mac OS (Mac Store), Windows 10 (Microsoft Store) and Android platforms support fingerprint login. By default, all fingerprint logins are allowed.
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.
An admin can restrict the use of certain platforms (Web Vault, Extensions, Mobile and Desktop devices). By default all platforms are allowed.
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.
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.
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.
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.
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.
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.
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.
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.
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.
There are 2 permissions available from the Shared Folder screen when adding users and teams, "Can Manage Records" and "Can Manage Users".
When this setting is checked, the user is able to add and remove records from the shared folder.
When this setting is checked, the user is able to add and remove other users & teams from the Shared Folder.
Shared Folders are a powerful feature of Keeper for all users within the organization. A Shared Folder is a container of passwords or other records in your Keeper Vault that are shared to either a set of named users or an entire Team.
Shared Folders are created by each individual user within their vault (Web Vault, Mobile app, Desktop app and all other platforms support the creation and management of Shared Folders). The Admin Console interacts with Shared Folder only in regards to setting Team permissions and defining the organizational structure for sharing (who is able to share with what teams up and down the node tree).
Individual users and teams can be granted permissions on the record management and user management of the shared folder. See example below.
To create a Shared Folder (using the Web Vault for demonstration):
1. Click on the Shared Folder tab
2. Click on "New Shared Folder" button
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:
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.
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"
Selecting "Share with User"
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").
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.
2. Click the Share icon.
3. Select "Share with User."
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.”
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.
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.
6. Next, navigate to the shared folder that you want to re-assign the record to and highlight it.
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.
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."
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 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.
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.
At any time, you can change which node you are viewing by navigating to or clicking on the nodes on far left Node pane. To navigate to the root-node or top level, click on the business name (e.g. The Company) in the navigation tree or in the breadcrumb along the top.
If the use of nodes are not required by your organization, the Keeper Administrator can disable viewing nodes by selecting the "Advanced Configuration" settings at the bottom of the Admin Console.
Teams are only visible by users in the tree path above and below the node structure (not adjacent nodes) that the team is contained in. To make a team that everyone can see and share to, we recommend setting up your teams in the Root Node or a node at a higher level above the sub-nodes which will be visible to everyone. The visibility of users and teams is important in regards to Shared Folders.
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.
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).
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.
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.
For example, a user could create a Shared Folder of passwords called "Masked Passwords" which restricts the viewing, editing and re-sharing of any password within the shared folder. The same set of users can be in another team that supports full viewing and editing of Passwords.
When deciding which passwords can be viewed versus not viewed, the user can simply share a folder to one team or the other.
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.
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.
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.
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.
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.
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.
To enable RSA SecurID, additional customer integration points are necessary. Please contact your Keeper account manager to initiate this integration.
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.
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 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.
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
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.
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.
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.
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.
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.
"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.
2. Turn on the “Share account” option under the Sharing & Uploading section of the Enforcement Settings of the desired role.
3. Select the administrative role that will have the ability to initiate a transfer (multiple roles may have the ability but only one role can be selected per enforcement).
Note - Both new users as well as existing users will be notified and are required to acknowledge the organization's ability to transfer records from their vault. Users only have to agree to this consent one time, upon logging into the vault.
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 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.
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.
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.
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.
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.
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.
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."
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.”
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 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.
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) )
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.
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) ) )
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) )
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.
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) ) )
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) ) )
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.
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.
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.
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.
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.
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.)
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.
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.
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.
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 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 Requirements- Mac OS 10.7+- Windows 7+- Linux OS with Java 8
The steps for setting up Keeper SSO Connect are below:1. Enable SSO Connect on a node from the Keeper Admin Console2. Install Keeper SSO Connect on your server (supports Windows, Mac, Unix/Linux)3. Configure Keeper as a service provider on your existing Identity Provider
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.
You can reach support by phone at +1 312.829.2680, email at business.support@keepersecurity.com or live chat from our support site.
Keeper Security は cookie（クッキー）を使用してユーザーのサービス利用情報を追跡記録ならびに保管することで、より良いウェブサイトエクスペリエンスを提供しています。当該データは、個人が特定できない状態で、広告主、関連会社、パートナーと共有される場合があります。 詳しくは知る
ライブチャットを使用する場合、cookie を有効にしてください。