Keeper is the leading cybersecurity platform for preventing password-related data breaches and cyberthreats.
Congratulations on your decision to deploy Keeper to protect your organization. This guide will provide valuable information on how to onboard your users, deploy the application to end-user devices and manage the platform.
Keeper's platform provides the following high level capabilities:
Password & Passkey Management
Secrets Management
Zero-Trust Network Access
Secure Vendor Access
OT Security
Connection Management
Remote Browser Isolation
Admin Console
Control Plane
This Keeper Enterprise guide covers the deployment of the core password management platform to your users. Additional guides and documentation of advanced privileged access capabilities are covered in later sections.
Keeper’s platform:
Provides each employee with a secure, encrypted digital vault in which to store their passwords, passkeys, files and other sensitive data. Employees can access their vault from any device and from all web browsers, automatically generate unique, complex passwords for all their accounts, and automatically fill their login credentials into all of their sites and apps.
Provides IT administrators complete visibility into employee password practices, enabling them to monitor password use and enforce password security policies across the entire organization, including password complexity requirements, two-factor authentication (2FA), role-based access control (RBAC), and other security policies.
Provides DevOps and engineering teams with a fully managed cloud-based, zero-knowledge Secrets Management platform for securing infrastructure secrets such as privileged accounts, API keys, database passwords, access keys, certificates and any type of confidential data.
Provides modern privilege access through connection management, OT security, secure vendor access, zero-trust network access and remote browser isolation with session management, monitoring and recording.
A brief platform demo can be viewed below:
Creating a trial of Keeper Business and MSP
(1) To create your Keeper Business or KeeperMSP Trial version, visit this page: https://keepersecurity.com/password-manager-free-trial-sign-up.html ... or click on "Try it Free" from our homepage at: https://keepersecurity.com
(2) Select Business or MSP version
(3) Fill out the form using your Business email address, and click Start Free Trial.
(4) On the next screen, you'll create your account (or if you're using an existing Keeper personal email address, you can select "Use an Existing Account").
Important: At this step, please ensure that you select your desired Geographic Data Center location.
Signup for US, EU, AU, CA, JP data center locations are available.
US GovCloud (FedRAMP Compliant) region is available on request.
The choices available are US, EU, AU, CA, JP. Contact us for GovCloud public sector signup.
If you select the wrong data center region, please contact support to delete your trial and start over.
(5) Select your Administrator account Master Password.
Ensure you select a strong Master Password that is only used for managing Keeper. If you forget your Master Password, Keeper support cannot perform a password reset due to our Zero Knowledge architecture. We recommend activating Account Recovery (via a recovery phrase) after logging in and visiting the Settings screen.
(6) After verifying your email address and selecting a Master Password, you will be logged into the Keeper Admin Console. Click on "Admin" to add users and begin your configuration.
(7) Click on "Add Users" to invite other users for your trial, or to set up additional admin accounts. Users who are manually invited will login with a self-selected Master Password.
(8) Proceed through this Enterprise Guide to learn about best practices for deploying Keeper, Single Sign On ("SSO") integration, Role enforcement policies, Teams, Advanced Administration and other important topics.
Resources for getting started with Keeper Business and Enterprise edition
The following links will get you up and running with Keeper.
Keeper for Teams and Small BusinessKeeper EnterpriseDeploying Keeper to End-UsersKeeper MSPTo schedule a demo or watch an on-demand demonstration of the Keeper platform, visit: https://keepersecurity.com/schedule-demo.html
Contact our sales team: https://keepersecurity.com/contact.html?t=b&r=sales or email sales@keepersecurity.com.
Keeper Security Government Cloud (KSGC) is a FedRAMP Authorized environment that protects your agency against ransomware and cyberthreats with zero-trust cybersecurity.
https://www.keepersecurity.com/industries/public-sector.html
Contact our public sector team at govsales@keepersecurity.com.
If you are an existing customer and need help, contact enterprise support: https://keepersecurity.com/support.html
The resource portal of our website provides several white papers and product data sheets: https://keepersecurity.com/resources.html
The end-user guides are available for our desktop, web and mobile applications: https://docs.keeper.io/user-guides/
If you're a security guru, we recommend taking a look at our encryption model.
Check out the latest release notes and updates across all platforms. https://docs.keeper.io/release-notes/
This quick start guide will help get your small business team up and running with Keeper Business in just minutes
This video will demonstrate all that Keeper has to offer your small business and provide you with step-by-step instructions to get your team up and running in no time.
Short on time? Check out our 3 minute demo here.
When you first log in to the Admin Console, you will land on the Dashboard which will provide an overview of high level data on your user activity and overall security status.
The Dashboard provides oversight of the following:
Top Events and link to Timeline Chart
Security Audit Overall Score
BreachWatch Overall Score
User Status Summary
The Admin tab is where majority of your set-up and user deployment will take place. Here, is where you can access Nodes, Users, Roles, Teams and Two-Factor Authentication Settings.
As a first step, we recommend uploading your company logo to the vault and customizing the email invitation that will invite your employees to create their Keeper Vault. These configurations are highly recommended as they have shown to help with quick user adoption of Keeper's software.
Click Configuration
then click Edit
next to "Company Logo" to upload your image file.
Once uploaded, your company logo will appear in the upper left side of the header when users are logged into their Keeper Web Vault and Desktop App as well as Keeper One-Time Shares.
Click Configuration
then Edit
next to Email Invitation, then toggle "Send Custom Email Invitations" on.
The email invitation template supports customization of the following four attributes:
Subject
Message Heading
Message
Download Button Text
The body of the message supports plain text as well as basic markdown syntax.
Once you have finalized your changes, click Save
. When you are ready to add your users, they will receive your customized invite similar to the one below.
In Keeper's architecture, Roles allow you to define enforcement policies based on a user's job responsibility as well as provide delegated administrative functions. The number of roles you create is a matter of preference and/or business need.
Nodes are used to organize your users into distinct groupings, similar to organizational units in an Active Directory. You can create nodes based on location, department, division or any other structure. Smaller organizations may choose to administer Keeper as single level, meaning no additional nodes are created. In this scenario, all provisioned users are accessed from the default "Root Node".
We recommend you create a secondary Keeper Administrator as soon as possible. At its simplest configuration, the Keeper Administrator role is applied to the initial administrator who has set up the Keeper account for the organization as well as any other user you grant full admin rights. We strongly recommend you add a second user to the Keeper Administrator role in case one account is lost or no longer accessible.
Admin > Users > + Add Users
enter the user's full name and email address, then click Add
Admin > Roles > Keeper Administrator
and clicknext to Users
Select the new user from the list and click OK
to finish.
This will generate an email inviting the users to setup their Keeper account.
Account Transfer will allow a Keeper Administrator to transfer records and data from one user to another, should an employee leave the company. It is an optional, but highly recommended feature that should be configured by the Keeper Administrator during the initial deployment phase of the Keeper rollout. The Account Transfer setup must be configured prior to the user's account being transferred.
First you will need to enable the Transfer Account permission for the Keeper Administrator Role.
The Transfer Account permission is NOT enabled by default and must be manually activated by the Admin.
Admin > Roles > Keeper Administrator
Under Admin Permissions, hover over your company name and click
Check the box next to "Transfer Account" and click OK
To learn more about Account Transfer, click here.
As a second step, Enable Account Transfer for the Keeper Administrator Role. This will allow the vaults of you and any delegated admins, under the Keeper Administrator role to be transferred.
Admin > Roles > Keeper Administrator
Click Enforcement Policies
From the Transfer Account tab, toggle "Enable Account Transfer" on then click Done
All 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 their vault.
Roles allow you to define enforcement policies based on a user's job responsibility as well as provide delegated administrative functions.
You will need at least one role defined for your users, but you can create as many as you would like depending on the structure of your organization. Roles can be created to support a variety of policies depending on what enforcements should be applied to a user based on their position (e.g. Administrators, Executives, Managers, Staff, and Contractors). For smaller organizations, Keeper recommends you create a default, "General Employee" role.
Admin > Roles > + Add Role
Select the Node you want to add the Role to, enter the name of the role and click Add
To learn more about Roles, click here.
Nodes are used to organize your users into distinct groupings, similar to organizational units in an Active Directory. You can create nodes based on location, department, division or any other structure.
Smaller organizations may choose to administer Keeper as single level, meaning no additional nodes are created. In this scenario, all provisioned users are accessed from the default "Root Node" (e.g. ACME Co.).
Admin > + Add Node
Enter the name of the Node then click Add Node
to finish.
At any time, you can change which node you are viewing by navigating to or selecting the Nodes on the far left Node pane. To navigate to the root node or top level, select your business name (e.g. ACME Co.) in the navigation tree.
To learn more about Nodes, click here.
To ensure that a certain role is applied to all imported users, enable the “Set as Default Role for Node and Sub Nodes” setting. This will automatically assign new users that are added to a Node or Sub Node to a specified role.
Admin > Roles
select the target role then check the box next to "Set as Default Role for Node and Sub Nodes".
Role-based Access Controls (RBAC) provide your organization the ability to define Enforcements Policies based on a user's job responsibility as well as provide delegated administrative functions.
Enforcement Policies offer a wide-range of control features that are organized into the following categories:
Login Settings
Two-Factor Authentication (2FA)
Platform Restriction
Vault Features
Record Types
Sharing & Uploading
KeeperFill
Account Settings
Allow IP List
Keeper Secrets Manager
Transfer Account
Admin > Roles
select a role then click Enforcement Policies
A dialogue box will appear where you can configure the Enforcement Policies that will be applied to the selected role. Click Done
when finished.
To learn more about Enforcement Policies, click here.
Business customers can seamlessly deploy Keeper to their users using two different methods. Admins can either manually invite individual users or bulk import users via a CSV file. Advanced deployment options are also available.
Admin > Users > + Add Users
Select the Node you would like to add the user to, enter their Full Name and Email Address then click Add
This will generate an email inviting the user to setup their Keeper account. Instructions to customize the email can be found in the Key Configuration Steps section, above.
Admin > Users > + Add Users
Select the Node you would like to add the users to then simply drag and drop your formatted CSV file of users or click Browse Files
to upload the file from your local device (the Role field is optional). To learn more about formatting your CSV file, click here.
Review the user details and click Add
to complete the import.
This will generate an email inviting the users to setup their Keeper account. Instructions to customize the email can be found in the "Key Configuration Steps" section, above.
Keeper integrates with any SAML 2.0 identity provider for just-in-time provisioning:
Entra ID / Azure AD
Okta
Google Workspace
Microsoft AD FS
Amazon AWS
Auth0
Centrify
Duo SSO
F5
OneLogin
Ping Identity
PingOne
Rippling
RSA SecurID Access
SecureAuth
Shibboleth
Any other SAML 2.0 identity provider
See the User and Team provisioning section to learn more.
Next, we encourage you to create Teams. The purpose of creating teams is to give users the ability to share the records and folders within their vaults with logical groupings of individuals. The administrator simply creates the team, sets any Team Restrictions (edit/viewing/sharing of passwords) and adds individual users to the team. Teams can also be used to easily assign Roles to entire groups of users to ensure the consistency of enforcement policies across a collective group of individuals.
Admin > Teams > + Add Team
Select the Node you want to add the team to then enter the name of the team and click Add Team
You can then set the following team-level restrictions:
Disable record re-shares
Disable record edits
Apply privacy screen
Clickto add individual Users and Roles to the team.
Team-to-role mapping allows organizations to assign users directly to teams that can be assigned custom roles. With team-to-role mapping, a user who is a member of a team that is assigned to a role, will assume the enforcements of the given role.
It's important to note, that Keeper implements Least-Privileged policies, so when a user is a member of multiple roles or teams, their net policy is most restrictive or least privileged.
To learn more about teams and team-to-role mapping, click here.
As a final step to further enhance your security practices, we recommend that you require the use of Two-Factor Authentication across your organization. This role enforcement can be enabled within each role's Enforcement Policy settings.
Admin > Roles
select the target role and click Enforcement Policies
Toggle "Require the use of Two-Factor Authentication" on.
Set your platform-specific enforcements, enable the desired 2FA methods then click Done
Keeper is a cybersecurity platform for preventing password-related data breaches and cyberthreats.
Keeper Enterprise provides the highest levels of security and at the same time provides a simple user experience - with millions of users worldwide, Keeper is the proven industry leader.
Keeper is SOC 2 Certified, ISO27001 Certified, FedRAMP Authorized and StateRAMP Authorized. Keeper's encryption has been certified by the NIST CMVP and validated to the FIPS 140 standard by accredited third party laboratories.
Below is a 25-minute demonstration of the Keeper Enterprise platform.
For a personalized demo with a Sales Engineer: Request a Demo Passwords are the single greatest cause of a data breach. 81% of data breaches are due to weak or stolen passwords. Password management solutions provide an affordable and simple way for companies to solve the root cause of most data breaches. By helping businesses generate strong passwords as well as manage and securely share them among teams, they significantly reduce the risk of a data breach.
Keeper's architecture is the most secure in the industry. Built from the ground up with record-level encryption and client-side key generation, the foundation of Keeper Enterprise is built upon a model that ensures only the user is able to decrypt and access their privileged information.
The Keeper platform is built on an access layer and encryption layer. Access and authentication controls who is able to sync the encrypted ciphertext, and client-side encryption controls who is able to physically encrypt/decrypt the data. This foundation is what gives Keeper the ability to apply the most granular level of protection to user data and enables the core features and capabilities of the product.
Users, Roles, Teams, Records and Shared Folders are all protected and managed through the use of client-side generated keys. This complex distribution of keys is completely managed by the software with a simple and easy-to-use user interface.
Keeper Encryption and Security Model DetailsKeeper is a cross-platform solution that provides full capabilities from every major platform and device including iOS, Android, Windows, Mac and Linux. Browser plugins are compatible with Chrome, Firefox, Edge, Safari and any other chromium-based browser.
The Keeper Administrator can restrict vault access to specific platforms based on security requirements of the enterprise. End-user vault applications can be used completely independent of one another, or used together. For example, using the Web Vault or Desktop Application does not require the installation of a browser plugin.
The Keeper Vault is available on all devices and computers, with award-winning native applications:
Native Desktop Apps
Windows
Mac
Linux
Browser-Based Apps
Chrome
Edge
Safari
Firefox
Brave
Other Chromium-based Browsers
Native Mobile Apps
iOS
Android
Chrome, Firefox, Edge, IE and Safari Browsers
Key Differentiators
Keeper was named Best Password Manager by PC Mag in 2018, 2019, 2020 and 2021. Some of the reasons that customers select Keeper over the competition are listed below.
Keeper vs. LastPass https://www.keepersecurity.com/vs/lastpass.html
Keeper vs. Dashlane https://www.keepersecurity.com/vs/dashlane.html
Keeper vs. 1Password https://www.keepersecurity.com/vs/1password.html
Keeper vs. Keepass https://www.keepersecurity.com/vs/keepass.html
Keeper vs. Passportal https://www.keepersecurity.com/vs/nable-passportal.html
Keeper vs. Bitwarden https://www.keepersecurity.com/vs/bitwarden.html
SSO and SAML simplify login to many cloud applications, however, it does have its limitations. Keeper (with Keeper SSO Connect) complements the two major gaps with your SSO deployment:
Offering privileged access to applications that don’t support SAML protocols.
Enabling non-password use cases, such as management and sharing of digital certificates, SSH keys, API keys, secret notes, lists, files and more.
With Keeper SSO Connect, you can easily add Keeper to the apps that your IdP services. Whether you use AD FS, Entra ID/Azure, Okta, Google Workspace, Centrify, Ping, JumpCloud or any other SAML 2.0 Identity Provider, Keeper will easily integrate. Keeper SSO Connect logs the user directly into their encrypted vault while maintaining full zero knowledge. With SSO integration, there is also no master password to remember. Keeper SSO Connect is available as a customer-hosted or cloud-hosted high availability solution that preserves zero knowledge and allows the end-user to authenticate directly into their vault.
For more information about Keeper SSO Connect, visit our web page: https://keepersecurity.com/keeper-sso-connect.html
Keeper's Zero-Trust Platform seamlessly integrates into any existing identity stack and infrastructure.
Keeper's least-privilege access model, encryption model and role-based access model support the zero trust implementation guidelines of NIST and provide organizations with a substantial leap forward in the journey towards zero trust.
For reference, see the National Institute of Standards and Technology (NIST) Special Publication (SP) 800-207 document which provides the following operative definition of zero trust and ZTA:
https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-207.pdf
Keeper provides customers with the selection of geographic regions where data resides in-country.
United States
GovCloud US
Ireland
Frankfurt
Australia
Canada
Japan
The ability to provide least privileged access to an employee is critical in the deployment of an Enterprise Password Manager. Keeper gives fine-grained control over what users are capable of accessing and managing within the platform through the use of customizable role policies. By providing a flexible role policy engine, you can lock down restrictions and access based on the risk profile of the employee. For example, you may want your IT Admins to be restricted from accessing their vault outside of the office network. Or you may want administrative assistants the ability to onboard new users, manage teams and run reports. The entire process is fully customizable through a user friendly interface. Role Enforcements Include:
Password Complexity Rules and Biometrics
Multi-Factor Authentication, Token Expiration and Device Restriction
Offline Access Restrictions
Allow IP Listing, Sharing and Data Export Restrictions
Account Transfers (employee offboarding and break-glass scenarios)
Administrative Permissions
Keeper Administrators can create organizational units (called Nodes). A role can be given Administrative permissions over the node (or sub-nodes) for which a role exists. This delegated administration allows different people in the organization to have management controls over subsets of teams of users, roles and shared folders. Users within different nodes can be provisioned and authenticated with different methods.
Keeper's Zero Knowledge Account Transfer capabilities provide Enterprise customers with the peace of mind that an employee will never walk away with critical data when they leave the organization.
Since 50% of help desk calls are estimated to be password related, there is a significant productivity gain by rolling out a password manager to your organization. When employees don't need to worry about remembering passwords, the cost savings are massive.
Compliance is becoming even more complex with requirements mandating internal control policies and standards. Organizations in heavily regulated industries are audited for password enforcement policies and practices. Keeper's password security platform solves many of compliance and regulation enforcement requirements that organizations face. Keeper Security is the most certified solution in the industry:
SOC 2 Certified
ISO 27001 and ISO 27017 Certified
FIPS 140-3 Validated
GDPR Compliant
GSA Certified
SAM Certified
Compliant with the EU-U.S. Data Privacy Framework (“EU-U.S. DPF”), the UK Extension to the EU-U.S. DPF and the Swiss-U.S. Data Privacy Framework (“Swiss-U.S. DPF”)
ITAR Compliant
FedRAMP Authorized
StateRAMP Authorized
Keeper Security is listed as Authorized on the FedRAMP Marketplace with an authorization date of 8/23/2022.
See: The Federal Risk And Management Program Dashboard (fedramp.gov)
Keeper supports compliance with United States International Traffic in Arms Regulations (ITAR). Companies that are subject to ITAR export regulations must control unintended exports by restricting access to protected data to U.S. Persons, and by restricting physical location of protected data to the U.S.
Keeper’s FedRAMP Moderate environment supports ITAR requirements through the following:
Fully compliant data storage hosted on AWS GovCloud and restricted to the U.S.
Secure data encryption in transit and at rest.
Zero knowledge and zero trust security, in conjunction with granular permissions, allows organizations to ensure that only approved personnel can access sensitive data.
Robust compliance reporting features provide a traceable, electronic audit trail of all actions performed and data entered.
Sequestered Customer Success team comprised of U.S. Persons specifically trained in safe handling of Export Controlled and ITAR-governed data.
No non-U.S. based support on public sector environments.
The Keeper FedRAMP environment has been audited by an independent third-party assessment organization (3PAO) to validate that proper controls are in place to support customer export compliance programs.
For more information about ITAR, please visit https://www.pmddtc.state.gov/.
High level steps for successful rollout of Keeper Enterprise
For the most successful rollout of Keeper Enterprise, we recommend following the steps below:
If you haven't already, create a Keeper Enterprise Trial from our website or by contacting the sales team. Be sure to allocate the necessary number of total users you expect to onboard.
Create your Keeper Admin account and login to the Keeper Admin Console by following the instructions sent via email from the trial registration form.
Managed Service Provider (MSP) customers: Please sign up for the Keeper MSP product trial. Keeper MSP is a specialized version of the Keeper Enterprise product. To jump to the Keeper MSP guide, click here.
Schedule a demo/training session with our Business Support team by contacting your sales representative or emailing business.support@keepersecurity.com.
Setup and configure your provisioning and authentication methods as described in the User and Team Provisioning section of this document. You can choose from many different provisioning methods such as:
Manual provisioning through the Keeper Admin Console
Active Directory provisioning with the Keeper Bridge service
Single Sign-On (SAML 2.0) with Just-In-Time (JIT) provisioning
SCIM automated provisioning
Email provisioning
Keeper Commander API / SDK provisioning
Contact us if you require assistance in configuring your environment.
Inform your users, stakeholders, DevOps and IT Admin teams that you have partnered with Keeper Security, the leading cybersecurity platform for preventing password-related data breaches and cyberthreats to implement a simple, employee-friendly password management application.
Deploy Browser Extensions and/or Desktop application as desired to users via push mechanism. https://docs.keeper.io/enterprise-guide/deploying-keeper-to-end-users
Or, direct your users to install Keeper from our Download Page.
Users can also simply utilize the Web Vault and Browser Extensions:
US Data Center: https://keepersecurity.com/vault
US Public Sector / GovCloud: https://govcloud.keepersecurity.us/vault
EU Data Center: https://keepersecurity.eu/vault AU Data Center: https://keepersecurity.com.au/vault CA Data Center: https://keepersecurity.ca/vault
JP Data Center: https://keepersecurity.jp/vault
Upon first login, the user is prompted to import passwords and walk through setup steps, 2FA, etc.
Users are invited to join a training session via Google Meet or the customer's meeting platform. This training invite can be contained within the email invitation body content, or sent separately by the Admin to their users. Contact your Customer Success manager at success@keepersecurity.com to start training your team.
The Keeper Admin can monitor the usage of users via the Reporting & Alerts Module and also configure realtime web-hook alerts to Slack or Microsoft Teams. Installing Keeper Commander is also helpful for running automated reports.
We recommend that the Keeper Admin notifies users regarding the timeline in which built-in password manager saving will be disabled by GPO.
After the specified amount of time, the Keeper Admin disables legacy built-in browser password managers, thus requiring and enforcing the use of Keeper on the browser.
To learn more about how to disable the built-in password manager Click Here.
It's critical that all employees use Keeper to manage their passwords and to prevent sharing of information over insecure channels. Update your password policies and employee onboarding processes to ensure that Keeper is utilized. Sharing records to the user's vault is a great way to encourage them to login and gain access.
Reserve the use of domains for privacy and security
Keeper's Cloud architecture is Zero Knowledge (more information about our security model is here).
For security reasons, Keeper's Enterprise tenants are restricted to inviting and creating end-user accounts within certain email domains. When you sign up for a Keeper Business or Enterprise account, we recommend that you use a business email domain, e.g. mycompany.com.
If you sign up for the Enterprise account using @mycompany.com for your email address, this domain will be reserved to your tenant.
Keeper's architecture requires a domain to be reserved before it can be used by the Enterprise. This serves several purposes:
(1) Ensures that end-users cannot create "rogue" accounts without being explicitly invited or provisioned by the Enterprise Admin.
(2) Reduces administrative burden in locating free or personal accounts associated with a domain
(3) Prevents a malicious actor from creating a Keeper account with a domain reserved by an Enterprise customer.
If you require additional email domains (e.g. us.company1.com and eu.company2.com), please open a support ticket with the Keeper team and we will assist you in reserving the domain.
If you own a set of domains that your users will use for logging in, be sure to contact your Keeper account manager to request domain reservation for all of your domains. We can lock the domains to your preferred region to ensure that users don't sign up in the wrong geographic data center.
Keeper maintains a list of "personal" domains, for example gmail.com and yahoo.com which cannot be reserved and allow the general public to create Keeper accounts with those domains, with a verified email.
If you would like to allow end-users to create personal or Enterprise accounts with your reserved domain outside of your enterprise tenant, please contact the Keeper support team and we can unlock this domain for you.
Organizations have the option to add a “corporate alias” to their account. For example, in situations where an organization domain change occurs, our team can easily transition your users to the new domain without any interruption in service. Please contact Keeper's support team to add a domain alias to your account.
If you are using Keeper SSO Connect Cloud or Keeper SSO Connect On-Prem, you can enable Just-In-Time Provisioning. If Just-In-Time provisioning is enabled, you can automatically route users to the identity provider when the user types in their email and clicks "Next" from the Vault login screen. This applies to all devices including Web Vault, Desktop App, Browser Extensions, iOS and Android apps.
If you would like to ensure that new users who access the vault are automatically routed to your SSO based on the email domain, please contact support and we will assist in setting up the routing.
Customers who attempt to login or provision accounts from a different region may or may not automatically get routed to the proper region where their tenant is hosted. If the routing is not occurring, please open a support ticket.
Methods for deploying the Keeper app to end-user devices.
This section describes the methods of deploying Keeper to end-users. Keeper can be deployed as a web browser application, browser plugin, mobile app and native desktop application.
A series of Keeper 101 videos are available to help train your end-users. Below is the Enterprise End-User guide:
Keeper works on every smartphone, tablet and computer. Keeper supports popular browsers including Chrome, Safari, Firefox, Edge, Brave and Opera. Native app installation is available from the Keeper website and every public-facing app store (iTunes, Google Play, Microsoft Store, Mac App Store, etc).
Device | OS Version Supported |
Windows | 7 / 8 / 10+ |
Mac OS | Current Version - 2 |
Linux | Fedora, Red Hat, CentOS, Debian, Ubuntu, Mint |
iOS | 9+ |
Android | 4.4+ |
Chrome OS | Current Version - 2 |
Edge | Current Version - 2 |
Safari | Current Version - 2 |
Firefox | Current Version - 2 |
Opera | Current Version - 2 |
Brave | Current Version - 2 |
The latest Keeper downloads can be found at https://keepersecurity.com/download
Most business and enterprise customers utilize the Keeper Web Vault, which is a fully featured web-based application. To access the Keeper Web Vault login, visit:
US Data Center: https://keepersecurity.com/vault
US Public Sector / GovCloud: https://govcloud.keepersecurity.us/vault
EU Data Center: https://keepersecurity.eu/vault AU Data Center: https://keepersecurity.com.au/vault CA Data Center: https://keepersecurity.ca/vault
JP Data Center: https://keepersecurity.jp/vault
Keeper provides customers with a fully native desktop application as an optional component. The desktop app has some unique capabilities compared to the web vault, such as native app autofill and hot keys. See the subsection Desktop Application.
Keeper's browser extension provides autofill capabilities on every web browser. See the subsection Browser Extension (Keeper Fill).
Keeper for mobile and tablet devices can be deployed through the public-facing app stores. MDM solutions can also push these applications to end-user devices without any special requirements. When the users register or sign into an account, Enterprise enforcement policies are automatically applied.
Keeper supports authentication, provisioning and deployment through your existing SAML 2.0 identity provider such as Azure AD, Okta, Google Workspace, JumpCloud, Ping and many others. See the SSO Connect Cloud setup guide for deployment instructions.
When deployed through Azure AD, Keeper fully supports Azure conditional access policies across web, mobile and desktop applications.
Methods for deploying Keeper to user desktops
Keeper offers users two different desktop vaults. The Keeper Web Vault in the web browser, and the native Keeper Desktop application for Windows, Mac and Linux.
The Keeper Desktop App has several benefits compared to the Keeper Web Vault such as:
Ability to Autofill and auto-type passwords into native apps using KeeperFill for Apps feature.
Ability to automatically import existing passwords without additional component installation.
Automatically migrate from existing LastPass vaults.
Secure biometric login using Touch ID on compatible MacBook Pro computers.
Secure biometric login using Windows Hello (Windows 10).
Windows Hello for Business, including biometrics and smart card capabilities (Windows 10).
Increased performance.
Offline access using biometrics or master password (if permitted by Keeper Admin)
Keeper Desktop is a cross-platform native desktop application for Windows, MacOS and Linux. Several installer files are provided at the links below. For additional details on each package, see the Additional Deployment Details section below.
Windows 10 AppInstaller (64 and 32-bit, supports Windows Hello) [Install Link] Command-line deployment:
Microsoft Store Version (64 and 32-bit, supports Windows Hello) [Microsoft Store Link]
Command-line deployment:
Windows 10 MSIX Installer: [MSIX Installer Link] (Note: MSIX does not auto-update) Command-line deployment:
Windows 10 MSI Installer: [MSI Installer Link] (Note: MSI does not auto-update, no support for Windows Hello)
Command-line deployment:
Mac OS .dmg [Install Link (.dmg)]
Mac App Store [Mac App Store Link] (Note: does not support iCloud Keychain import)
Linux Fedora, Red Hat, CentOS, Debian, Ubuntu and Linux Mint: (Please refer to the below Download Page for the latest links) [Download Page Link]
Password Importer Standalone (Windows 10): [Install Link (.exe)]
Password Importer Standalone (Mac OS): [Install Link]
Installer: [Install Link]
Supported Platforms: Windows 10 build 1803 or newer.
Supported Architectures: x64, ia32
Install Location: %programfiles%\WindowsApps\KeeperPasswordManager_*
Data Location: %localappdata%\Packages\KeeperSecurityInc.KeeperPasswordManager_xxx
Auto-Updates: Yes
Windows Hello: Yes
The appinstaller is just a lightweight wrapper around the msixbundle that enables auto-update functionality, which is checked on app launch. Due to including the auto-update feature, the appinstaller requires Windows 10 version 1803.
Users download a small appinstaller file that automatically fetches the msixbundle from https://keepersecurity.com/desktop_electron/packages/KeeperPasswordManager.msixbundle. It otherwise behaves the same as the MSIX install.
The appinstaller can be deployed with PowerShell like this:
The contents of the KeeperPasswordManager.appinstaller
file is below:
Install Link: [MSIX Installer Link]
Supported Platforms: Windows 10 build 1703 or newer.
Supported Architectures: x64, ia32
Install Location: %programfiles%\WindowsApps\KeeperPasswordManager_*
Data Location: %appdata%\Keeper Password Manager\IndexedDB
Auto-Updates: No
Windows Hello: Yes
The msixbundle file is an appx bundle containing multiple architectures, currently x86 and x86_64 are supported. The asset requires at least Windows 10 version 1703 to install, and installs to C:\Program Files\WindowsApps with a package identity which enables additional features such as Windows Hello. The installed app is owned by TrustedInstaller.
Command-line deployment:
Install Link: [MSI Installer Link]
Supported Platforms: Windows 7, Windows 8, Windows 8.1, Windows 10
Supported Architectures: x64, ia32
Install Location: %programfiles%\keeperpasswordmanager
Data Location: %appdata%\Keeper Password Manager\IndexedDB
Auto-Updates: No
Windows Hello: No
The MSI installer does not auto-update. This is to satisfy enterprise administrators who require complete control over application updates.
The MSI installer is 32-bit, and it has the best compatibility with older versions of Windows.
The MSI installer does not support Windows Hello.
The MSI can be silently installed from an elevated command prompt (otherwise it will silently fail at the unanswered Windows UAC prompt that never happens because it's a silent install) in this way:
The MSI installer does not allow selecting the installation location to mitigate a security weakness whereby an administrator can install the application in a location, such as C:\
where non-privileged users have access to modify or replace the binary. Instead, the MSI installer always installs to %programfiles%
.
The Keeper .MSI installer utilizes Microsoft Msiexec. Standard switches are documented here: https://docs.microsoft.com/en-us/windows/desktop/msi/standard-installer-command-line-options
Install Link: [Microsoft Store Link]
Supported Platforms: Windows 10 build 1803 or newer.
Supported Architectures: x64, ia32
Install Location: %programfiles%\WindowsApps\KeeperPasswordManager_*
Auto-Updates: Yes (via Microsoft Store)
Windows Hello: Yes
The Windows Store build is almost identical to the normal msixbundle, but has a different app identity which is assigned by the Microsoft Store. Updates are managed by the Microsoft Store, and the app is also installed to C:\Program Files\WindowsApps
and is owned by TrustedInstaller.
The desktop app is able to be installed silently from the Microsoft Store using Microsoft's package manager winget
:
Businesses may push the Microsoft Store app to Intune using an Intune Connector setup to use the Microsoft Store For Business (businessstore.microsoft.com), which is different than the consumer Microsoft Store (apps.microsoft.com), which some companies block. Companies are given the option to publish two different types of apps, an "offline" (which wont update automatically via the store) and an "online" (should update via the store) version. The “online” version will update the app in Company Portal as well, so every time a user installs it from Company Portal, it’s the newest version.
Minimum Requirements:
Mac OS 10.10+ with Intel or Apple M1 ARM-based processor, 64-bit. 512MB RAM. Keeper Desktop for Mac contains a universal installer which is optimized for both chipsets.
Auto-Updates: Yes
Download Link:
Keeper for Mac (.dmg)
Fedora 28 or above Ubuntu LTS releases 16.04 or above Red Hat Enterprise Linux 7.0 or above CentOS version 7.3 and above Debian 8 and above Hardware: 512MB RAM
Auto-Updates: No
Keeper for Linux - Fedora, Red Hat and CentOS
Keeper for Linux - Debian, Ubuntu and Linux Mint
For file verification, Keeper Desktop SHA1 hashes are computed based on the most recent version and can be retrieved at the below URL: https://keepersecurity.com/desktop_electron/SHASUM256.txt
Enterprise configuration settings are available in Keeper Desktop version 16.7.0 and newer.
Keeper supports Enterprise Configuration settings to control the end-user experience.
Key | Type | Description |
---|---|---|
DomainName | String | Enterprise SSO Domain to pre-populate on app launch. |
Region | String | Region identifier where your Keeper tenant is hosted. Must be one of ("us", "eu", "au", "usg") |
HideCreateAccount | Boolean | Hides the Create Account button from the start page |
UseDefaultBrowserForSSO | Boolean | Routes the user to their default web browser for SSO authentication instead of using a popup window. |
Keeper Desktop can be configured using standard macOS NSUserDefaults
objects using the com.keepersecurity.passwordmanager
domain. If your MDM solution is able to push macOS user defaults, you can use this method for enforcing configuration settings. Note the capital letter on the key value.
Testing the Config
You can test the configuration on the local machine using the below commands:
For example:
Keeper Desktop's mac app bundle has an Information Property List File, Info.plist
, which contains key-value pairs that identify and configure a bundle.
Finding the App Bundle ID and App Version
The following keys in Information Property List file contains the values for the App Bundle ID and App Version:
CFBundleIdentifier: App Bundle ID
CFBundleShortVersionString: App Version
To find the values of the above keys, you need to access the Information Property List File, Info.plist
, and find the corresponding values.
Location of Info.plist
after mounting DMG file:
Alternatively, you can run the defaults read
command:
For the Keeper Desktop App, running the following commands would give you the App Bundle ID and Version:
All Windows, macOS and Linux end-user installations can be configured by using a UTF-8 encoded JSON file placed in the user's home folder under ".keeper/desktop.config.json
". Note the identifiers are using camel case for JSON defaults with a lowercase on the first letter.
Example File
macOS End Users
Alternatively, for macOS end-users, Keeper Desktop can be configured using the standard macOS NSUserDefaults
. Visit the following section for more information.
The desktop.config.json file must be UTF-8 encoded.
From your text editor, in File > Save As...
In the "Save as type" drop-down, select All Files.
In the "Encoding" drop-down, select UTF-8.
Ensure the name of the file is desktop.config.json
Note that Keeper can automatically route your users to the proper enterprise tenant, SSO provider and data center based on the email domain that they type into the Keeper login form. If you are using SSO, make sure that the "Just In Time Provisioning" option is enabled in the SSO configuration. Also, ensure that your domain is reserved, which means that typing anything @ yourcompany.com will get routed to the proper region.
If the routing of user to the proper region and SSO is not working correctly for you, please open a support ticket.
You can launch the Keeper Password Manager automatically when you start your computer.
To set Keeper Password Manager app to launch at start up, go to Start > Run and type shell:startup
Your startup folder will be shown. Place a shortcut Keeper Desktop into this folder. Now Keeper will launch automatically on startup.
From Settings, go to General > Login Items
Click the Plus (+), go to Applications, and select Keeper Password Manager
Now Keeper will launch when you start your mac.
KeeperFill makes it easy to login, save passwords and access your vault on web browsers.
The KeeperFill browser extension can be installed directly by the user or pushed to users by the Keeper administrator.
The latest KeeperFill Browser Extension can be installed by users at the links below, or by visiting the Keeper download page. Chrome, Brave, Opera and other Chromium-based Browsers: https://chrome.google.com/webstore/detail/keeper%C2%AE-password-manager/bfogiafebfohielmmehodmfbbebbbpei Firefox: https://addons.mozilla.org/en-US/firefox/addon/keeper-password-manager/ Microsoft Edge: https://microsoftedge.microsoft.com/addons/detail/keeper%C2%AE-password-manager-/lfochlioelphaglamdcakfjemolpichk
Safari: https://apps.apple.com/us/app/keeper-for-safari/id6444685332
Chrome, Edge and Firefox deployment guides are linked below:
Deploying Firefox with Extensions (Mozilla)
For environments where devices are managed through platforms such as Microsoft Intune or Jamf.
If your group policy does not support installation of extensions, your SCCM administrator may be able to use the below links to push the extensions or directly:
Microsoft Edge and Chrome: chrome.zip
Firefox: firefox.xpi
Direct package install is not recommended for most environments. Using app store management portals such as Google Admin are preferred.
User guides are available for every web browser at the links below:
Deploying KeeperFill to macOS devices using device management platforms
Follow these steps to deploy KeeperFill to all Mac devices in your organization using your preferred device management platform.
To set up KeeperFill on Mac, you create configuration files in MCX Property List (.plist) format. When you deploy the configuration files to the device using your preferred mobile device management (MDM) tool, the settings are applied.
These procedures are a General Guide and assume that you have already deployed the Chrome Browser within your organization.
Use your preferred editor to create the Keeper .plist policy file.
Set up KeeperFill browser extensions.
Push the configuration files to all macOS devices in your organization using your preferred mobile device management (MDM) tool.
Deploying KeeperFill to Chrome via PLIST Policy
If you currently do not have a Policy file created, please proceed to creating your Keeper plist policy file to your desired location, Ex: /tmp and name it com.google.Chrome.plist by selecting GO on the top Menu Bar of you MacOS Desktop and select Terminal to open a Terminal Console.
Copy and paste the contents below, into your Terminal, and hit Enter / Return. This will create your plist file within the /tmp directory and display that the file is there.
In your preferred file editor or basic file editor, copy, paste and save the contents, below, into the com.google.Chrome.plist file.
There are multiple tools to deploy your PLIST policy. In the next set on instructions, we will walk through deploying your PLIST policy file via Jamf Pro, AirWatch and Microsoft Intune.
Deploying Custom Configuration Profiles using Jamf Pro
This is a general overview of how to deploy Google Chrome's .plist configuration profile, to computers within your organization, using Jamf Pro.
Upload the manually created Google Chrome PLIST file that defines the properties for the preference domain you specify in Jamf Pro.
Log in to Jamf Pro.
Click Computers at the top of the page.
Click Configuration Profiles.
Click New.
Use the General payload to configure basic settings, including the level at which to apply the profile and the distribution method.
Click the Application & Custom Settings payload, and then click Upload.
Click Add.
Enter com.google.Chrome in the Preference Domain field.
To upload the custom PLIST file choose Upload File, enter the preference domain for which you want to set properties. Click Upload PLIST File, and then choose the com.google.Chrome.plist file previously created.
Note: If the PLIST file contains formatting errors, follow the PLIST (.plist) Policy Deployment instructions to remediate the issue.
10. Click the Scope tab, and then configure the scope of the configuration profile. 11. Click Save.
Deploying Custom Configuration Profiles using Microsoft Intune
This is a general overview of how to deploy Google Chrome .plist configuration profile, to computers within your organization, using Microsoft Intune.
Sign in to the Microsoft Endpoint Manager admin center.
Select Devices > Configuration profiles > Create profile.
Enter the following properties:
Platform: Select macOS
Profile: Select Preference file.
Select Create.
5. In Basics, enter the following properties:
Name: Enter a descriptive name for the policy. Name your policies so you can easily identify them later. For example, a good policy name is macOS: Add preference file that configures Google Chrome on devices.
Description: Enter a description for the policy. This setting is optional, but recommended.
6. Select Next.
7. In Configuration settings, configure your settings:
Preference domain name: Enter the bundle ID as com.google.Chrome
Property list file: Select the property list file associated with your app. Be sure to choose the com.google.Chrome.plist file previously created.
The key information in the property list file is shown. If you need to change the key information, open the list file in another editor, and then re-upload the file in Intune.
Note: Be sure your file is formatted correctly. The file should only have key value pairs, and shouldn't be wrapped in <dict>
, <plist>
, or <xml>
tags. If the PLIST file contains formatting errors, follow the PLIST (.plist) Policy Deployment instructions to remediate the issue.
8. Select Next.
9. In Scope tags (optional), assign a tag to filter the profile to specific IT groups, such as US-IL IT Team
or Chicago_ITDepartment
. For more information about scope tags, see Use RBAC and scope tags for distributed IT.
10. Select Next.
11. In Assignments, select the users or groups that will receive your profile. For more information on assigning profiles, see Assign user and device profiles.
12. Select Next.
13. In Review + create, review your settings. When you select Create, your changes are saved, and the profile is assigned. The policy is also shown in the profiles list.
Select Devices > Configuration profiles. All the profiles are listed.
Select the profile you want to assign > Properties > Assignments > Edit:
Select Included groups or Excluded groups, and then choose Select groups to include. When you select your groups, you're choosing an Azure AD group. To select multiple groups, hold down the Ctrl key, and select your groups.
Select Review + Save. This step doesn't assign your profile.
Select Save. When you save, your profile is assigned. Your groups will receive your profile settings when the devices check in with the Intune service.
When you create or update a profile, you can also add scope tags and applicability rules to the profile.
Scope tags are a great way to filter profiles to specific groups, such as US-IL IT Team
or Chicago_ITDepartment
. For more information about scope tags, see Use RBAC and scope tags for distributed IT.
Deploying KeeperFill to Linux devices using device management platforms
Follow these steps to deploy KeeperFill to all Linux devices in your organization using your preferred deployment tool or script.
To set up KeeperFill on Linux, you create configuration files in JavaScript Object Notation (.json) format.
These procedures are a General Guide and assume that you have already deployed the Chrome Browser within your organization.
Use your preferred editor to create the Keeper JSON policy file.
Set up KeeperFill browser extensions.
Push the configuration files to all Linux PCs in your organization using your preferred deployment tool or script.
Deploying KeeperFill via JSON Policy
If you currently do not have JSON Policy files created in which you want to utilize to deploy the Keeper Browser extension to all PCs in your organization, please proceed to creating your Keeper JSON policy file to your desired location, Ex: /tmp, and name it keeperbe.json
OR create your keeperbe.json file via command-line
2. In your preferred JSON file editor or basic file editor, copy, paste and save the contents, below, into the keeperbe.json file or the policy file in which you currently utilize for your organization.
If you currently have configuration folders setup for the user PCs in your organization, proceed to Step 3: Deploying the Keeper JSON Policy File.
On each PC, in your organization, that you would like to apply this policy on, you’ll need at least one folder to apply this policy.
If it does not already exist, create the directory structure, verbatim, as follows; /etc/opt/chrome/policies/managed
and set the proper permissions for that directory.
OR create your directory structure via command-line
The creation of this directory will most likely NOT be in the same directory as where Chrome is installed on the target Linux devices. Ex: My Chrome installed directory is /opt/google/chrome but my managed policy directory, in which my organization manages my Chrome install, is in the /etc/opt/chrome/policies/managed directory.
Use your preferred method (utility or script) to push the keeperbe.json policy file and Chrome Browser to the target Linux devices in your organization.
Push the keeperbe.json file to the /etc/opt/chrome/policies/managed
directory on all target Linux devices in your network.
Confirm that the files are in the correct directories on all the target Linux devices.
On a target client device, open Google Chrome and navigate to chrome://policy to see all policies that are applied.
You may need to select "Reload Policies" to apply this new policy to the target Linux devices.
You may need to close and reopen Google Chrome before the new policies appear.
Deploying KeeperFill to Windows devices using device management platforms
There are many options to deploy the Keeper Browser Extension (KeeperFill) to browsers on Windows machines including Group Policy, SCCM and Intune.
Sample reference guides are linked below:
Deploying KeeperFill via Group Policy
This section describes how to utilize your Active Directory Group Policy Management, against Google Chrome templates, to deploy the Keeper Browser extension to all PCs in your organization. Please note this is a general guide.
On your domain controller, navigate to the URL, provided below, and download the correct 32 or 64 bit zip bundle. Extract the Google Chrome bundle to your desired location. Ex: C:\temp
Navigate to the directory in which you extracted the Google Chrome Bundle and copy the chrome.admx file located within the
64-bit
\GoogleChromeEnterpriseBundle64\Configuration\admx
directory to C:\Windows\PolicyDefinitions
OR
32-bit
\GoogleChromeEnterpriseBundle\Configuration\admx
directory to C:\Windows\PolicyDefinitions
Navigate to the directory in which you extracted the Google Chrome Bundle and copy the chrome.adml file located within the
64-bit
\GoogleChromeEnterpriseBundle64\Configuration\admx\en-US
directory to C:\Windows\PolicyDefinitions\en-US
OR
32-bit
\GoogleChromeEnterpriseBundle\Configuration\admx\en-US
directory to C:\Windows\PolicyDefinitions\en-US
NOTE: If a different language is desired instead of en-US, please navigate to the directory for the correct language of your choosing. Ex: es-ES
Open Group Policy Manager on your domain controller and expand out your domain -> Group Policy Objects. If you currently do not have a Group Policy created in which you want to utilize for Chrome Policies, proceed to right clicking on Group Policy Objects and create a New Policy.
2. Name the policy something relevant. Ex: “Chrome Policy”
3. Once created, right click the new policy and select Edit.
4. Expand out Chrome Policy -> Computer Configuration -> Policies -> Administrative Templates -> Google Chrome -> Extensions then Right click and Edit the “Configure the list of force-installed apps and extensions”
If this Policy will apply to Users instead of Computers, the Edge Policies you will be expanding will be located under User Configuration -> Policies -> Administrative Templates -> Google Chrome
5. Tick the Enable button, and then click the Show button.
6. Add the following text and click OK.
7. Click Apply, and then click OK
8. Disable Chrome's Built-In Password Manager by navigating to Google Chrome -> Password manager and then Right click and Edit the “Enable saving passwords to the password manager”
9. Tick the "Disabled" button, and then click Apply, and then click OK.
10. Following the same process as steps 8 - 9, direct within Google Chrome Administrative Templates Policy definitions, Disable Chrome's AutoFill capabilities by editing both "Enable AutoFill for addresses" and "Enable AutoFill for credit cards" and setting them to disabled.
11. (Optional) If you would like to disable Developer Tools, to further secure against users attempting to unmask a masked password / credential, still within the Google Chrome Administrative Templates Policy definitions, disable Developer Tools by editing "Control where developer tools can be used" end setting it to "Enabled" and select the Options value of "Don't allow using the developer tools" and click OK.
12. Exit the Group Policy Management Editor, Right Click the OU of your choice, in which contains your Computers or Users, and select Link an Existing GPO.
13. Select the “Chrome Policy” and click “OK”
If you have more than one OU (Organizational Unit) that you would like to Link this new Group Policy to, repeat steps 12 - 13.
For any PC within that OU, the “Chrome Policy” will automatically install the Keeper Security Browser Extension, if Chrome is installed on those PCs as well as disable Chrome's, less secure, built-in password manager and AutoFill capabilities.
On a target client device, open Google Chrome and navigate to chrome://policy to see all policies that are applied. If you applied policy settings on the local computer, policies should appear immediately.
You can also check your extension by navigating to chrome://extensions and ensuring your extensions are being forcefully installed.
You may need to run gpupdate /force, in an elevated command prompt, to apply this new group policy to the PCs.
You may need to close and reopen Google Chrome before the new policies appear.
Deploying KeeperFill via Group Policy
This section describes how to utilize your Active Directory Group Policy Management, against Firefox Policy Templates, to deploy the Keeper Browser extension to all PCs in your organization. Please note this is a general guide.
On your domain controller, download the zip file and extract the Firefox Policy Template file to your desired location. Ex: C:\temp
Navigate to the directory in which you extracted the Firefox Policy Template file and copy the firefox.admx file located within the
\policy_templates_v.(version)\windows
directory to C:\Windows\PolicyDefinitions
Navigate to the directory in which you extracted the Firefox Policy Template file and copy the firefox.adml file located within the
\policy_templates_v.(version)\windows\en-US
directory to C:\Windows\PolicyDefinitions\en-US
NOTE: If a different language is desired instead of en-US, please navigate to the directory for the correct language of your choosing. Ex: es-ES
Open Group Policy Manager on your domain controller and expand out your domain -> Group Policy Objects. If you currently do not have a Group Policy created in which you want to utilize for Firefox Policies, proceed to right clicking on Group Policy Objects and create a New Policy.
2. Name the policy something relevant. Ex: "Firefox Policy”
3. Once created, right click the new policy and select Edit.
4. Expand out Firefox Policy -> Computer Configuration -> Policies -> Administrative Templates -> Firefox -> Extensions then Right click and Edit the “Extensions to Install”
5. Tick the Enable button, and then click the Show button.
6. Add the full hyperlink to the Add-on from Mozilla, like below:
7. Click Apply, and then click OK
8. Now proceed to right clicking and Edit the “Prevent extensions from being disabled or removed”
9. Add the URL again from Step 6 above in the value field.
10. Click Apply, and then click OK
11. Disable the Firefox Built-In Password Manager by navigating direct within Firefox Administrative Templates Policy definitions and then Right click and edit both the Offer to save logins and Offer to save logins (default) and set to Disabled, Click Apply and then OK.
12. Exit the Group Policy Management Editor, Right Click the OU of your choice, and select Link an Existing GPO.
13. Select the “Firefox Policy” and click “OK”
If you have more than one OU (Organizational Unit) that you would like to Link this new Group Policy to, repeat steps 12 - 13.
For any PC within that OU, the “Firefox Policy” will automatically install the Keeper Security Browser Extension, if Firefox is installed on those PCs as well as disable Firefox's, less secure, built-in password manager and AutoFill capabilities.
On a target client device, open Firefox and navigate to about:policies to see all policies that are applied. If you applied policy settings on the local computer, policies should appear immediately.
You may need to run gpupdate /force, in an elevated command prompt, to apply this new group policy to the PCs.
You may need to close and reopen Firefox before the new policies appear.
Deploying KeeperFill via Group Policy
This section describes how to utilize your Active Directory Group Policy Management, against Microsoft Edge templates, to deploy the Keeper Browser extension to all PCs in your organization. Please note this is a general guide.
On your domain controller, go to the Microsoft Edge Enterprise landing page to download the Microsoft Edge policy templates file (MicrosoftEdgePolicyTemplates.cab), by clicking on "Get Policy Files" and extract the contents to your desired location. Ex: C:\temp
Please select and download the correct files in accordance to your organizations environment and preferences.
2. Browse to the directory in which you saved the downloaded MicrosoftEdgePolicyTemplates.zip file. Extract the contents of the MicrosoftEdgePolicyTemplates.zip file to your desired location. Ex: C:\temp
Navigate to the directory in which you extracted the Microsoft Edge Templates zip file and copy the msedge.admx file located within the
\windows\admx
directory to C:\Windows\PolicyDefinitions
Navigate to the directory in which you extracted the Microsoft Edge Templates zip file and copy the msedge.adml file located within the
\windows\admx\en-US
directory to C:\Windows\PolicyDefinitions\en-US
NOTE: If a different language is desired instead of en-US, please navigate to the directory for the correct language of your choosing. Ex: es-ES
Open Group Policy Manager on your domain controller and expand out your domain -> Group Policy Objects. If you currently do not have a Group Policy created in which you want to utilize for Edge Policies, proceed to right clicking on Group Policy Objects and create a New Policy.
2. Name the policy something relevant. Ex: “Edge Policy”
3. Once created, right click the new policy and select Edit.
4. Expand out Edge Policy -> Computer Configuration -> Policies -> Administrative Templates -> Microsoft Edge -> Extensions then Right click and Edit the “Control which extensions are installed silently”
If this Policy will apply to Users instead of Computers, the Edge Policies you will be expanding will be located under User Configuration -> Policies -> Administrative Templates -> Microsoft Edge.
5. Tick the Enable button, and then click the Show button.
6. Add the following text and click OK.
7. Click Apply, and then click OK
8. Disable Edge's Built-In Password Manager by navigating to Microsoft Edge -> Password manager and protection and then Right click and Edit the “Enable saving passwords to the password manager”
9. Tick the "Disabled" button, and then click Apply, and then click OK.
10. Following the same process as steps 8 - 9, directly within Microsoft Edge Administrative Templates Policy definitions, Disable the Edge AutoFill capabilities by editing both "Enable AutoFill for addresses" and "Enable AutoFill for credit cards" and setting them to disabled.
11. (Optional) If you would like to disable Developer Tools, to further secure against users attempting to unmask a masked password / credential, still within the Microsoft Edge Administrative Templates Policy definitions, disable Developer Tools by editing "Control where developer tools can be used" end setting it to "Enabled" and select the Options value of "Don't allow using the developer tools" and click OK.
12. Exit the Group Policy Management Editor, Right Click the OU of your choice, in which contains your Computers or Users and select Link an Existing GPO.
13. Select the “Edge Policy” and click “OK”
If you have more than one OU (Organizational Unit) that you would like to Link this new Group Policy to, repeat steps 12 - 13.
For any PC or User within that OU, the “Edge Policy” will automatically install the Keeper Security Browser Extension, if Edge is installed on those PCs, as well as disable the Edge browser, less secure, built-in password manager and AutoFill capabilities.
On a target client device, open Microsoft Edge and navigate to edge://policy to see all policies that are applied. If you applied policy settings on the local computer, policies should appear immediately.
You can also check your extension by navigating to edge://extensions and ensuring your extensions are being forcefully installed.
You may need to run gpupdate /force, in an elevated command prompt, to apply this new group policy to the PCs.
You may need to close and reopen Microsoft Edge before the new policies appear.
This page describes how to deploy the Keeper Browser Extension with SCCM
This is a general guide in which describes how to utilize SCCM, against Google Chrome templates, to deploy the Keeper Browser extension to all desired PCs in your organization.
Create a new Configuration Item. This can be done within the Configuration Manager console, in the Assets and Compliance work space. Give it a suitable name, like Keeper Browser Extension, and click Next.
Select the appropriate platforms in which this Configuration will apply to and click Next.
Create a new settings configuration by clicking New.
Configure the new settings, as shown below, and click OK.
Name: ExtensionInstallForcelist
Description: Keeper Browser Extension
Key Name: Software\Policies\Google\Chrome\ExtensionInstallForcelist
Value Name: 1 This number is unique. Are you planning on adding other extensions this way, these should be added as 1, 2, 3 and so forth
Now click on the "Compliance Rules" tab and click on New.
Configure the new compliance rules, as shown below, and click OK.
Name: Keeper Security Extension Compliance Rule
Description: Keeper Browser
Within the "the following values:" field, add the value "bfogiafebfohielmmehodmfbbebbbpei;https://clients2.google.com/service/update2/crx" without the quotes.
Tick ON Remediate noncompliant rules when supported and Report noncompliance if this setting instance is not found
Click OK to create the new compliance rule.
Click Close to finish the new configuration item wizard.
In order to deploy this Configuration item, you need a baseline unless you have an existing baseline you would rather use.
If you have an existing baseline you would rather use, proceed to ?.
Create a new Configuration Baseline in the Configuration Manager console, in the Asset and Compliance work space. Give it a suitable name and click Add > Configuration Item.
Add your newly created Keeper Browser Extension Configuration Item, shown within the Available Configuration Items pane and click OK.
Finish creating the new Configuration Baseline by clicking on OK.
Finally!!!! The Configuration Baseline containing the Keeper Browser Extension Configuration Item needs to be deployed. When deploying a baseline, remember to tick ON the Remediate noncompliant rules when supported. Also, consider how often the compliance should be evaluated. For ex: Group policies updates, by default, every 90 minutes. If this is replacing a GPO, consider to lower the policies update interval. Click OK to complete the configuration baseline.
Once the SCCM client has updated its policies, per device, and the Configuration Baseline has run, on a target client device, open Google Chrome and navigate to chrome://policy to see all policies that are applied. If you applied policy settings on the local computer, policies should appear immediately.
You can also check your extension by navigating to chrome://extensions and ensuring your extensions are being forcefully installed.
Deploy the Keeper browser extension to Microsoft Edge using Microsoft Intune
In Azure, open Intune, and then select Devices.
Select Configuration profiles.
Select + Create profile.
For Platform, select Windows 10 and later. For Profile type, select Templates. For Template name, select Administrative templates. Select Create.
For Name, enter "Keeper-Edge". For Description, enter "Keeper Web Extension for Edge Browser". Select Next.
In Configuration settings, open the Microsoft Edge folder by double-clicking it.
Open the Extensions folder by double-clicking it.
Open the Configure which extensions are installed silently setting by double-clicking it.
For Support on: Microsoft Windows 7 or later, select Enabled. For Extension/App IDs and update URLs to be silently installed, paste "lfochlioelphaglamdcakfjemolpichk;https://edge.microsoft.com/extensionwebstorebase/v1/crx". Select OK.
Make sure that the State for your setting is Enabled, and then select Next.
Select Next.
Select Add groups.
Select the Azure AD Groups that you are deploying the Keeper browser extension to. In this example, the group is called "KeeperUsers". Select Next.
Make sure that Groups lists all groups you want to deploy to and select Next.
Select Create.
The policy is now active. If a plan member hasn't enrolled with Intune, they'll be prompted to do so when they sign in on a managed device. After they enroll, the Keeper web extension is installed on Microsoft Edge automatically.
Deploy the Keeper browser extension to Google Chrome using Microsoft Intune
In Azure, open Intune and then select Devices.
Select Configuration profiles.
Select + Create profile.
For Platform, select Windows 10 and later. For Profile type, select Templates. For Template name, select Administrative templates. Select Create.
For Name, enter "Keeper-Chrome". For Description, enter "Keeper Web Extension for Chrome Browser". Select Next.
In Configuration settings, open the Google folder by double-clicking it.
Open the Google Chrome folder by double-clicking it.
Open the Extensions folder by double-clicking it.
Open the Configure the list of force-installed apps and extensions setting by double-clicking it.
For Support on: Microsoft 7 or later, select Enabled. For Extension/App IDs and update URLs to be silently installed, paste "bfogiafebfohielmmehodmfbbebbbpei;https://clients2.google.com/service/update2/crx". Select OK.
Make sure that the State for your setting is Enabled, and then select Next.
Select Next
Select Add Groups
Select the group that you are deploying the Keeper Extension to. Example: KeeperUsers
Make sure that Groups lists all groups you want to deploy to and select Next.
Select Create
The policy is now active. If a plan member hasn't enrolled with Intune, they'll be prompted to do so when they sign in on a managed device. After they enroll, the Keeper web extension is installed automatically.
Configuration settings for Edge Browser Extension
The behavior and settings of the Microsoft Edge extension can be customized through the ExtensionSettings policy on Microsoft Windows devices.
Please see the below link to learn about the various settings can be applied:
Configuration settings for Chrome Browser Extension
The behavior and settings of the Chrome extension can be customized through the ExtensionSettings policy on Windows, Mac and Linux.
Please see the below link to learn about the various settings can be applied:
Persisting KeeperFill settings on virtualized desktops
Some customers virtualize their workforce desktops with tools like VMware or Citrix. For the KeeperFill extension to function properly on such desktops, certain directories may need to be persisted.
This applies to the extensions for Chrome and Edge. For each, three directories within the user's home directory must be persisted, as listed below.
Some directory paths refer to an <Extension-ID>.
Where the ID is referred to, you can opt to persist the entire parent directory, or you can find the ID in the table below.
For Chrome, the ID may be either of the Chrome IDs listed. For Edge, the ID may be either of the Edge IDs listed; or, if you installed on Edge using the Chrome Web store, the ID will be one of the two Chrome IDs.
Browser | Extension ID |
---|---|
Edge | lfochlioelphaglamdcakfjemolpichk OR mpfckamfocjknfipmpjdkkebpnieooca |
Chrome / Edge | bfogiafebfohielmmehodmfbbebbbpei OR kbedblbpfmeicfpadihimgombbafaeeh |
The following three directories should be persisted when using the Edge extension.
Extension Installation:
C:\Users\%username%\AppData\Local\Microsoft\Edge\User Data\Default\Extensions\<Extension-ID>
Indexed DB:
C:\Users\%username%\AppData\Local\Microsoft\Edge\User Data\Default\IndexedDB\chrome-extension_<Extension-ID>
Storage:
C:\Users\%username%\AppData\Local\Microsoft\Edge\User Data\Default\Local Extension Settings\<Extension-ID>
The following three directories should be persisted when using the Chrome extension.
Extension Installation:
C:\Users\%username%\AppData\Local\Google\Chrome\User Data\Default\Extensions\<Extension-ID>
Indexed DB:
C:\Users\%username%\AppData\Local\Google\Chrome\User Data\Default\IndexedDB\chrome-extension_<Extension-ID>
Storage:
C:\Users\%username%\AppData\Local\Google\Chrome\User Data\Default\Local Extension Settings\<Extension-ID>
Deployment of mobile apps through Intune
Keeper's mobile applications for iOS and Android are native apps that support all vault capabilities including record management, sharing management and autofill. Deploying the app to end-users is possible either through the public app store download or through mobile device management platforms.
Keeper for iOS can be installed directly from the App Store:
Keeper for Android can be installed from the Google Play application at the link below:
Keeper can be easily deployed to users through Microsoft Intune.
To deploy the iOS app via Intune to your users, follow the steps below:
(1) From Intune, Select app type of "iOS store app"
(2) Search for Keeper
(3) Select the Keeper Password Manager app by Callpod Inc.
(4) Click Create
Notes regarding the iOS app:
The publisher shows as "Callpod Inc." which is the original holding company for Keeper Security. This is normal.
The Appstore URL is: https://apps.apple.com/us/app/keeper-password-manager/id287170072
If you need the Bundle ID, it is D4D2433BGC
(Case Sensitive)
To deploy the Android app via Intune to your users, follow the steps below:
(1) Select app type of "Android store app"
(2) Enter the below information, feel free to customize the description.
Attribute | Value |
---|---|
Name | Keeper Password Manager |
Description | Keeper automatically generates strong passwords, stores them in a secure digital vault accessible from any device, and autofills them across all of your sites and apps. Keeper’s powerful encryption protects your passwords and sensitive information from data breaches, ransomware, and other cyberattacks. |
Appstore URL | |
Minimum operating system | Android 8.0 (Oreo) |
Category | Productivity |
Show in portal | Yes |
Developer | Keeper Security |
(3) Create the application
Notes regarding the Android app:
If you need the identifier, it is com.callpod.android_apps.keeper
Deploy Keeper to mobile phones
Other Policy Driven Deployment Tasks
As a general security practice, we recommend that Enterprise customers limit the ability of end-users to install unapproved 3rd party browser extensions. Browser extensions with elevated permissions could have the ability to access any information within any website or browser-based application. Please refer to your device management software to ensure that Keeper is allowed, and unapproved extensions are blocked or removed.
The Keeper Password Importer tool is typically downloaded by the user during account creation on the Web Vault. If you do not permit the installation of applications on end-user devices, you can preload the app using the binaries located below:
Password Importer (Windows): https://keepersecurity.com/pwd_importer/win32/keeperimport.exe
Password Importer (Mac): https://keepersecurity.com/pwd_importer/Darwin/KeeperImport.zip
Often times, Enterprise customers would like to automatically disable the less secure, built-in password saving features of web browsers. There are several methods of managing this as described in this section.
Google provides .adm and .admx files (.admx is a newer .xml file type) to make it easier to manage the Chrome browser using Group Policy. In G Suite and Chrome Enterprise environments, it is enabled via the Google Cloud platform using one of the below methods:
AD managed Chrome – Google provides adm and admx files that are incorporated into a GPO
Chrome Mac Policies and Quickstart – pushed via MDM tools (JAMF, etc...)
Chrome Linux policies and Quickstart – pushed via MDM tools (Ivanti, etc...)
Chrome G Suite managed – Native management for G Suite subscribers
Chrome Enterprise managed – centralized Cloud based Management for Windows, Mac, or Linux computers – agnostic to directory services
Similar to Chrome, Mozilla provides .adm and .admx files to manage Firefox using Group Policy. Mac-based systems are provided a .pkg file and are managed via JAMF, etc. Linux users are provided a policies.json file.
Edge for Business is now available for Windows and Mac. Group policy is managed through .adm and .admx files on Windows, and .plist on Mac.
The new Edge for Business now supports "Internet Explorer Mode". We recommend using this mode for any IE browser requirements within your organization.
If legacy Internet Explorer is absolutely required by your users, management of password saving features can be disabled under traditional GPO found under:
User Configuration > Policies > Administrative Templates > Windows Components > Internet Explorer
Then disable “Turn on the auto-complete feature for user names and passwords.”
Policy Requirements for IE11 Trusted Sites
Customers who login to Keeper with SSO, or customers who are on corporate networks that deploy group policies for Internet Explorer, ensure that the following entries exist in your Trusted Sites settings under Tools > Internet Options > Security.
US / Global Customers (USA East/West):
keepersecurity.com *.keepersecurity.com
EU Data Center Customers (Ireland, London, Frankfurt):
keepersecurity.eu *.keepersecurity.eu AU Data Center Customers (Sydney): keepersecurity.com.au *.keepersecurity.com.au
CA Data Center Customers (Canada): keepersecurity.ca *.keepersecurity.ca
JP Data Center Customers (Tokyo): keepersecurity.jp *.keepersecurity.jp GovCloud Data Center (US): keepersecurity.us *.keepersecurity.us
Enterprise customers must push group policies to end-users with these Trusted Sites in order to fully function with SSO and other critical features.
Links to end-user guides for mobile and desktop devices.
Once you've deployed Keeper to your users, they can reference our many end-user guides listed below for step-by-step instructions for Keeper's web, desktop and mobile applications.
Web Vault & Desktop App Keeper Web Vault and native Desktop app for Mac, PC, Linux.
Browser Extensions KeeperFill browser extensions for all web browsers including Chrome, Edge, Firefox, Safari, Brave and Opera.
Enterprise End-User Setup (Master Password Login) End-user guide specifically for users who login with a Master Password.
Enterprise End-User Setup (SSO Login) End-user guide specifically for users who login with SSO solutions such as Azure.
KeeperFill for Apps Native application autofill, auto-type keystroke automation and shortcut filling.
KeeperChat Native secure messaging application for iOS, Android, Mac and PC.
Sharing Guide focused on the various ways to share content in Keeper.
Record Types Usage guide on record templates and custom fields.
Importing A series of guides for migrating existing passwords from CSV files, or from other products such as 1Password, LastPass, KeePass, Dashlane, Bitwarden and many more.
Passkeys This is a guide to managing Passkeys in your vault. Passkeys are FIDO credentials that replace passwords with cryptographic key pairs for phishing-resistant sign-in security.
This video provides a general overview of the Keeper platform for new end-users.
Additional videos for getting started with Keeper are available at the page below:
https://www.keepersecurity.com/getting-started.html
Do you require any additional documentation or user guides with your branding? Let us know. Email: business.support@keepersecurity.com.
The Keeper Admin Console provides administrative controls, user onboarding, reporting and auditing.
Follow the links below to access the Keeper Admin Console: https://keepersecurity.com/console (US) https://keepersecurity.eu/console (EU) https://keepersecurity.com.au/console (AU) https://keepersecurity.ca/console (CA) https://keepersecurity.jp/console (JP) https://govcloud.keepersecurity.us/console (US Gov)
(Or open KeeperSecurity.com > Login > Admin Console)
Business customers login to the Keeper Admin Console to manage their environment. In the Admin Console, you can invite users, configure provisioning methods (SSO, SCIM, AD, etc..), set role policies, manage teams, run reports and monitor security. The Admin Console scales to organizations of any size.
When you first log in to the Admin Console, you will land on the Dashboard which will provide an overview of high level data on your user activity and overall security status.
The Dashboard provides oversight of the following:
Top Events and link to Timeline Chart
Security Audit Overall Score
BreachWatch Overall Score
User Status Summary
To download a user status report that displays a list of all users including: Email, Name, Active/Invited status, Locked/Disabled status, Blocked/Pending Transfer, last login, nodes, roles, and teams, click on the (...) and then click Download.
From the Admin screen, you can access Nodes, Users, Roles, Teams, 2FA settings, and User Provisioning.
Nodes provide a method to organize your users, roles, teams and administrators into distinct groupings, similar to organizational units in Active Directory. The administrator can create nodes based on location, department, division or any other structure that makes sense for your organization. Nodes can have completely independent sets of users, role enforcement policies, administrators and provisioning methods.
By default, the top-level node, or Root Node is set to the organization name and all Nodes can be created underneath. Depending on your organization you may or may not need to set up nodes.
Small teams may not need multiple nodes and will be able to administer users, roles and teams from the default root node only.
Larger teams may benefit from organizing by location or department across multiple nodes.
Users and Teams within different nodes can have levels of visibility and sharing capability within the Keeper Vault. If full node isolation is required between users of different node trees, please contact Keeper support to activate this special backend feature.
For more information on node isolation click here.
All employees or users you choose to deploy Keeper to are responsible for managing their own encrypted vault. Every user's vault can be made up of private records or shared records. Users can be provisioned many different ways. Users can be required to set up a Master Password or they can be provisioned and authenticated through your SSO provider. For more information about provisioning, read the User and Team provisioning section.
We recommend separating your personal, private records from your business records by creating two separate user accounts. All business end-users receive a free Keeper Family Plan. When enforcements are applied to the organization (such as Account Transfer privileges), only the business vault is affected.
Roles provide the organization the ability to define enforcements based on a user's job responsibility as well as provide delegated administrative functions. Learn more about roles.
Permissions for Administrators are also configurable here which toggle whether an Admin can manage nodes, users, teams, roles, SSO, AD Bridge, User Account Transfer and Run Reports.
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. For more information, refer to Account Transfer.
The purpose of creating Teams is to give users the ability to share the records and folders within their vaults with logical groupings of individuals. The administrator simply creates the team, sets any Team Restrictions (edit/viewing/sharing of passwords) and adds individual users to the team. Teams can also be used to easily assign Roles to entire groups of users to ensure the consistency of enforcement policies across a collective group of individuals.
As you prepare to rollout Keeper to your organization, consider one of the following options when inviting users:
Access to additional Secure Add-On functionality can be accessed through the Admin Console "Subscriptions" and "Secure Add Ons" screen:
For a more thorough overview of Keeper Enterprise watch the video below.
Keeper's node architecture scales for organizations of all sizes
Keeper's "node" architecture provides customers with a way to organize users into distinct groupings, similar to organizational units in Active Directory. The administrator can create nodes based on location, department, division or any other structure. A node is typically associated with different provisioning methods and identity providers.
By default, the top-level node, or Root Node is set to the organization name, and all Nodes can be created underneath the Root Node.
Smaller organizations might choose to administer keeper as single level. In this scenario, all provisioned users, roles, and teams are accessed from the default Root Node. Larger organizations benefit from organizing locations or departments into multiple nodes. Users can then be provisioned under their respective node and have roles configured to match the specific needs of the business. One of the advantages in defining multiple nodes is to help support the concept of delegated administration. A delegated administrator can be granted some or all of the Administrative permissions but only on their respective node (or sub nodes) to help reduce the administration load on the primary Keeper Administrators.
When rolling out Keeper alongside an SSO identity provider, we require that those users are located within a node. This way, you can have any number of nodes associated with one or more SSO identity providers.
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 within the Keeper Admin Console.
Watch the video below to learn about nodes and organizational structure.
To manually create Nodes and Sub Nodes, select the button and click Add Node. The Add Node window will appear. Enter the name of the Node 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 selecting the nodes on the Node selector. To navigate to the root-node or top level, select the business name (e.g. The Company) in the navigation tree.
When users are in the vault and sharing records, Teams and Users are visible in the auto-suggest field by all users regardless of what node the team or user resides in.
If the desire is to restrict visibility and control whether or not the usernames and teams associated with other parallel (a.k.a. "sibling") nodes will be hidden in the auto-suggestion dropdown menu when setting up sharing of folders, "node isolation" will need to be enabled. With node isolation enabled, "children" of a node can see each others's associated users/teams as well of those above it (parent nodes).
When a node is isolated, users and teams in the parent node will be visible. Node isolation only limits visibility between parallel nodes.
Note: Any user who is an a role with admin rights having Share Admin permissions will also appear in auto-suggestion drop-downs, if the role has management permissions over the node for the currently logged-in user.
Turning on node isolation can be accomplished using the Keeper Commander CLI, or by opening a support ticket with Keeper support.
To find a list of nodes and node IDs, use the enterprise-info
command:
To enable node isolation for a specific node, use the enterprise-node
command:
After node isolation is enabled, a visual indicator will show in the console:
Node Isolation affects the ability for users to share records and folders outside of their node tree. For example, when sharing a record from the vault, the auto-suggestion list is restricted.
If you are a Managed Service Provider (MSP) and you are considering the use of Nodes for different customers, we recommend you instead use the Keeper MSP product which provides a specialized set of features for deploying Managed Companies. The Keeper MSP user guide can be found here: Keeper MSP Guide
Within a Node, the "Role" is defined that can enable administrative permissions.
If nodes are enabled either via Active Directory integration or configured manually from the Admin Console, the placement of the Role within the Node Tree is important with regards to where the administration permissions begin. Placement of the role at the top level will allow the Admin permissions to flow down to any of the sub-nodes if the Cascade Node Permissions attribute is checked within the "Administrative Permissions" setting of the role. If the role is placed in a sub-node with the Cascade Node Permissions attribute checked then the permissions apply to that node and its sub-nodes only. If the Cascade Node Permissions attribute was not checked then the role permissions are only applied the the specific node to which the role belongs.
Each node and sub-node within the Keeper deployment can provision users with different provisioning methods. For example, Finance and Sales & Marketing can use Single Sign-On, and Engineering can use Active Directory.
A node can contain one or more provisioning methods. For example, you can provision users with Active Directory and authenticate the users with Single Sign-On (SAML 2.0) integration.
Navigate to the Node that you would like to provision users. Then click on the "Provisioning" tab and click "Add Method".
Enhanced Risk Visibility With Keeper’s Risk Management Dashboard
The Keeper Risk Management Dashboard is a powerful feature of the Keeper Admin Console that provides comprehensive security posture information covering end-user deployment, utilization, cloud configuration, and event monitoring. This critical data helps administrators ensure that risks are remediated and compliance is enforced effectively.
Keeper's Risk Management Dashboard is an upcoming feature. If you would like to be added to the beta list, contact beta@keepersecurity.com.
Keeper’s Risk Management Dashboard delivers a risk assessment score based on key metrics within an organization’s Keeper environment. These metrics include:
Users who have created records
Users who have logged in within 30 days
Users who have accepted Keeper invitations
Users with Two-Factor Authentication (2FA) protected vaults
Only displays for organizations that are not SSO enabled as 2FA is traditionally done at the SSO level. Keeper’s Risk Management Dashboard automatically detects SSO environments and tailors the risk management level to your configuration.
The Users Who Have Created Records metric indicates the number of users within your organization that are actively using Keeper and creating records.
Predefined filters allow an Administrator to view users with no records created and users who have records created.
Individual users can be clicked to view a per user detail.
A downloadable CSV file is also available for further data analysis by clicking Download Report.
The Users Who Have Logged In Within 30 Days metric provides an indicator that shows users who have recently used Keeper within your organization.
Predefined filters allow an Administrator to view users who have and have not been active recently.
Individual users can be clicked to view a per user detail.
A downloadable CSV file is also available for further data analysis by clicking Download Report.
The Users Who Have Accepted Their Keeper Invitations metric allow Administrators to measure and keep track of users who have accepted their Keeper Invitation and also allows Administrators to re-invite users who have not accepted invitations. This ensures maximum coverage for your organization.
Predefined filters allow an Administrator to view invited and active users as well as re-inviting users by clicking Resend All Invites.
Individual users can be clicked to view a per user detail.
A downloadable CSV file is also available for further data analysis by clicking Download Report.
The Users With 2FA Protected Vaults metric provides an indicator that shows users who have enabled 2FA to login to their individual Keeper vaults.
Predefined filters allow an Administrator to view users who have and have not enabled 2FA for their vault.
Individual users can be clicked to view a per user detail.
A downloadable CSV file is also available for further data analysis by clicking Download Report.
The Risk Management Dashboard will display a license count during the first two weeks of onboarding after activating your first user and allow the Administrator to purchase more licenses by clicking Add Users.
A Low license alert will display when an organization has reached 90% of used licenses and allow the Administrator to purchase more licenses by clicking Resolve.
Keeper’s Risk Management Dashboard leverages an outlined set of Keeper Security Benchmarks to keep organizations compliant and safe. With an emphasis on enforcing least privilege and ensuring organizations embrace the highest level of security, Keeper consistently updates these benchmarks to ease security adoption and provide important information for admins.
Keeper Security Benchmarks in the Keeper Risk Management Dashboard are broken into three main categories:
Critical Items to Resolve
Completed
Ignored
If a benchmark is not applicable to your organization, an Administrator may choose to ignore it.
Keeper will periodically update recommendations for Keeper Security Benchmarks if a feature is updated or a recommendation is updated due to security advances.
When a benchmark is updated, a previously resolved item will become unresolved until configuration changes are made to adhere to the current recommendation.
The Security Benchmark tab is viewable in the default view. For information about all Keeper Security Benchmarks, click About Keeper Security Benchmarks.
Each benchmark will have a custom action to remediate the issue displayed.
In this example, clicking Add Back-up Admin will take the Admin to the Keeper Administrator role policy.
Clicking Ignore Benchmark will add the benchmark to the "Ignored" list.
The Security Alerts tab will show a subset of Keeper's Advanced Reporting and Alerts Module's (ARAM) alerts. The subset is based on items that are considered high risk alerts.
Clicking View Reporting & Alerts will take the Administrator to the ARAM module in the Keeper Admin Console to view and take action on all alerts.
Each alert is clickable and will display:
Number of occurrences of the alert in the last 30 days
Sorting options for:
Name
Number of Occurrences
Recent Occurrences
Trend percentage based on current 30 days against the previous 30 days
Option to download a csv report of the trend for further data analysis
Individual clickable user details to display information about an individual user
A PDF summary report can be generated by clicking Download Report.
Benchmark detail view will provide more instruction and remediation actions in future updates
Security alert trends do not properly fill. Data will be backfilled shortly.
User provisioning is flexible and powerful with Keeper Enterprise
Keeper Enterprise can provision users through many different methods that are described here in detail.
Manual Provisioning through the Keeper Admin Console
Single Sign-On (SAML 2.0) Authentication and Provisioning with Keeper SSO Connect
Active Directory / LDAP Provisioning with the AD Bridge
Okta, Azure AD, Google Workspace, Ping, OneLogin Provisioning with SCIM
API Provisioning with SCIM
Email Auto-Provisioning
CLI Provisioning with Commander SDK
Watch the video below to learn more about provisioning users.
If you are deploying Keeper to a small number of users, or if you are only deploying Keeper to a team within a large Enterprise, using Keeper's "manual provisioning" or "bulk upload" may be sufficient.
See: Simple Provisioning through the Admin Console
For organizations that are managing an on-prem AD environment, we recommend using the Keeper Active Directory Bridge application ("AD Bridge") for mapping node structure and adding Users, Teams and Roles.
See: AD Bridge
The AD Bridge software is used strictly for provisioning of users. To authenticate your users against AD, we recommend using AD FS with the Keeper SSO Connect service.
See: SSO Connect Cloud
For organizations who are already utilizing federated services, Keeper SSO Connect provides real-time authentication and Just-In-Time (JIT) provisioning. If you would like to automatically assign users to Roles and Teams through AD security groups or other custom LDAP queries, the Keeper AD Bridge software can also be utilized.
See: AD Bridge with SSO Connect Cloud
Many Keeper Enterprise customers have either migrated to a cloud-based identity store or they are in the process of migration, either through AD->Azure syncing or other mirroring techniques.
If your organization utilizes a cloud-based directory, you have 3 choices for deployment:
Keeper SSO Connect is a powerful feature of Keeper Enterprise which supports real-time authentication and provisioning of user accounts through any SAML 2.0 compatible identity provider. Azure AD, AD FS, Okta, JumpCloud, Google Workspace, Ping, OneLogin and all other identity providers are compatible with Keeper.
SSO Connect Cloud supports Just-In-Time ("JIT") provisioning to make the user onboarding process simple and straightforward.
See: SSO Connect Cloud
The SCIM provisioning protocol is supported by most modern identity providers including Azure, Okta, Google Workspace and many others. Google calls it "User Provisioning". Okta and Azure call it "Automated Provisioning". Keeper's SCIM implementation can provision a user account, de-provision an account, create a team, assign a user to a team, remove a user from a team.
See: Entra ID / Azure AD, Google Workspace, Okta, JumpCloud and generic SCIM provisioning docs
SCIM and SSO can be combined to provide real-time authentication, provisioning of accounts AND the ability to create teams, assign users into teams, de-provision users, etc. Entra ID / Azure AD, Okta, Google Workspace, JumpCloud, Ping and many other modern identity providers support a combination of these two methods.
See: SSO Connect Cloud
Universities and large organizations who have fragmented user directories or do not wish to integrate Keeper with SSO or SAML protocols can use Keeper's Email Provisioning method for a mass deployment.
Email provisioning essentially reserves a domain name (e.g. iastate.edu) and will automatically provision a user based on their domain (with email verification) into a default role. No work needs to be done by the Keeper Admin once the initial configuration is set up.
If you have a special integration requirement such as automatically provisioning and creating user vaults through a developer API or other custom integration needs, Keeper provides several SDK options. Visit the Commander SDK platform for Python, .Net, PowerShell, Java and other toolkits available for customers.
See: Commander SDK
Configure a custom invite email and logo before inviting users
Prior to adding users to Keeper we recommend uploading your company logo to the vault and customizing the email invitation that will invite your employees to create their Keeper Vault. These configurations are highly recommended as they have shown to help with quick user adoption of Keeper's software.
For security reasons, custom email invitations are only allowed for reserved domains. If you are sending invitations to users on domains that are not currently reserved to your tenant, please follow this guide.
To customize the email language, subject and logo, select Configurations then Edit next to "Email Invitations".
The email invitation template supports customization of the following four attributes:
Subject
Message Heading
Message Body
Download Button Text
Markdown Syntax
The body of the message supports plain text as well as basic markdown syntax. Example of markdown syntax:
For more information on the markdown language supported by Keeper, visit the following:
Custom Email - Markdown LanguageCustom Email Template on Admin Console:
The example above produces the following email invitation:
For security reasons, a custom email invitation can only be sent to a user if the domain has been reserved to the tenant. If the email domain of the recipient is not reserved, the user will receive Keeper's default email invite, which looks like the below:
To ensure that your domains are reserved, please see the Domain Reservation documentation page.
When creating a custom email invitation, the template is applied to users at the root node and all child nodes.
If you would like to have a different email invitation on a sub-node, you can use Keeper Commander's enterprise-node command to set a custom template for each node.
Documentation for this feature is linked here.
Additional info for creating and inviting users with Commander are documented here.
Upload your unique company logo to the console so it will appear in the Keeper Vault header when users are logged into their Keeper Web Vault and Desktop App. It will also appear in your users' One-Time Share invites. To upload your logo, select Configurations and Edit next to "Company Logo".
If you would like to have a different vault logo and one-time share logo on a sub-node, you can use Keeper Commander's enterprise-node command to set a custom logo for each node.
Documentation for this feature is linked here.
For MSPs, a Managed Company can be associated with a node. Using this method, a custom logo file can be added for each node.
When formatting the body message of your custom email templates, Keeper supports plain text as well as basic markdown syntax. This document will go over the markdown syntax supported by Keeper
To create a heading, add the hash symbol (#
) in front of a word or phrase. The number of hash symbols you use corresponds to the heading level.
Markdown Syntax | Font Size |
---|---|
| Heading of font size 32 |
| Heading of font size 24 |
| Heading of font size 19 |
| Heading of font size 16 |
| Heading of font size 13 |
| Heading of font size 11 |
Sentences are plain text and multiple sentences can be grouped together to form a paragraph.
Do not indent paragraphs with spaces or tabs as it can cause formatting issues
Markdown Syntax | Rendered Output |
---|---|
This is a one line paragraph |
|
This is a multiline paragraph. I like formatting |
|
To create a line break or new line, press return
or enter
at the end of the line. Pressing return
or enter
multiple times will create multiple line breaks
Markdown Syntax | Rendered Output |
---|---|
This is an example. Of a linebreak. |
|
This is an example. Of Multiple linebreaks. |
|
To bold text, add 2 asterisks (**
)
To italicize text , add 1 asterisk (*
)
Markdown Syntax | Rendered Output |
---|---|
This is **bold** | This is bold |
This is *italics* | This is italics |
This is **bold** and *italics* | This is bold and italics |
To create a link, enclose the link text in brackets (i.e. [Keeper]
) and place the URL in parentheses (i.e. (https://
keepersecurity.com))
. You can also format (bold or italics) the link as needed.
Markdown Syntax | Rendered Output |
---|---|
| Visit Keeper! |
To embed images from URL, add an exclamation mark (!
), followed by the word Image
in brackets, and the path or URL to the image asset in parentheses:
Provision users and create teams from the Keeper Admin Console.
To add users manually through the user interface, follow these steps.
Login to the Admin Console.
Select the Node that the user will belong to. By default, the top level root node is selected.
From the Users Tab, select the + Add Users button.
Enter the Name and Email of the user and then click Add.
The user will receive an email to create their vault with a Master Password or SSO, depending on what node they are located in.
You can also import many users at once via a comma-delimited text file (.csv).
The file format for a CSV file upload is 3 columns: Email Address, Name, Role.
The Role field is optional. Keeper recommends you create a default, "General Employee" role and all users imported will be automatically applied to that role, for example:
Example File (using Excel)
Convert the file to .csv by selecting File > Save As... > (.csv)
A few important notes about preparing a CSV file for user importing:
Ensure that the file does not contain a header row.
Only roles without Admin Permissions can be imported. Any row containing a Role that has Administrative Permissions will be skipped.
Don't populate a default role in the column. This is not necessary and will generate error messages. Simply leave the Role blank to inherit the default ole.
If you include a Role name, make sure it matches the exact spelling in the Admin Console.
From the Admin Console, select Admin > Users.
Select the + Add Users.
Drag and drop a prepared CSV file with 3 columns: Name, Email and Optional Role.
After dragging and dropping the file, you will be asked to review the changes. Note the default role will appear empty. Click Add to complete the import.
Keeper AD Bridge supports automatic provisioning of nodes, roles, teams and users across any size Active Directory environment.
The Keeper Bridge is an enterprise-class service application that supports the ability to automatically sync Nodes, Users, Roles and Teams to your Keeper Enterprise account from an Active Directory service. To activate and install the Keeper Bridge, follow the steps below:
Login to the Admin Console.
Create a Node (under the root node) to sync with your Active Directory.
Visit the Provisioning tab and select Add Method and then Active Directory Sync.
Download the Keeper Bridge and proceed with setup.
For detailed Keeper Bridge setup and installation instructions see our Keeper Bridge Guide.
Keeper Bridge supports single and multi-domain, multiple forest domains and other complex environments. The Bridge also supports high-availability mode and a variety of custom configuration options based on your AD/LDAP environment. The Keeper AD Bridge Guide documents the full setup process.
The Keeper Bridge does not authenticate users into their vault with their Active Directory password. For seamless user authentication, consider our Keeper SSO Connect add-on as described in the next section which authenticates against Active Directory via AD FS.
Automated Team provisioning requires the Keeper Administrator to authenticate on the Keeper Bridge. The Bridge will poll for users who have created their Keeper account after invitation, then the Bridge will encrypt the Team Key with the user's public key, and distribute the Team Key to the user. Once any member of the team logs into the Vault, all members of that team are approved.
Once the Active Directory Bridge is syncing, we recommend not making manual user or team changes directly on the Admin Console. Delegate all user and team provisioning to the bridge through Active Directory. Role enforcement policy changes should still be made on the Admin Console
Keeper AD Bridge supports automatic provisioning of nodes, roles, teams and users from any LDAP service.
The Keeper Bridge is an enterprise-class service application that supports the ability to automatically sync Nodes, Users, Roles and Teams to your Keeper Enterprise account from an LDAP service. To activate and install the Keeper Bridge, follow the below steps:
Login to the Admin Console.
Create a Node (under the root node) to sync with your Active Directory.
Visit the Provisioning tab and select Add Method and then select LDAP Sync.
Download the Keeper Bridge and proceed with setup.
For detailed Bridge setup and install instructions see our Keeper Bridge Guide.
The Keeper Bridge does not authenticate users into their vault with their LDAP password. For seamless user authentication, consider our Keeper SSO Connect add-on as described in the next section which authenticates against Active Directory via AD FS.
Automated Team provisioning requires the Keeper Administrator to authenticate on the Keeper Bridge. The Bridge will poll for users who have created their Keeper account after invitation, then the Bridge will encrypt the Team Key with the user's public key, and distribute the Team Key to the user. Once any member of the team logs into the Vault, all members of that team are approved.
Once the Keeper Bridge is syncing, we recommend not making manual user or team changes directly on the Admin Console. Delegate all user and team provisioning to the bridge through the LDAP Directory. Role enforcement policy changes should still be made on the Admin Console
Keeper supports just-in-time automatic provisioning and seamless authentication with any identity provider
Keeper SSO Connect® Cloud leverages Keeper’s zero-knowledge security architecture to securely and seamlessly authenticate users into their Keeper Vault and dynamically provision user vaults to the platform. Keeper supports all popular SSO IdP platforms such as Okta, Microsoft Entra ID / Azure AD, Google Workspace, Centrify, Duo, OneLogin, Ping Identity, JumpCloud and many more.
Keeper supports both IdP-initiated login flows and SP-initiated flows. Just-in-time provisioning allows admins to quickly and easily roll out Keeper to users using a few simple steps:
Configure the SAML 2.0 connection with "Enable Just-In-Time Provisioning" selected
Assign your users to the Keeper application in your identity provider
Direct your users to simply login to Keeper with their email address or SSO domain.
If your domain is reserved to your Keeper tenant, users will be automatically routed through your identity provider as seen in the below screenshots.
Any user who is provisioned through JIT will be assigned to the default role enforcement policies for the node which they are provisioned in.
The user's vault will be immediately provisioned and the user will be walked through the onboarding process which can include importing passwords, installing the KeeperFill browser extension and setting up two-factor authentication.
The exact steps of the onboarding process depend on the user's assigned role enforcement policy. Onboarding can also be disabled completely.
After the onboarding is complete, users can begin using Keeper and managing their vault.
For a full step by step guide on setting up your SSO Connect Cloud environment, see the SSO Connect Cloud guide.
See the SSO Connect Cloud admin guide https://docs.keeper.io/sso-connect-cloud/
Keeper supports SAML 2.0 Authentication and SCIM provisioning with the Okta platform.
This guide covers Okta Automated Provisioning with SCIM. Before you begin the setup, we recommend that you first activate Keeper's powerful SSO Connect integration with Okta that provides realtime user authentication and Just-In-Time provisioning.
Please review the Okta SSO implementation guides:
SSO Connect Cloud (Recommended): Click Here
Keeper/Okta automated provisioning supports the following features:
Create users in Keeper
Update user attributes
Activate or deactivate users (locks or unlocks them in Keeper)
Creates teams in Keeper (from Okta groups)
Seamless authentication
When provisioning users, Okta directory is mapped to a single Keeper node. Okta creates users and groups in a pending state and new users will receive an email invitation prompting them to create a Keeper account.
To setup Keeper user provisioning with Okta, you need to have access to the Keeper Admin Console and an Okta Admin account.
If you haven't added Keeper to your Okta Admin, Select the Applications tab and then select Browse App Catalog and search for "Keeper".
Open the Keeper Admin Console and navigate to a node which should be synchronized with your Okta account. If you are using SAML 2.0 authentication, add the SCIM connector to the same node. Select Add Method > SCIM (System for Cross-Domain Identity Management) and click Next.
Copy the URL.
Navigate back to your Okta Admin account and paste the URL from Keeper into the Base URL of the Okta API Integration screen.
Switch back to the Keeper Admin Console click Generate.
Immediately copy the generated token to your clipboard then click Save (important to Save now)
Note: If you click "Test" on the Okta side before saving the token in Keeper, the test will fail.
Paste the token into the Okta console.
Select Save on Okta to finish the Keeper provisioning setup.
In the Okta Provisioning tab, click Edit under Provisioning to App. Enable "Create Users", "Update User Attributes", "Deactivate Users" capabilities, then click Save.
Assign the app to a user from Okta, and after a short period, select the Full Sync button in the Keeper Admin Console.
Please ensure that the username and email for users remains the same during user assignment.
In the Keeper Admin Console, users will show in either an "Invite" state or a "Pending transfer acceptance" state (if Vault Transfer policy is active for the default role).
The user will receive an email invitation (unless email invites are disabled at the Role Policy level). Clicking the invite link will allow the user to login with Okta and complete the provisioning process.
Alternatively, the user can simply login to Keeper with their email address or Enterprise Domain and complete the sign-in process.
After the user has created their Keeper vault, the status on the Admin Console will change to "Active".
Keeper supports Team provisioning through Okta "Push Groups".
Push Groups are added as Keeper Teams within the Admin Console
Users who are assigned to Push Groups are assigned to the Keeper Team
Keeper Teams can then be provisioned to Shared Folders
Keeper Teams can be mapped to Role Policies through Team-to-Role Mapping
Processing of Team and Team-User assignments must be completed locally on the Admin Console or through one of Keeper's automated tools.
After pushing Users or Teams to the Keeper Admin Console, simply login or click "Full Sync" to process and approve the transactions.
A notification will appear along the bottom of the screen when team approvals have been processed.
Team and user approvals can also be performed by the Keeper Automator service or using Keeper Commander with the team-approve
command.
Okta Automated provisioning maps Push Groups to Keeper Teams. To automatically assign different teams to different Keeper Roles, you can use our "Team to Role mapping" feature.
From the Roles screen, simply add the Team to the role.
To use team-to-role mapping, administrators simply assign a role to an entire “Team,” as opposed to individual users and use role enforcements to establish different requirements and restrictions for each team. Note that Team-Role mapping cannot be used with Administrative roles.
If you click the "Test" button before saving the SCIM provisioning method in the Admin Console, the test will fail. Copy the token then click Save.
Keeper users are identified by their email, therefore when assigning the Okta user to the Keeper app, make sure the User Name contains a valid email address.
Groups assigned to the Keeper Okta application are not created as teams in Keeper by default; only group members are pushed to Keeper. To sync groups and group memberships to Keeper you need to add the groups to "Push Groups" in the Keeper Okta application.
When synchronizing group memberships from Okta, Keeper creates team memberships which are not immediately visible. For the provisioned users to become actual team members, the user must register with Keeper, accept the invitation and be receive approval for group entry by a Keeper Administrator or auto-approved by an existing Keeper team member logged into their Web Vault.
When creating a new Push Group, the Okta admin will need to manually push the groups to complete group synchronization at least one time.
When setting up User and Team SCIM provisioning with Okta, make sure of the following:
Ensure that you have assigned the Okta groups as Push Groups in the SAML application
When you invite a user from Okta or assign a user into a group that has been provisioned as a Push Group, Okta will send the request to Keeper to either invite a user to join, or to add a user to a team, or to create a team.
If the user does not exist yet in Keeper, they will receive an invite to sign up (or they can use just-in-time provisioning)
After the user has created their Keeper account, the user will not yet be assigned into a Keeper team until one of a few things happen: (a) Admin logs into the Admin Console > Click on "Full Sync" from the Admin screen (b) A user from the relevant team logs into the Web Vault or Desktop App (c) Admin runs team-approve from Keeper Commander Sharing an encryption key (e.g. Team Key) can only be performed by a user who is logged in, and has access to the necessary private keys.
The Keeper Automator service as of version 3.2 performs instant approval of Teams and team assignments. More information about the Automator service is located here.
If you receive the error "Unable to update Group Push mapping target App group xxx: Error while updating user group membership... Not Found"
This error can occur if the Keeper Enterprise User ID is different between the Keeper backend and the Okta admin. This can occur if you delete and re-create a user's account from the Keeper side, instead of properly creating the user from a SCIM invitation. In this case, Okta does not have knowledge of the user's new Enterpriser User ID.
To resolve this issue, you need to simply remove the application assignment to Keeper, and re-assign the user to the Keeper application.
Please visit the Okta + Keeper SSO Connect guide for sign-on authentication.
SSO Connect Cloud (Recommended): Click Here
SSO Connect On-Prem: Click Here
Keeper supports SAML 2.0 Authentication and SCIM provisioning with the Azure AD / Entra ID platform.
Keeper supports the ability to provision users and teams from Microsoft Azure AD or other identity platforms using the SCIM protocol. For customers that utilize Azure AD, users can be provisioned to the platform and automatically added to Teams to receive shared folders.
Before setting this up, we recommend that you consider activating Keeper's powerful SSO Connect integration with Azure AD that provides realtime user authentication and Just-In-Time provisioning.
View the full SSO Connect Cloud setup guide: https://docs.keeper.io/sso-connect-cloud/
If you have already setup Keeper SSO Connect Cloud or you don't have the need for SSO, proceed to Step 1 in the Configuration Steps below.
Keeper/Azure provisioning integration supports the following features:
Creates users in Keeper
Updates user attributes (display name in Keeper)
Deletes users (locks users in Keeper)
Creates teams in Keeper (from Azure groups)
Adds or removes users to groups (to teams in Keeper)
When provisioning users, Azure AD is mapped to a single Keeper node. Azure creates users and groups in a pending state and new users will receive an email invitation prompting them to create a Keeper account.
To setup Keeper user provisioning with Azure AD, you need to have access to the Keeper Admin Console and an Azure account.
Watch the video below to learn more about Azure AD provisioning with SCIM.
Step 1. Navigate to your Azure Admin account and select Azure Active Directory > Enterprise Applications and then New Application. Search for Keeper and select Keeper Password Manager & Digital Vault.
Step 2. After adding the application, click on the Provisioning section and select Automatic from the listed options.
In a separate window, you will retrieve the Tenant URL and Secret Token from the Keeper Admin Console.
Step 3. From the Keeper Admin Console navigate to a node which should be synchronized with your Azure AD. Click Add Method.
Note: SCIM integration can only be applied to specific nodes (e.g. organizational units) within your Admin Console. Be sure to host the provisioner within a "subnode" as opposed to the "root" node.
Step 4. Choose the SCIM option and click Next then select Create Provisioning Token.
Step 5. Copy the Tenant URL and Secret Token values and paste them into the Tenant URL and Secret Token fields in the Azure AD screen from step one. Select Save to finish the Keeper provisioning setup.
Step 6. Return to the Azure AD screen and click Test Connection. If successful, save the credentials. Turn the Provisioning Status "on" and click Save.
Step 7. Go to the Users and Groups section of the Keeper Azure AD app and assign users or groups from your Azure AD to the app.
Step 8. Start Provisioning
Ensure that provisioning is started by clicking on the "Start" button.
Wait for approximately five minutes (in some cases, Microsoft can take up to 40 minutes for the first time run), then click the Sync button in the Admin Console. Verify that users appear under the Users tab.
SCIM-provisioned teams are not immediately created but rather put into a “Pending Queue” where they are finalized by one of several approval methods.
Instant Provisioning
In Azure, you can also instantly provision a user by clicking on Provisioning > Provision on demand.
Typically, identity providers that use SCIM such as Azure, support assigning users to teams, but custom role assignment is done only on a user basis. SCIM-provisioned teams and users are applied to the default role, without the ability for a team provisioned from SCIM to be mapped into an alternative, pre-defined role.
Keeper's Team-to-role mapping allows organizations to use their existing identity provider to assign users directly into teams that can be assigned custom roles.
To use team-to-role mapping, administrators simply assign a role to an entire “Team,” as opposed to individual users and use role enforcements to establish different requirements and restrictions for each team.
When setting up User and Team SCIM provisioning with Azure, make sure of the following:
Ensure that you have assigned the Azure groups in the SAML application
When you invite a user from Azure or assign a user into a group that has been provisioned, Azure will send the request to Keeper to either invite a user to join, or to add a user to a team, or to create a team.
If the user does not exist yet in Keeper, they will receive an invite to sign up (or they can use just-in-time provisioning)
After the user has created their Keeper account, the user will not yet be assigned into a Keeper team until one of a few things happen: (a) Admin logs into the Admin Console > Click on "Full Sync" from the Admin screen (b) A user from the relevant team logs into the Web Vault or Desktop App (c) Admin runs team-approve from Keeper Commander Sharing an encryption key (e.g. Team Key) can only be performed by a user who is logged in, and has access to the necessary private keys.
To streamline this process, the Keeper Automator service as of version 3.2 performs instant approval of Teams and team assignments. More information about the Automator service is located here.
This document described the provisioning process with Azure AD. To enable automatic authentication with Azure AD using the SAML 2.0 protocol, follow the setup instructions in the Keeper SSO Connect Cloud Guide.
Keeper supports SAML 2.0 Authentication and SCIM provisioning with the Google Workspace platform.
Keeper Enterprise is available for Google Workspace with automated user provisioning using the SCIM (System for Cross-Domain Identity Management) protocol. SCIM is an open standard that enables automated user provisioning between identity providers (like Google Workspace) and service providers (like Keeper).
IMPORTANT: If you want your users to authenticate via SAML 2.0 with Google Workspace, you must first configure and install Keeper SSO Connect.
View the full SSO Connect Cloud setup guide: https://docs.keeper.io/sso-connect-cloud/
Companies utilizing Google Workspace for their identity services can easily deploy Keeper’s EPM solution to their users without the need to manually provision users. Keeper has developed a tight integration with Google Workspace and Google Cloud to automatically provision users and teams from Google to Keeper. In the integration, admins can select which groups and users are provisioned to Keeper.
In addition to provisioning and de-provisioning users, Keeper Enterprise provides zero-knowledge, SAML 2.0 compliant authentication with Google for seamless and frictionless access.
Integration of Keeper Enterprise into Google Workspace enables organizations of any size to secure their passwords and confidential information within an encrypted vault. By including Keeper Enterprise in their SSO implementation, organizations fill critical security and functionality gaps that are essential from a cybersecurity perspective which includes:
Protects and generates strong passwords for any non-SAML application or website
Implements zero-knowledge security architecture with full end-to-end encryption
Stores SSH keys, digital certificates and any other confidential information
Enforces password compliance and policy-based access controls across the entire organization – all employees on all their devices for every website, application and system.
Manages shared passwords for financial, business, social media or any other critical service
Keeper is available for all Google Workspace Education, Business and Enterprise customers.
Google Workspace supports the following integrations with Keeper:
SSO authentication with SAML 2.0
Automatic User Provisioning with SCIM
User and Team provisioning with Google Cloud Functions and Cloud Scheduler
For step-by-step Google Workspace specific configuration use the following link: https://docs.keeper.io/sso-connect-cloud/identity-provider-setup/g-suite-keeper
Keeper supports SAML 2.0 Authentication and SCIM provisioning with JumpCloud
This guide covers JumpCloud Automated Provisioning with SCIM which will update and deactivate Keeper user accounts as changes are made in JumpCloud.
You can configure SCIM without SSO or SSO+SCIM
To setup Keeper user provisioning with JumpCloud®, you need to have access to the Keeper Admin Console and a JumpCloud® Admin account.
IMPORTANT: If you want your users to authenticate via SSO / SAML 2.0 with JumpCloud, you must first configure and install Keeper SSO Connect with JumpCloud. View the full SSO Connect setup guides: SSO Connect Cloud: https://docs.keeper.io/sso-connect-cloud/ SSO Connect On-Prem: https://docs.keeper.io/sso-connect-guide/ Once Complete, proceed to Step 8: in the guide below.
If you just want to provision users via SCIM provisioning without SSO, proceed to the guide below.
Navigate to your Keeper Admin console and add the SCIM Provisioning Method to your desired "Node".
Select "SCIM (System for Cross-Domain Identity Management)" and select "Next".
At the next screen select "Generate" to generate your Token to connect your SCIM provisioning method.
At the next screen, you will be presented with your URL and Token. You will need this information, for future use, to configure the SCIM section of the Keeper SSO Application within JumpCloud®. Select "Save".
You will now see your SCIM Provisioning Method in a Pending State.
Navigate to your JumpCloud® Admin Console -> SSO and select the Plus Sign to add Keeper Password Manager to the list of your SSO applications.
On the "Configure New SSO Application" page, search for Keeper Security in the search bar. Select Configure on the right hand side of Keeper Application.
Under "General Info", provide your Keeper application a Display Label such as "Keeper EPM" in the provided field and then select "activate".
You will now see your Keeper application in an active status.
Click on the active Keeper application and within the Keeper App Configuration, scroll down to the bottom and select "Configure" under the "Identity Management Section".
This is where you will supply the previously generated URL and Token within the SCIM Provisioning Method in your Keeper Admin Console.
To enable Team Provisioning, click on "Enable management of User Groups..."
Select "save".
User and Team provisioning with JumpCloud is complete. Moving forward, new users who have been configured to use Keeper, in JumpCloud and are within the provisioning scope definitions, will receive invites to utilize the Keeper Vault and will be under the control of JumpCloud.
SCIM-provisioned teams are not immediately created but rather put into a “Pending Queue” where they are finalized by one of several approval methods.
Keeper supports SAML 2.0 Authentication and SCIM provisioning with CloudGate UNO
This guide covers CloudGate Automated Provisioning with SCIM which will update and deactivate Keeper user accounts as changes are made in CloudGate.
You can configure SCIM without SSO or SSO+SCIM
To setup Keeper user provisioning with CloudGate, you need to have access to the Keeper Admin Console and a CloudGate Admin account.
IMPORTANT: If you want your users to authenticate via SSO / SAML 2.0 with CloudGate, you must first configure and install Keeper SSO Connect with CloudGate. View the full SSO Connect setup guides: SSO Connect Cloud: https://docs.keeper.io/sso-connect-cloud/ Once Complete, proceed to Step 7: in the guide below.
If you just want to provision users via SCIM provisioning without SSO, proceed to the guide below.
Navigate to your Keeper Admin console and add the SCIM Provisioning Method to your desired "Node".
Select "SCIM (System for Cross-Domain Identity Management)" and select "Next".
At the next screen select "Generate" to generate your Token to connect your SCIM provisioning method.
At the next screen, you will be presented with your URL and Token. You will need this information for the step 8 to configure the SCIM section of the Keeper SSO Application within CloudGate. Select "Save".
You will now see your SCIM Provisioning Method in a Pending State.
Navigate to your CloudGate Admin Console -> Service Provider and select the Add service provider to add Keeper Password Manager to the list of your SSO applications.
On the "ADD SERVICE PROVIDER" page, search for Keeper Security in the search bar. Select Add on the Keeper SSO Cloud Connect icon.
Click "edit" on the Keeper SSO Cloud Connect icon you created at SERVICE PROVIDERS page and go to the provisioning settings tab.
This is where you will supply the previously generated URL and Token within the SCIM Provisioning Method in your Keeper Admin Console at the step 4. Now you can click "Test" to check if the SCIM provisioning is OK.
Select "save".
User provisioning with CloudGate is complete. Moving forward, new users who have been configured to use Keeper, in CloudGate and are within the provisioning scope definitions, will receive invites to utilize the Keeper Vault and will be under the control of CloudGate.
Keeper supports SAML 2.0 Authentication and SCIM provisioning with the OneLogin platform.
Keeper Enterprise supports integration with OneLogin with automated user provisioning using the SCIM (System for Cross-Domain Identity Management) protocol. SCIM is an open standard that enables automated user provisioning between identity providers (like OneLogin) and service providers (like Keeper).
IMPORTANT: If you want your users to authenticate via SAML 2.0 with OneLogin, you must first configure and install Keeper SSO Connect. Please follow one of the guides: https://docs.keeper.io/sso-connect-cloud/ - Cloud or https://docs.keeper.io/sso-connect-guide/ - On-Prem
If you don't want to authenticate users using SAML 2.0 and you simply just want to provision users via SCIM provisioning, proceed to the SCIM Only Configuration section below.
Companies utilizing OneLogin for their identity services can easily deploy Keeper’s EPM solution to their users without the need to manually provision. When auto-provisioning for Keeper Enterprise is enabled in OneLogin, any users created, modified or deleted in OneLogin are automatically added, edited or deleted in Keeper.
In addition to provisioning and deprovisioning users, Keeper Enterprise provides zero-knowledge, SAML 2.0 compliant authentication with OneLogin for seamless and frictionless access.
Integration of Keeper Enterprise into OneLogin enables organizations of any size to secure their passwords and confidential information within an encrypted vault. By including Keeper Enterprise in their SSO implementation, organizations fill critical security and functionality gaps that are essential from a cybersecurity perspective which includes:
Protects and generates strong passwords for any non-SAML application or website
Implements zero-knowledge security architecture with full end-to-end encryption
Stores SSH keys, digital certificates and any other confidential information
Enforces password compliance and policy-based access controls across the entire organization – all employees on all their devices for every website, application and system
Manages shared passwords for financial, business, social media or any other critical service
User encryption keys are generated dynamically by Keeper SSO Connect, encrypted and stored locally on the installed server, providing the customer with full control over the encryption keys that are used to encrypt and decrypt their digital vaults.
OneLogin has a built-in Keeper application in their catalog that supports both SSO + SCIM integration.
For OneLogin integration instructions, visit the Keeper SSO Connect Cloud guide: https://docs.keeper.io/sso-connect-cloud/identity-provider-setup/onelogin-keeper This will walk through setting up the integration of SSO and getting SCIM connected.
After the API Connect status is Enabled, navigate to the Provisioning section and check the box for "Enable provisioning".
Add Users to the application.
Users can be added to the Keeper Password Manger connector in Onelogin in a couple different ways. The application can be added to the user's account or the user can be added to a Role, and the role gets added to the application via the Access section of the application in OneLogin. After the user has been added, in order for SCIM to send the request to Keeper, the OneLogin Admin will need to approve the change by navigating to the Users section in the Keeper Password Manager application connector and clicking on the "pending" status to Approve the user. The approval link can also be reached by going to the Applications section of the Users OneLogin profile and clicking the "pending" status. Click the Approve button to allow the user to be provisioned from OneLogin to Keeper.
Observe the user status changes from "Pending" to "Provisioned".
On the Parameters section, click on Groups in the Optional Parameters section. On the Edit Fields Group pop-out select 'Include in User Provisioning'.
Click save and observe the Groups status changes to Enabled. Next, navigate to the Rules section of the application connector and select the "Add Rule" button.
Give the rule a name like "Create Team from Role. Under the Actions section, select "Set Groups in Keeper Password Manager" from the pull down. Next, select (or search) 'role' from the pull down and add the value .* (dot star) for the matching text.
.* is regular expression to match any character 0 or more times. To refine the search to a specific role or roles alter the regular expression. Please contact OneLogin if your search results are not aligning.
For SCIM-only configuration, users are directed to the following OneLogin instructions, https://developers.onelogin.com/scim.
On the Configuration page of your app, use the following SCIM JSON template (Keeper username must be a valid email address):
Obtain the SCIM Base URL and SCIM Bearer Token from the Admin Console
Add the following line to the Custom Headers section
After you have enabled provisioning, your configuration would look similar to the screen capture below:
SSO Connect Cloud:
To use team-to-role mapping, administrators simply assign a role to an entire “Team,” opposed to individual users and use role enforcements to establish different requirements and restrictions for each team.
Typically, identity providers that use SCIM such as OneLogin, support assigning users to teams, but custom role assignment is done only on a user basis. SCIM-provisioned teams and users are applied to the default role, without the ability for a team provisioned from SCIM to be mapped into an alternative, pre-defined role. Team-to-role mapping allows organizations to use their existing identity provider to assign users directly into teams that can be assigned custom roles.
OneLogin appears to have a timing issue with their SCIM system which can possibly send multiple simultaneous requests to create the same Group. Keeper normally will accept the new group creation even if the Group Name is identical.
If you encounter an issue with duplicate group names, please contact Keeper and we will set a flag on your SCIM connection which enforces unique names.
Contact Keeper Support to enforce unique group names on your SCIM instance.
SCIM-provisioned teams are not immediately created but rather put into a “Pending Queue” where they are finalized by one of several approval methods.
Keeper supports SAML 2.0 Authentication and SCIM provisioning with Microsoft AD FS
Keeper integrates with Microsoft AD FS for real-time user authentication, provisioning and de-provisioning.
View the full SSO Connect setup guides:
SSO Connect Cloud with Microsoft AD FS: https://docs.keeper.io/sso-connect-cloud/identity-provider-setup/ad-fs-keeper
SSO Connect On-Prem: https://docs.keeper.io/sso-connect-guide/identity-provider-setup/ad-fs-configuration
Keeper supports direct SCIM API provisioning for any 3rd party identity provider
System for Cross-domain Identity Management (SCIM) is a standard for automating the exchange of user identity information between identity domains, or IT systems [wikipedia].
Identity providers such as Okta, Azure AD / Entra ID, Google G Suite, JumpCloud and other popular IdP platforms support the use of SCIM for provisioning Teams and Users to Keeper Enterprise. The terminology differs between platforms. For example, Okta and Azure call it "Automated Provisioning".
Other identity management products such as SailPoint also support the use of SCIM 2.0 for provisioning users automatically.
Keeper supports SCIM 2.0, a REST-based API using JSON message structure. The Keeper SCIM endpoint supports Users and Groups resources, and the following message types:
User/Team Provisioning
Retrieve user/team information
Add a user/team
Update a user/team profile
Delete a user/team
Keeper SCIM Rest endpoint is a resource available at http://keepersecurity.com/api/rest/scim/v2/<node_id>, where node_id identifies the Keeper Enterprise node used in the SCIM protocol sync.
A user can have multiple nodes synchronizing with different identity providers (Azure AD, Okta directory, etc.) from the same vendor or different vendors. One node per identity provider, parent-child relationship is not supported (e.g if SCIM is setup on a node, the sub-nodes of this node are not controlled by the integration, but they can be controlled by their own provider).
The authentication is the Header Authentication, with the token generated by Keeper when setting up the node.
Keeper SCIM endpoint supports Users and Groups resources, according to the following table:
Resource/Method | URL sample |
Users/GET | https://keepersecurity.com/api/rest/scim/v2/123/Users Returns all users for the node 123 |
Users/GET | https://keepersecurity.com/api/rest/scim/v2/123/Users/456 Returns the user 456 for the node 123 or 404 if not found |
Users/POST | https://keepersecurity.com/api/rest/scim/v2/123/Users Parses SCIM content (User) of the requests and adds an user to the node 123 |
Users/PATCH | https://keepersecurity.com/api/rest/scim/v2/123/Users/456 Parses SCIM content (Operations) and adds or removes the user 456 to/from teams referenced in add/remove operations as groups. Also, can process “active” property making user locked or unlocked in Keeper. The referenced teams must belong to the same node. Returns 404 if user is not found. |
Users/DELETE | https://keepersecurity.com/api/rest/scim/v2/123/Users/456 Locks user 456 from the node 123. Returns 404 if user is not found. Note: Keeper locks the account instead of deletion to prevent data loss. Admin can perform permanent user deletion within the Admin Console interface or Commander API. |
Groups/GET | https://keepersecurity.com/api/rest/scim/v2/123/Groups Returns all teams for the node 123 |
Groups/GET | https://keepersecurity.com/api/rest/scim/v2/123/Groups/789 Returns the team 789 for the node 123 or 404 if not found |
Groups/POST | https://keepersecurity.com/api/rest/scim/v2/123/Groups Parses SCIM content (Group) of the requests and adds a team to the node 123 |
Groups/PATCH | https://keepersecurity.com/api/rest/scim/v2/123/Groups/789 Parses SCIM content (Operations) and adds or removes to the team 789 users referenced in add/remove operations. The referenced users must belong to the same node. Returns 404 if team is not found. |
Groups/DELETE | https://keepersecurity.com/api/rest/scim/v2/123/Groups/789 Deletes team 789 from the node 123. Returns 404 if team is not found. |
ServiceProviderConfig/GET | https://keepersecurity.com/api/rest/scim/v2/123/ServiceProviderConfig Returns SCIM Service Provider Configuration for Keeper SCIM service |
Per specification: https://tools.ietf.org/html/rfc7644#section-3.4.2.5
Keeper supports the “excludedAttributes” for “members” attribute. To improve performance of working with groups that contain a large number of members, you can add a parameter such as:
...on SCIM queries for multiple groups and a single group, and on PATCH query for a group.
Per specification: https://tools.ietf.org/html/rfc7644#section-3.4.2.4
By default, Keeper SCIM API will only return the first 1000 entries for queries that yield large result sets. To query the entire data set, use SCIM pagination parameters according to the specification.
The SCIM identity provider maps to a single node, and the username of the provider maps to the Keeper user name (email address), which needs to be unique globally. Therefore, if an identity provider contains a user defined by the email which is already a member of the same or different Keeper Enterprise account, any attempt to provision this user will fail. The only exception is if the user is already a member of the same node, then the provisioning will be successful, establishing the link between the identity provider and Keeper. To avoid problems, if you already have manually created users in Keeper that match ones that you plan to use in the identity provider, move them manually under the SCIM node prior to setting up the integration in the provider.
When a user is provisioned, Keeper requires either their username or email to contain a valid email address. If not, the provisioning can be rejected (e.g. in Okta you can set username to be some arbitrary string and an email is not required). If the email is fake, it will be accepted, but the provisioned user will not be able to receive the invitation email and as such will not be able to join the enterprise.
New users added by the SCIM sync are created in the “invited” state and will receive an invite to join Keeper. New teams created by the SCIM sync are created in the “pending” state and require final approval from either the Keeper Administrator or another team member.
Users added to teams via SCIM are added in a "pending" state and require approval. Team and user approval occurs automatically when the Admin logs in to the Keeper Admin Console. Approvals can also be automated using the Keeper Automator service or using Keeper Commander. The reason that teams and users are approved using this method is because encryption keys must be generated and/or shared. In Keeper's Zero-Knowledge environment, this action must be performed by a Keeper Administrator, by another team member, or by the automation service. Keeper's support team can assist customers in installing the automation service.
By default, Keeper will accept group creation even if the Group Name is identical to a previously used name.
If you encounter an issue with duplicate group names, please contact Keeper and we will set a flag on your SCIM connection which enforces unique names.
If necessary, contact Keeper Support to enforce unique group names on your SCIM instance.
Keeper has integrated SCIM into the Keeper Commander SDK. Users and groups can be pushed from any directory source (e.g. Google Workspace, Active Directory or any other source) directly into the Keeper SCIM endpoint.
Learn More about the SCIM Push command.
If you click the "Test" button before saving the SCIM provisioning method in the Admin Console, the test will fail. Copy the token first, then click Save.
Keeper users are identified by their email, therefore when assigning so make sure the User Name contains a valid email address.
When setting up User and Team SCIM provisioning, make sure of the following:
When you invite a user from SCIM, if the user does not exist yet in Keeper, they will receive an invite to sign up (or they can use just-in-time provisioning)
After the user has created their Keeper account, the user will not yet be assigned into a Keeper team until one of a few things happen: (a) Admin logs into the Admin Console > Click on "Full Sync" from the Admin screen or.... (b) A user from the relevant team logs into the Web Vault or Desktop App or.... (c) Admin runs team-approve from Keeper Commander or... (d) The Keeper Automator service approves the transaction. The reason that teams and users can't be created instantly via SCIM, is due to the encryption model and the need to share a private key between users. Sharing an encryption key (e.g. Team Key) can only be performed by a user who is logged in, and has access to the necessary private keys.
To streamline this process, the Keeper Automator service as of version 3.2 performs instant approval of Teams and team assignments. More information about the Automator service is located here.
Manual and Automated approval of SCIM or Bridge-provisioned Users & Teams
The "Approval Queue" is where SCIM- and Bridge-provisioned Teams and Users live until an Admin or other team member performs the necessary approval. Approvals are required in the Keeper environment in order to share the necessary encryption keys (by encrypting the private keys with the public key of the Team or User).
Additionally, the Approval Queue is used for Keeper SSO Connect Cloud device approvals when the end-user clicks on "Request Admin Approval".
Keeper provides several methods of approvals, manual and automated.
New users added by identity providers using the SCIM protocol are created in the “invited” state and will receive an invite to join Keeper.
New teams created by the SCIM sync are created in the “pending” state and require final approval by a Keeper Administrator, another team member or automated methods.
Actions must be taken by either the Admin or using methods outlined below, because encryption keys must be generated and/or shared.
Team creation and team member assignments are completed automatically when any Administrator logs into the Keeper Admin Console. Approval is performed by encrypting the Team Key with the user's public key.
Team members approvals are completed automatically when any member of the team (including the Admin) log into the Keeper Web Vault or Desktop App. Approval is performed by encrypting the Team Key with the user's public key.
Keeper Automator is a container application that can be deployed as a standalone service to any cloud or on-prem environment.
Keeper Automator version 3.3+ supports automated team creation, team-user assignments and user approvals
Keeper Automator performs instant device approvals, team approvals and team-user assignments without the need for any manual actions by users.
See the setup instructions here: https://docs.keeper.io/sso-connect-cloud/device-approvals/automator
Approvals can be automated or run manually via the Keeper command-line interface or SDK platform, Keeper Commander.
Download Keeper Commander here: https://github.com/Keeper-Security/commander.
team-approve
approves queued teams and users that have been provisioned by SCIM or Active Directory Bridge.
Keeper Commander Parameters
--team
approve teams only
--user
approve team users only
--restrict-edit {on,off}
disable record edits
--restrict-share {on,off}
disable record re-shares
--restrict-view {on,off}
disable view/copy passwords
device-approve
approves SSO Cloud user devices.
--approve
approve all devices
--trusted-ip
approve devices that come from recognized IPs
--reload
retrieve the latest devices pending approval
--deny
deny a device
See the setup instructions here:
Basic provisioning of users based on email address
To facilitate the onboarding of Keeper to users based on their email address domain and a Master Password, use the Email Provisioning method. This can be used for organizations that are deploying Keeper to a large number of users (such as a university) where the admin is not explicitly inviting the user to sign up.
For example, anyone with the email address containing the domain acme.edu, can be automatically provisioned to a particular node and role within the Acme EDU Keeper Enterprise account upon creating their vault.
Email provisioning is only recommended for users setting up a Master Password authentication method. SSO-enabled nodes do not require an email provisioning method.
(1) Login to the Keeper Admin Console
(2) If you don't already have a Node created for this provisioning method, please create one by clicking "Add Node". Provisioning is not permitted in the root node.
(3) In the new node, click on Provisioning > Add Method
(4) Select Email Auto-Provisioning then Next
(5) Choose a method of domain name ownership. You can use DNS lookup or HTML file upload.
(6) Once verification is complete, the status will show the email domain.
When using the email provisioning method, the easiest way to invite users to sign up is to provide them a link to the vault:
US Data Center: https://keepersecurity.com/vault
EU Data Center: https://keepersecurity.eu/vault AU Data Center: https://keepersecurity.com.au/vault
CA Data Center: https://keepersecurity.com.ca/vault
JP Data Center: https://keepersecurity.jp/vault
Users simply click "Set up now" and use your company email to create your vault.
The user types in their email and clicks "Next".
User will set a Master Password.
After the user confirms their email with a verification code, the user will be provisioned to the specified Node and Default Role in the Admin Console.
Keeper Commander is an open-source Python SDK which can perform many vault and administrative functions within the Keeper system.
Keeper supports API-based provisioning through the use of our Python-based Keeper Commander SDK. The Keeper Commander SDK is open source Python code that is available for download from Keeper's Github Repository. The Commander SDK can assist in the following use cases:
Command line access to your Keeper vault
Running reports
Importing passwords, folders and shared folder
Provisioning users and teams
Pushing records to users and teams
Sharing records and folders with users and teams
Performing targeted password rotation
Managing Secrets Manager and Keeper PAM
Since Keeper Commander is an open source SDK and written in Python, it can be customized to meet your needs and integrated into your back-end systems.
For more information about Keeper Commander, visit: https://docs.keeper.io/secrets-manager/commander-cli/overview
Commander's command-line interface and interactive shell is a powerful and convenient way to access and control your Keeper vault and perform many administrative operations. To see all available commands, just type:
To run a series of commands and stay logged in, you will enjoy using Commander's interactive shell.
Type h
to display all commands and help information.
Commander has hundreds of features. Specifically with regards to User and Team provisioning, the following commands are relevant:
create-user
enterprise-info
enterprise-node
enterprise-user
enterprise-role
enterprise-team
enterprise-push
team-approve
There are two methods for creating user accounts with Commander:
Invite users to an enterprise with the enterprise-user --add
command
Create new user accounts and vaults with the create-user
command
For the full list of commands offered by Commander, visit:
Federate login to Keeper with any SAML 2.0 compatible identity provider (IdP)
Keeper integrates with any SAML 2.0 compatible identity provider such as Okta, Microsoft Azure, Google Workspace, Centrify, OneLogin, Ping Identity, JumpCloud and more.
We offer two different SSO implementations: SSO Connect Cloud and SSO Connect On-Prem. Both implementations provide Zero Knowledge encryption with seamless authentication for end-users. We recommend SSO Connect Cloud for most customers.
Keeper SSO Connect Cloud is the latest Cloud-based architecture which can be configured with your identity provider to authenticate and provision users in a matter of minutes. To read the SSO Connect Cloud setup guide, see the link below: https://docs.keeper.io/sso-connect-cloud/
SSO Connect On-Prem is a self-hosted integration that requires either a Windows or Linux hosted application server. To read about the SSO Connect On-Prem configuration, see the link below:
Managing users and lifecycles in the Keeper Admin Console
Clicking on the Search field will open a dynamic search tool that searches across Nodes, Roles, Teams and Users. The search feature uses a fuzzy searching mechanism to find the best match.
Click on the headers (Nodes, Roles, Teams, Users) to filter the results.
Once a user has been added, the Administrator can edit or make changes to a user's profile. By selecting the user that you want to modify from the Users tab, you will notice what user details can be edited, such as Name, Roles, or Team.
Users can be in one of 6 states: Invited, Active, Disabled, Locked, Blocked and Pending Transfer Acceptance.
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 selecting the Resend Invite button. |
Active | User has created their Keeper account and joined the organization. |
Disabled | User has been disabled in the enterprise Active Directory. |
Locked | User has been suspended (either manually by selecting the Lock Account button or automatically via AD Bridge or SCIM). To manually lock a user account, select the Lock Account button. |
Blocked | If Account Transfer enforcement policy is applied to the role that the user belongs to, 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 (the user can login but will not be able to move past the consent request popup to access their records). By clicking the Extend Transfer Acceptance Consent icon, the Admin can extend the time limit for an additional 7 days. |
Pending Transfer Acceptance | If the Account Transfer enforcement policy is applied to the role that the user belongs to and the vault transfer consent request is pending acceptance within their vault. The user has 7 days to accept the request. |
Additional user actions can be performed from the Edit User dialog. Only icons relevant to each user's account will be visible.
Icon | Action |
Edit a user | Change the name of the user. |
Disable 2FA | Disable the user's second factor authorization (2FA). |
Transfer Account | If Account Transfer is active for 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. The account must first be locked before you can perform a transfer. After the transfer is completed, the user account is deleted. More information on the Transfer Account action is detailed throughout this guide. |
Delete User | Delete the user account. Note: this action cannot be undone and has serious consequences: 1. All of this user's owned vault records will be immediately deleted, and they will be removed from all Roles, Nodes and Teams. 2. Any records created by the user are deleted. 3. Any records shared from this user to other users will be deleted. 4: Any records in a shared folder shared to other users will continue to be shared and will become ownerless. |
Lock Account | To suspend an account and prevent the user from accessing their Vault, you can simply lock their account. 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 | Expire a user's Master Password outside of the enforcement policy periodicity. 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 the Account Transfer enforcement policy is applied, 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 in 7 days, their account will be in a "blocked" state. They will be required to accept the consent before access is again granted. The Extend Transfer Acceptance Consent will extend the time limit for another 7 days. |
Resend Invite | If a user has been invited to join Keeper but has not yet completed their account setup, you can re-send their invitation to join. |
Keeper's Least-Privilege Role permissions are both flexible and powerful.
In the Keeper architecture, Roles and Teams are separate but related concepts.
Roles define permissions, controls what features and security settings apply to users and manages administrative capabilities.
Teams are used for sharing privileged accounts and Shared Folders among users within the vault. Teams can also be used to easily assign Roles to entire groups of users to ensure the consistency of enforcement policies across a collective group of individuals (more on teams here).
Role-based Access Controls (RBAC) provide the organization the ability to define enforcements based on a user's job responsibility as well as provide delegated administrative functions.
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 (under the Root Node) 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.
We strongly recommend adding a secondary admin to the Keeper Administrator role in case one account is lost or no longer accessible. The creation of additional roles such as a General Employee role, is not required but highly encouraged.
Watch the video below to learn more about role-base access controls.
You can add roles manually through the Admin Console, automatically mapped via SCIM, created with Keeper Commander, or assigned from Active Directory / LDAP via the Keeper AD Bridge.
To add roles manually, select the Roles tab. There you can navigate to the specific node you would like the role to be assigned to. Select the + button to add a role. Verify or select the appropriate Node in the organization tree (or select the Root Node). Enter the name of the role you are creating then click Add. After the role has been created, you can configure the role enforcement policies, select the users to assign the role and set administrative permissions.
First, select the role you would like to configure. Click the Enforcement Policies button. Observe the enforcement policies are are structured into the following areas:
Login Settings
Two-Factor Authentication (2FA)
Platform Restriction
Vault Features
Sharing & Uploading
KeeperFill
Account Settings
Allow IP List
Keeper Secrets Manager
Transfer Account
For more information about Enforcement Policies, click here.
Team-to-role mapping allows organizations to use their existing identity provider to assign users directly into Teams that can be assigned custom Roles. With team-to-role mapping, a user who is a member of a team who is assigned to a role will assume the enforcements of the given role. That user can be a member of the role more than once, once via user-role membership and again via user-team-role memberships if any exist.
To use team-to-role mapping, administrators simply assign a role to an entire Team, as opposed to individual users, and use Role Enforcement Policies to establish different requirements and restrictions for each Team.
Currently Keeper does not allow mapping of administrative roles to teams, in order to prevent an admin from inadvertently elevating permission of a user. This feature is being considered for a future release.
When setting up SCIM (System for Cross-Domain Identity Management) in the Keeper Admin Console, roles can be automatically assigned instead. By default, SCIM groups map to Keeper teams. SCIM group names that start with this optional prefix will instead map the assignments to a role.
It is important to note, that if a user is a member of multiple roles or a team with differing role enforcements, all enforcements must be satisfied for all the roles the user is a member of. Keeper implements least-privileged policies, so when a user is a member of multiple roles, their net policy is typically most restrictive, but this can vary depending on the enforcement.
For example: Role A does not allow sharing to anyone. Role B does not allow sharing outside of the enterprise. The user will be unable to share to anyone because Role A (least privilege) does not allow it.
The next section documents each of the available enforcement policies.
Role Enforcement Policies
Keeper role enforcement policies provide fine-grained control over the security and functionality of your Keeper environment.
This option, which we also refer to as "Alternate Master Password", provides SSO-activated users a way to alternatively login by using their own Master Password instead. This may be useful if the SSO connection is down or the user is offline. This can also be used by SSO-enabled users to log into Keeper Commander CLI.
Customers who normally login to their Keeper Vault using Enterprise SSO Login (SAML 2.0) can also login to Keeper Web Vault, Browser Extension and Keeper Commander using a Master Password. To make use of this capability, it must be enabled by the Keeper Administrator in the role policy and then configured by the user. Offline access can also be achieved with a Master Password for SSO-enabled users when this feature is activated.
Once this policy is activated, each user can follow the below steps to activate their Alternate Master Password:
Login to the Web Vault using SSO
Visit the Settings screen and then click "Setup" or "Edit" to set the Master Password.
Once set, the user can login to Keeper Web Vault by visiting the "Enterprise SSO Login" > "Master Password" screen.
The Master Password login feature for SSO users is only available on the Web Vault, Desktop App, Browser Extension and Commander CLI.
Master Password Complexity policy enforces a password complexity for users that are assigned the selected role. This policy only applies to users who login with a master password.
Settings include:
Password length
Number of digits
Number of special characters
Number of uppercase letters
Number of lowercase letters
Important Note about Master Password Complexity and Default Role
When users are initially creating their vault, Keeper looks at all of the Default Roles within the Keeper Enterprise console in order to enforce master complexity rules. Keeper decides the Master Password complexity rules based on the largest value of each Default Role.
Once the account is created, Keeper will use the role assigned to the user to ensure Master Password complexity requirements are enforced on an ongoing basis.
When creating the Keeper Vault, the user will be required to adhere to the complexity requirements.
The Master Password Expiration policy will require users to change the Master Password at the selected time interval (in days). When this policy is turned on, the Master Password will expire and the user will be forced to choose a new Master Password upon their next login. To configure the number of days that the Master Password must be changed, select this setting and make a selection between 10 to 150 days.
This feature does not affect users who login with SSO Connect Cloud.
If a user's Master Password needs to be expired immediately, this can be done from the Users tab. Select the user(s) that you wish to expire the master password for and select the Expire Master Password for all users. This will instantly expire a user's Master Password and require a password reset.
Keeper natively supports Windows Hello, Touch ID, Face ID and Android biometrics. Customers who normally login to their Keeper Vault using a Master Password or Enterprise SSO Login can also login to their devices using a biometric. Offline access can also be achieved with a biometric for both Master Password and SSO-enabled users unless the "Restrict offline access" enforcement is applied.
Keeper does not store or process biometric data of users. Keeper integrates with the existing biometrics capabilities of the operating system.
Turning on the Two-Factor Authentication 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.
If 2FA is enforced, the user will be prompted to set up 2FA upon account creation or login
If 2FA is enforced, it cannot be disabled by the user, but they can "Edit" and re-configure their 2FA
In addition to enforcing 2FA, the Admin can also specify how often users are prompted to re-authenticate with a new code.
Admin can disable a user's 2FA temporarily from the User detail screen in the Admin Console
Note that 2FA is always enforced on the Keeper servers once it has been configured for a user, no matter how often the user is prompted for a code. When a user has authenticated with a 2FA code, a token is generated on the device which is used for subsequent communication to the backend system.
On the user's device, the Admin can decide how often the user is prompted. For example, you can specify that users on Web Vault and Desktop app are prompted every login, but users on mobile devices are prompted once every 30 days. In any case, logging into a new device will always prompt the user.
In addition to specifying the 2FA prompting frequency, the Admin can specify which 2FA methods are available to users within the role. Different roles can be enforced with different methods.
Keeper supports the following 2FA methods:
FIDO2 WebAuthn Security Keys (supports PIN verification)
TOTP (Google Authenticator, Microsoft Authenticator or any time-based TOTP generator)
Smartwatch (Apple Watch or Android Wear)
RSA SecurID
Duo Security
Text Message (SMS)
More information on DUO Security and RSA SecurID can be found in the Two Factor Authentication section.
Keeper's advanced authentication system provides a built-in device verification that provides a second factor via email confirmation when attempting to login on an unrecognized device. If a user has configured 2FA, it can also be used as a method of device approval instead of email (for example, if email access is not possible).
Device Approval with a 2FA code is only possible with accounts that login with a Master Password. Users who login with SSO on a new device are required to use Keeper Push, Admin Approval or Keeper Automator approval methods.
An Admin can restrict the use of specific platforms to access Keeper including the Web Vault, Browser Extensions, Mobile app, Desktop app, Commander SDK and KeeperChat.
An Admin can prevent users in a role from using standard features in the Vault. Each individual policy is described below.
Turning this on will prevent the "Quick Start" module from appearing in users' vaults when they login in for the first time.
The in-app onboarding flow will adapt to the policies set by the Keeper Administrator:
If importing is not allowed, this option will be hidden
If Browser Extension is not allowed, this option will be hidden
If account recovery is disabled, this option will be hidden
If Quick Start is completely disabled, this flow will not appear
This will force all custom field names and values to be masked. The user will need to unmask by clicking the eye icon in the record. Here's an example of what this will look like:
This will mask the notes section of a record. The user must click the eye icon unmask the details. Here's an example of what this will look like:
Passwords are always masked, by default, across all Keeper platforms. On iOS and Android devices, users have the choice of turning password masking On or Off. If this setting is enabled, the users will always have masking enabled, and to view a password will require the user to click on the eye icon.
When enabled, BreachWatch events will not be sent from the devices to the Keeper Admin Console. The only reason to use this feature might be when using test data or in the initial setup of the Enterprise console. Pausing BreachWatch events will therefore not generate events in the Admin Console or connected reporting systems.
By default, Keeper does not send BreachWatch event data from the user's device to connected SIEM and Advanced Reporting & Alerts reporting tools. The Keeper Admin must explicitly enable this feature. After it's enabled, the event data will begin to flow through to the Advanced Reporting engine and connected SIEM systems such as Splunk.
Note that this is not retroactive. Events will only flow through Advanced Reporting & Alerts after this feature is activated.
This enforcement policy allows you to require users to re-authenticate using either their Master Password or biometric login prior to completing the following actions:
Autofilling passwords
Revealing and copying a password or masked field
Editing, sharing and deleting a record or folder.
Additionally, "Delay re-authentication after minutes of inactivity" allows you to specify how many minutes should pass after inactivity before the user is asked to re-authenticate.
Note: This feature does not apply to SSO users.
By default, a deleted record will move into the Owner's trash bin ("Deleted Items"). Keeper provides two enforcement policies to control the handling of deleted items.
Day(s) before records can be cleared permanently
Day(s) before deleted records automatically purge
To prevent the possibility of a user either accidentally or maliciously permanently deleting the records in their vault, you can specify the number of days that a record must sit in the trash bin before being permanently deleted.
Admins can also configure automatic deletion of records that the user has placed into the trash bin.
Keeper's password and passphrase generator can be enforced as a general policy, or for specific website domains.
The password generator on end-user vaults will adhere to the minimum character length, minimum number of lowercase/uppercase/numbers/symbols and allowed list of symbols as defined here. The symbols used in the password generator will be limited to the selection from the list. By default, all symbols will be used.
The passphrase generator on end-user vaults is enabled by default, but can be disabled by the admin. Passphrases will adhere to the minimum number of words and can be configured to include capital letters and a number. The separators between words will be selected from the list of allowed symbols. By default, a set of symbols is utilized.
Domain-specific policies allow admins to enforce a password complexity privacy rule for a specific domain name, or domain pattern match.
Wildcards (*) can be used to create minimum password complexity rules for more than a single domain.
For example:
*.amazon.com
*.google.com
*.gov
example.com
*.example.com
One can also create a global domain rule using the wildcard character (*) by itself. Keep in mind that overlapping rules will be evaluated to produce the most restrictive outcome. If a wildcard is used by itself, the policy will be enforced for any record which contains any value for the domain name.
Keeper's Privacy Screen feature can be applied at the team level, role policy level (based on specific record domains), and at the record type (template) level.
At the role policy level, the Privacy Screen enforcement policy is used in conjunction with the Generated Password Complexity policy to control the viewing (unmasking) of passwords based on a specified domain. With this policy in place, passwords are not visible from the user interface serving as a deterrent from casual observation. This feature is commonly used to limit viewing of passwords for the non-technically savvy users.
If Privacy Screen is applied to a user with edit or ownership permission on a record, the user is forced to use the password generator when editing the record.
It is important to note that password masking is only visual in nature and the password is still stored in the user's vault and accessible via API communication and browser inspection. If the admin would like to enforce that users cannot inspect the web pages, we recommend using group policies to prevent users from opening the browser development tools.
This feature can be enabled within the Generated Password Complexity settings by checking the “Apply Privacy Screen” box once a domain has been added.
Inside the vault, any record with a matching URL will be locked, and the user cannot unmask to view the password.
Likewise, in the Browser Extension, the Privacy Screen is activated.
Watch the video below to learn more about the Privacy Screen feature.
If record types are enabled for your account, specific record types that are not wanted can be enabled or disabled. Both default and custom record types can be enabled or disabled based on the role permissions. Custom record types show up below default types, but the desired order can be controlled within each users vault settings.
Turning off certain record types will affect what shows up in the dropdowns in user vaults:
Note that the left menu item for "Record Types" will not be visible if this capability is not enabled for your enterprise.
If all record types except one are disabled in the console, when creating a record in the vault, the popup to select a record type will not appear. The workflow will continue as if record types has not been enabled for users in that role.
Even if record types are disabled for a portion of users in an organization, this will not limit sharing and editing capabilities. For example, an Admin will be able to share a custom SSH Key record with non-admins and all data in the record will be present.
If records are shared with another organization that does not have record types enabled, the data will be there, but not visible until that organization has record types enabled.
Creating and sharing enforcements offer admins a wide range of granular, flexible restrictions that can be applied to users when both creating and sharing records.
“Creating” enforcements handle a user’s ability to create records, folders, shared folders and more.
Creating can be customized to:
Create records, including the ability to restrict the creation of records and folders inside shared folders only and duplication of records.
Create folders, including the ability to restrict the creation of folders inside shared folders only.
Create shared folders
Create items in the identity and payments tab, including the payment and address records using the KeeperFill Browser Extension.
Upload files
“Sharing” enforcements handle a user’s ability to share and receive items including one-time share links, file attachments and more.
Sharing can be customized to:
Share and receive items
Share to others by adding records inside shared folders only, preventing a user from adding other users to records and shared folders.
Only receive shared items, preventing a user from adding other users to records and shared folders.
Cannot share or receive items, preventing a user from adding other users to records and shared folders and from receiving items from others. If this enforcement is enabled, then the ability to generate One-Time Share links, share records with file attachments and share to users outside of the enterprise will be disabled by default.
Admins can also individually restrict a users ability to:
Generate One-Time Share links
Share records with file attachments
Can share outside of isolated nodes
Share to users outside of the enterprise
Can receive items from users outside of the enterprise
"Import" and Export" enforcements offers admins more targeted control over their users’ ability to import and export from their vaults.
Importing and exporting can be customized to:
Import into vault, including the ability to restrict importing shared folders from LastPass.
Export from vault
KeeperFill is the browser extension that provides Keeper users with autofill capability on websites and applications.
To learn more about KeeperFill, read our KeeperFill Browser Extension guides.
Admins can individually enable the various features and settings of the KeeperFill Browser extension.
Supported Enforcement Settings:
Enforce or Disable "Hover Locks"
Enforce or Disable "Autofill Suggestions"
Enforce or Disable "Autofill"
Enforce or Disable "Auto Submit"
Enforce or Disable "Match on Subdomain"
Enforce "Prompt to Fill"
Enforce "Prompt to Save"
Enforce "Prompt to Change"
Enforce "Prompt to Disable"
Enforce the "HTTP Fill Warning" popup
Admins can disable KeeperFill on specific websites. This feature supports wildcard characters for matching domain names or URLs. One use case might be to disable KeeperFill for internal applications that have a lot of form fields.
Turning this on will prevent users from accessing their Keeper vault without internet access. Toggle this on to enforce the restriction so they can not login offline.
More information about Offline Access is documented here.
Turning this on prevents users from changing their email address. Note, SSO-enabled users cannot change their email.
Turning this policy on will allow users in this role 5 incorrect password attempts before all locally-stored Keeper data is erased.
Turning this policy on will prevent users from inviting their personal email to a Keeper Family License for personal use. More information about the free Family License for Personal Use is available at this page.
Activating this enforcement policy will disable the "Stay Logged In" feature for users in the role. This feature allows users to remain logged in to the Web Vault, Desktop App and Browser Extension in between browser or computer restarts, until the inactivity timer expires. When the enforcement policy is active, users will always be logged out when the application closes, regardless of the inactivity timer.
Set the default "Stay Logged In" setting "on" or "off" for new users in this role. This setting applies only to new users, it is not retroactive.
The Admin can set the inactivity logout timer for the Web, Mobile and Desktop Apps. A different duration can be set for each, in minutes. This sets the maximum and default time to automatically log out a user from Keeper when they are inactive. If a Keeper user's current timer is set greater than this value, it will be reduced to this default time setting.
A 24-word auto-generated recovery phrase is a break-glass method of recovering a Keeper Vault if the user forgets their master password. Account recovery can also be used to login to an account if the SSO identity provider is unavailable.
Keeper has implemented recovery phrases using the same BIP39-word list used to protect crypto wallets. The word list in BIP39 is a set of 2,048 words used to generate an encryption key with 256 bits of entropy. Each word in the BIP39 list is carefully selected to improve visibility and make the recovery process less error-prone. More information about account recovery is found at the Keeper blog post.
This policy allows the Admin to disable account recovery for users. This policy to disable account recovery is recommended when customers login with Keeper SSO Connect Cloud with a SAML 2.0 identity provider.
If account recovery is disabled, we recommend that customer enable the Vault Transfer policy to ensure that an Admin can assist a user who is unable to recover their vault (in the case of lost Master Password).
To perform account recovery for a user, follow the instructions to recover an account using vault transfer.
If this policy is activated, users in the role will not receive email invitations when their account is provisioned. A use case for this might be if the Admin would like to send their own email invitation instead of the system invite. An additional use case for this would be if the Admin is testing the invite process.
The Keeper invitation sent to new users when creating their vault can be re-sent automatically if the user does not create their account in the specified timeframe. The default setting is to only send the email invitation one time. You can increase the frequency depending on the amount of email reminders that you would like users to receive.
By default, Keeper invitations are only valid for 7 days. We recommend automatically resending invitations to ensure the highest levels of adoption.
Users within the specified role can be restricted to use Keeper outside a set of IP address ranges. The IP address must be your external (public) address as seen by the Keeper infrastructure at the time of user login. To add an IP Range, click on Add Range.
Make sure you test IP Allow on a role that is not associated with your account. Adding an invalid IP range could lock you out, or all of your users. If you run into this situation, please contact Enterprise Support.
If Keeper Secrets Manager is activated on a role, the Secrets Manager functionality will appear on the Web Vault, Desktop App and Commander CLI.
To learn more about Keeper Secrets Manager, see:
Secrets ManagerKeeper Password Rotation allows Keeper customers to securely rotate credentials in any cloud-based or on-prem environment. If Password Rotation is activated on a role, the Password Rotation functionality will appear on the Web Vault, Desktop App and Commander CLI.
To learn more about Keeper Password Rotation, visit this page.
To enable account transfer toggle on the switch and select the eligible role which can perform the account transfer from the dropdown menu.
Accounts can only be transferred after the user accepts the transfer account agreement upon Vault login. It is critical that the Transfer Account policy is configured prior to the time it will need to be used.
For detailed Account Transfer configuration information click here.
Keeper Commander, our command-line CLI and Python-based SDK supports the ability to modify roles and enforcement policies.
For more information, visit: Enterprise Role Commands
Here's an example restricting the "Engineering" role to access import records.
Watch the video below to learn more about Enforcement Policies.
Additional information regarding FIDO2 Security Keys in Keeper
Keeper Administrators can enforce the use of FIDO2 security keys, and require that a security key can be used as the only 2FA method. Security Keys can be enforced for any type of account, including Master Password-based login and SSO login.
Administrators can also require the use of PIN associated with the hardware key.
Screenshot below:
Enforcing the use of a FIDO2 hardware security key has several implications for users which admins need to be aware of. The information below is accurate as of May 2024.
Support for enforcing a FIDO2 Security Key can vary based on the device operating system and device firmware capabilities.
Keeper on iOS currently requires using NFC keys, not plug-in keys.
The activation of security keys as the only factor requires the use of the Web Vault or Desktop App. Enrollment of security keys as the only factor on iOS/Android will be rolled out in a later release.
Some components of the mobile application do not support NFC hardware keys natively, such as iOS app extensions (during Autofill functions). The current solution to handle this issue is to extend the login session between iOS main app and iOS autofill extension to reduce the need for re-authentication. To enable this capability, follow the below steps:
From the Web Vault or Desktop App, go to Settings > Security and enable "Stay Logged In"
From the iOS app, go to Settings > and set the Logout Timer to your preferred value.
Now, using the main iOS app and the Autofill functionality will be logged in together
The PIN requirement is supported based on the capabilities of the device. As of this writing, mobile OS support for PIN enforcements is limited. We do not recommend enforcing the PIN if users are accessing Keeper on their mobile device.
Overview of role-based Administrative Permissions
A Keeper role can be granted 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, approve devices 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.
To create a privileged role with admin permissions, click on the + Add Managing Node button in the Administrative Permissions sections.
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 there were three other nodes created under the top, root 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 four nodes and members of that role.
To give Administrative Permissions to a Role, select the + Add Managing Node button on the Role screen.
Select a Node and click OK.
Set permissions by clicking on the gear icon 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 still have an "invited" status.
A description of each permission is below.
Permission | Description |
---|---|
Manage Nodes | The ability to add, remove, or edit nodes. |
Manage Users | The ability to add, remove, or edit users. |
Manage Roles | The ability to add, remove, or edit roles. |
Manage Companies (MSP) | The ability to add, remove, and assign base-plans and secure add-ons to managed companies. Can also launch to the managed companies administrator consoles with full administrative permissions (only appears for MSP customers). |
Manage Teams | The ability to add, remove, or add members to Teams. |
Manage Bridge/SSO | The ability to add, remove, or configure the Enterprise Bridge or SSO. |
Run Security Reports | The ability to run and configure reports (Advanced Reporting & Alerts Module) |
Perform Device Approvals | For SSO cloud users, the ability to approve devices |
Transfer Account | The ability to transfer a user's vault (if the user's Role is configured to allow this. See Account Transfer policy. |
Cascade Node Permissions | If selected, the permissions apply to this node and all sub-nodes. |
Manage record Types in Vault | This permission allows the admin rights to create, edit, or delete Record Types which have pre-defined fields. Record Types appear during creation of records in the user's vault. Learn more about record types. |
Share Admin | Provides elevated access rights over the organization's shared folders and shared records. Learn more about Share Admin. |
Run Compliance Reports | Provides on-demand visibility of the access permissions associated with your enterprise records. Learn more about compliance reports. |
Only administrators who are a currently a member of this role are able to select "Transfer Account". If needed, you can add yourself to the role or another administrator within the role can set this permission.
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 "All Users" specifically to handle the policies that are desired for all the users that have been onboarded to the Keeper platform. If you intend for one of those users to be able to perform some of the administrative permissions, create a new role called "Delegated Admin", grant the administrative permissions, and make the user a member of that role.
Transfer the contents of a vault to another Keeper user
The Account Transfer policy provides business and enterprise customers with the ability to transfer a user's vault if they are terminated or abruptly leave the organization. This 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. This account transfer functionality is an important and powerful way to take ownership of the content within a user's vault while retaining a secure role-based hierarchy.
By default the Account Transfer permission is off. The Keeper 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. It's important to note that this permission will need to be enabled prior to the time it will need to be used. 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 of 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 policy is enabled, the users within the managed role will receive a pop-up notification upon logging into 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 specific 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 is deleted. The end user will receive a notification when their account is locked by the Admin as well as 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. Follow the steps below to perform this action.
(1) Enable the Transfer Account setting within the Administrative Permissions of the role that will have the ability to initiate the account transfer.
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.
Note that a role (e.g. the Keeper Administrator role) must have this permission enabled before any other role can be granted transfer account permission.
(2) Turn on the Enable Transfer Account option under the Transfer Account section of the Enforcement Policy 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).
Both new and existing users will be notified when account transfer is enabled and are required to acknowledge the organization's ability to transfer records from their vault. Users only have to agree to this consent once upon logging into their vaults.
Please note that changing the administrative role from the dropdown will trigger a new acknowledgement notification to both new and existing users regardless of previous acceptance of the notification by users.
Users will see this prompt when they log into their vault:
(1) Lock the account of the user by selecting Lock Account from the user's configuration panel under User Actions (the configured admin will only have the ability to transfer records from a locked user).
(2) From within the same configuration panel, select Transfer Account. A window will open with a list of users. Select the user that will receive the transfer of records (the "recipient"), then select Transfer.
(3). The records, folders, and subfolders in the user’s account are transferred to the recipient's vault into a single folder (with the original owner's email address) and the original owner's account is permanently deleted.
The records contained in the user's "Deleted Items" will be transferred to the recipient's "Deleted Items".
Watch the video below to learn more about Account Transfer.
Account Transfer actions and automation can be performed through the Keeper Commander CLI. See the below related commands:
Keeper Teams allow you to share privileged accounts among pre-defined user groups
The purpose of creating teams is to give users the ability to share the records and folders within their vaults with logical groupings of individuals. The administrator simply creates the teams, sets any Team Restrictions (edit/viewing/sharing of passwords) and adds individual users to the team. Users can be added to teams either manually or using several different automated methods.
Teams can also be used to easily assign Roles to entire groups of users to ensure the consistency of enforcement policies across a collective group of individuals.
Navigate to the Teams tab and select the + Add Team button. Just like Roles, the teams will be added to the specific node that is selected. Enter the team name and click Add Team to save.
Select the team you would like to edit from the Teams tab. From here you can make edits to the team such as change the name, disable record re-shares, disable record edits, and apply privacy screens. You can also change the Node the team belongs to as well as add Users and Roles to the team. To delete the team, simply click the Delete button.
Teams can be configured with several restrictions that will override any folder-level permission settings.
With this restriction in place, passwords shared to this team cannot be re-shared by team members. This restriction will override any permissions set at the Shared Folder level.
With this restriction in place, passwords are usable and viewable but cannot be edited. This restriction will override any permissions set at the Shared Folder level.
Keeper's Privacy Screen feature gives you the ability to control the viewing (unmasking) of all passwords at the team level. With this policy in place, passwords are not visible from the user interface serving as a deterrent from casual observation. This feature is commonly used to limit viewing of passwords for the non-technically savvy users. It is important to note that password masking is only visual in nature and the password is still stored in the user's vault and accessible via API communication and browser inspection. Privacy Screen can also be configured at the role and website domain level in Keeper's Role Policies.
Watch the video below to learn more about the Privacy Screen feature.
Users can be added to teams several ways:
Manually through the Admin Console
Automated through the Keeper Bridge (for AD/LDAP)
Automated through SCIM provisioning (Azure, Okta, etc)
Automated through Keeper Commander CLI
Click the + Add User button to add users to a team.
If you would like to queue invited users into Keeper Teams, you can accomplish this using Keeper Commander's enterprise-team
command. In the example below, we are adding an invited user to a team. This shows in the "Queued User(s)" output.
Queued Teams and Users will be processed using one of the methods described in this page:
https://docs.keeper.io/enterprise-guide/user-and-team-provisioning/approval-queue
Teams can be provisioned in other ways as described in the Keeper Enterprise guide, including:
Keeper AD Bridge https://docs.keeper.io/keeper-bridge/
Automated Provisioning with SSO and SCIM https://docs.keeper.io/enterprise-guide/user-and-team-provisioning
Keeper Commander API https://docs.keeper.io/secrets-manager/commander-cli/overview
Teams and team-user assignments are accomplished through the use of public/private key encryption. Teams have a public/private key. Adding a user to a team involves encrypting the Team Key with the user's Public Key. When creating teams and assigning users to teams using the Admin Console interface, all of the encryption occurs locally because the Admin has the necessary rights and access to the keys required to perform the encryption actions.
Teams and team assignments created by automated methods such as the Keeper AD Bridge and SCIM API don't have the necessary encryption keys in order to fully create the assignments. Therefore, these teams and assignments go into a "queue" system.
Queued Teams and Team-User assignments are processed upon one of the following actions:
Admin logs into the Admin Console (and optionally clicks "Full Sync")
User from the respective team logs in to the Web Vault or Desktop App
Admin runs team-approve commands from Keeper Commander
Admin sets up the Keeper Automator service (version 3.0+)
SCIM and Commander APIs can be approved by following the instructions from the Approval Queue page.
If users are managed through SCIM or the Active Directory Bridge in a particular node within the Enterprise, we recommend performing all team management through the automated methods and the associated identity provider. Manually creating or editing teams from the Admin Console could interfere with your identity provider and generate syncing issues.
Business users can securely share their records and folders with co-workers, contractors and partners across all devices
Sharing Keeper records is a secure and powerful feature of the platform. Keeper offers various easy-to-use sharing capabilities with role-based enforcement policies to solve the most common use cases.
Record and File Sharing - easily share a single record with another Keeper user and choose from various permission types to control access.
Shared Folders - share multiple records in a folder to a specific set of users or Keeper Teams.
One-Time Share - provides time-limited secure sharing of a record to anyone, even if they don't have a Keeper account. This is a useful feature for sharing information with contractors or new employees during their onboarding process.
Share Admin - role-based permission that gives administrators elevated access rights over your organization's shared folders and shared records.
Time-Limited Access - securely share credentials or secrets with other Keeper users on a temporary basis, automatically revoking access at a specified time.
Self-Destructing Records - One-time share records that automatically delete from both sides when shared and viewed.
Individual record and file sharing in the Keeper Vault
A Keeper record can contain credentials, files, two-factor codes, or any type of content. Keeper records can be shared individually with other users. In the example below, the record contains a login/password, Passkey (for MFA), a file attachment and a two-factor code.
Click the Share button.
From the "Add People" tab, click within the email address field and search or type the email address of the Keeper user you would like to share the record with.
Click the dropdown arrow to set their permission level (can edit, share, edit & share, view only and transfer ownership) and click Add
.
Sharing within an existing Keeper Enterprise tenant does not require any further steps. If you are sharing with a person outside of the tenant, you will first need to establish a "sharing relationship". The user will receive an email prompting them to login to Keeper and either accept or deny the share request. Once you establish a sharing relationship, the user will appear in the email dropdown list.
User Permissions are designed to control the permissions a user has over the record that is shared with them.
Permission Name | Permission Level |
---|---|
Can Edit | User can edit this record |
Can Share | User can share this record |
Can Edit & Share | User can edit and share this record |
View Only | User can only view the record |
Transfer Ownership | User will obtain ownership of the record and control the user permissions |
The use of record and file sharing can be restricted by the Keeper Administrator in the Roles section of the Keeper Admin Console.
Record sharing commands are available from the Keeper Commander CLI tool. This provides advanced users with the ability to script and automate any sharing actions.
For more info, see: Commander Sharing Commands
Private folder and shared team folders in the Keeper Vault
Keeper's Private Folder, Shared Folder and Subfolder capabilities are flexible and secure. Private Folders and Shared Folders can be created within the vault (if permitted by the Admin). Users and Teams may be provisioned automatically from Active Directory through the Keeper Bridge, or from SCIM-connected identity providers such as Azure, Okta and Google Workspace allowing for simple setup of shared folder permissions.
A private folder is only visible to the user who created the folder and can be made up of subfolders and records. A folder can also contain other shared folders and shared records. To create a private folder, click Create New > Folder. Choose where you would like to nest the folder using the dropdown menu. You can select the parent folder or select My Vault to add the folder at the root level.
A shared folder can be shared with an individual Keeper user or with a Team of users (as designated in the Admin Console). Shared Folder permissions can be applied to Users, Teams and Records.
To create a Shared Folder, click Create New > Shared Folder. Choose where you would like to nest the folder using the dropdown menu. You can select the parent folder or select My Vault to add the folder at the root level. Next enter the name of the folder and set the User and Folder Permissions.
A Team can be setup in the Admin Console manually from Admin Panel and the Teams tab by clicking on the Add Team button and then selecting users via the + user checkbox dialogue.
Alternatively, when a user is provisioned to a Team through any of the previously described onboarding methods (Active Directory Bridge, SSO, Azure AD, SCIM, API, etc...), the user will instantly receive the shared folders for that team, and the records associated with those shared folders. When the user is removed from a team, their access is revoked from any shared folders and those folders are immediately removed from their vault.
Any user within the Keeper Vault can create a private folder or shared folder (unless restricted by their Keeper Administrator).
You can add records to the folder by a simple drag-and-drop or you can click Edit and add the records using the record search bar.
Record Permissions are used to govern folder members' (users) interactions with each individual record in the folder. You can access these permissions from the Records Tab by clicking Edit and then the dropdown icon next to each record name.
Permission | Description |
---|---|
Can Edit | Users in the folder can edit this record |
Can Share | Users in the folder can share this record |
Can Edit & Share | Users in the folder can edit and share this record |
View Only | Users in the folder can only view this record |
While in Edit mode, from the "Users" tab, click within the email address field and enter the email address of the Keeper user (including Share Admins) or Team you would like to share the folder with.
Next, set the user permissions by clicking on the dropdown arrow next to each user's email.
Permission | Description |
---|---|
Can Manage Users | The user can add or remove other users in the folder |
Can Manage Records | The user can add or remove records in the folder |
Can Manage Users & Records | The user can add or remove other users and records in the folder |
No User Permissions | The user will have no permissions over the other users or records in the folder |
To create a Subfolder within a Shared Folder, right-click on a Shared Folder and select New Folder. You can add records to the folder by a simple drag-and-drop or you can click Edit and add the records using the record search bar.
While viewing the records within a Shared Folder, click the Edit Icon and check the box next to “Show subfolder records" located in the Records tab to include those records in view or leave it unchecked to collapse them from view.
Both private and shared folders can be nested and contain an unlimited number of records or subfolders. Each subfolder inherits the same permissions structure as the parent folder.
If the parent folder is a shared folder and you move a private folder into it, the private folder will now inherit the permissions set from the shared folder, including the users that have permission to view and edit that folder and its records.
In the screen capture below, the Region 1 folder is not shared but 1 of its 2 subfolders is shared (Monthly Sales Projections) as noted by the shared folder icon. Region 2 is a shared folder so all the records contained within its subfolders are also shared and they as noted in their shared record icons.
Note that only the parent shared folder will display the shared folder icon.
Shared Folder Settings are configured in order to easily set folder permissions for all users within the folder. These are selected upon the initial creation of the Shared Folder, but you can change them at any time by clicking the Edit Icon > Settings. Click the dropdown arrows to set the Record and User Permissions for the folder.
Please note, newly created records inherit these permissions when adding users or records to the shared folder.
In order for the "subfolders" checkbox to appear, you must first click the "Show subfolder records" checkbox located in the Records tab.
If the Default Folder Settings are not set properly, users who add records to the Shared Folder will find that the records are "View Only" by other members of the Shared Folder, even if those users have "Can Manage Records" permission. If you would like all folder members to have edit rights over all records that are added to the folder, set the Default Folder Settings to Can Edit Records.
The Can Manage Records setting only allows users the ability to add or remove records, it does NOT give them record permissions.
Once the default configuration is set, it will only affect users and records added after the change was made. To edit permissions for the users or records added prior to the default configuration, change them individually or through a bulk change.
A Folder and a Shared Folder are objects that are created independently of records. Keeper's implementation of Subfolders (Nested Folders) is powerful and flexible, providing Enterprise customers with the most secure encryption model while providing ease-of-use functionality such as drag-and-drop.
A folder can be made up of private records, shared records or other regular subfolders.
Subfolders can be either shared or private.
You can create an unlimited number of folders and shared folders.
A shared folder can be made up of an unlimited number of subfolders, each subfolder beneath a shared folder retains the permissions of the parent.
There is no limit to the folder tree depth.
A folder is a container of records and record references (shortcuts).
A shared folder is a container of records, with flexible user and team sharing capability.
Folders and subfolders contained within Shared Folders will inherit the permission of the Shared Folder.
Watch the video below to learn about creating shared folders and assigning permissions.
Keeper Commander, our command-line SDK toolkit, provides a method of bulk record permission changes. Commander has special features that can be executed on the CLI instead of using the user interface. To download Keeper Commander binaries on Mac or PC please visit:
https://github.com/Keeper-Security/Commander/releases Or, to install the CLI in a developer mode, please follow the installation instructions in the documentation here:
https://github.com/Keeper-Security/Commander
Example: Elevate Permissions on All Records
In this example, we will recursively change the record permissions in a Shared Folder.
(1) Identify the Shared Folder UID on the Vault user interface, or from the Commander CLI.
On Commander, you can use the "ls -l" command, similar to a Bash shell.
On the Vault user interface, you can click on the info icon to display the Shared Folder UID.
(2) On Commander, execute the "record-permission" command with the "--dry-run" option to simulate the command. In this example, the Shared Folder UID is "-FHdesR_GSERHUwBg4vTXw". The command is below:
As you can see, the Shared Folder UID starts with a dash so we add "--" before the identifier to escape the character.
Running this command produces the following output:
The "SKIP" section is saying that the current user on Commander cannot make those requested changes, because we are not the owner of the record. The "GRANT" section indicates the changes that will be allowed.
(3) To execute the command, we remove the "--dry-run" portion:
Now, on the Vault UI, the permission of those affected records has been changed to "Can Edit".
If you are in a situation with many record owners in the same shared folder that require update, each of those users can simply run the above Commander action to change the permissions of their respective records.
Keeper's Share Admin feature is a role-based permission that gives administrators elevated access rights over your organization's shared folders and shared records.
A record can exist outside of a folder, inside a folder or inside a Shared Folder. A record can also be linked into multiple folders or Shared Folders. A linked record is also referred to as a Shortcut. In either case, modifying a linked record will change it everywhere it has a shortcut.
There are two ways to move a record into a folder:
Drag-and-drop the record from the list of records and select Move when prompted
Right-click on a record and select Move To...
Watch the video below to learn about adding records to shared folders.
Use one of the following methods to to add a record to multiple folders (create a Shortcut):
Select the Folder and then select Edit. In the Add Records search box, search for the records to add and select Add. This method will always add a Shortcut to the folder.
Drag-and-Drop the record from list of records and select Create Shortcut when prompted
Right-click on a record from the list of records and select Create Shortcut...
Teams are created by the Keeper Administrator, or any user who has been given administrative permissions for a specific node or organizational unit. A team is made up of users within a node or sub-node. Additionally, there is no limit to the number of teams that can be created. Teams can be provisioned using any of the following methods:
Manual creation in the Keeper Admin Console
Automatically provisioned through the Active Directory / LDAP Bridge software
Automatically provisioned through SCIM
Automatically provisioned through the Keeper Commander SDK
At the encryption layer, Teams have a public and private key pair. In order to add a user to a team, you must first be a member of the team because you need to encrypt the Team Key with the recipient's public key. When the recipient logs into their vault, the Team Key is retrieved by decrypting it with the user's private key. This encryption process is automatically handled by the provisioning methods listed above.
Inside the Admin Console there are several team security options. Teams that are added to a shared folder can be given limited rights:
Disable record re-shares
Disable record edits
Apply privacy screen
A user with access to a Shared Folder has the option to remove themselves from the Shared Folder. If the user has been granted the Can Manage Users & Records permission, the user also has the ability to delete the Shared Folder.
When a Shared Folder is Deleted, the records stored in the shared folder will be moved to the "Deleted Items" section of the vault, for the owner of each record.
Users can change the color of a shared folder in order to make is stand out visually. This can be done on both Shared Folders and Private Folders.
The use of shared folders can be restricted by the Keeper Administrator in the Roles section of the Keeper Admin Console.
Time-limited secure sharing of a record to anyone without having to create a Keeper account
Keeper "One-Time Share" provides time-limited secure sharing of a record to anyone without having to create a Keeper account. One-Time Share is the most secure way to send confidential information to an external person or contractor without exposing information over email, text message or messaging.
One-Time Shares are secure by design, utilizing Keeper's Zero-Knowledge encryption. The record data is decrypted locally on the recipient's device using 256-bit AES and all requests to the server are signed with elliptic-curve cryptography (ECDSA).
One-Time Share is only available on new record types. Legacy "General" records are not compatible. If you're not seeing the One-Time Share feature, change the record to a login type, or create a new record.
To create a One-Time Share, open a Keeper record and click on the Edit Icon > One-Time Share.
Select how long the share link should be valid. The record will expire at a time of your choosing, and it can only be viewed on one device. Even if you forget to un-share the record, it will expire and access will be revoked.
Share links will expire after the selected amount of time, if the link is never used. If the link is used and bound to a device, the record access will expire after the same amount of time.
You can either copy the Link only, the Invitation to share the record with another person, or simply scan the QR code.
When the recipient opens the link, the record will render in the device browser.
As an additional layer of security, One-Time Shares are device-locked which means that only the original recipient is able to access the data. If the link is later opened up by a third party, or your email account is compromised, the link cannot be accessed, except on the original device.
Share access credentials with a contractor
Share an encrypted file with a co-worker
Provide secure documentation or instructions
One-Time Share links can be sent to recipients through any trusted channel, such as:
Direct QR Code Scan
Airdrop
SMS
Enterprise messaging platforms
Any other out-of-band channel
The applications and uses for this are virtually endless. Any time you have a need to securely deliver data to a non-Keeper user, One-Time Shares are the perfect choice.
For existing Enterprise customers, One-Time Share is disabled on all default role policies.
To allow this feature on your existing default role policies, visit the Role > Enforcement Policies > Creating and Sharing.
For all new role policies created after the launch of the One-Time Share feature, it is enabled by default.
Create One-Time Share links programmatically using the Keeper Commander CLI tool. Relevant commands:
Commander offers additional controls such as fine-grained expiration times, additional output methods, and the ability to remove previously created One-Time Shares.
For more information see our Keeper Commander Documentation.
The encryption model implemented for one-time sharing uses the same technology as Keeper Secrets Manager, a zero-knowledge and zero-trust platform for protecting cloud infrastructure.
The security model and method of encryption is detailed below:
(1) In the vault, the sharer generates a one-time access token by clicking on "One-Time Share" in the record options screen. The 256-bit AES Record Key for the record being shared is encrypted with the one-time access token, and this encrypted value is stored in the Keeper Cloud.
(2) The sharer sends the One-Time Access Token to a recipient via a simple URL or QR code through their preferred channel. The URL portion that contains the access token is held within the "fragment identifier" section of the URL which is never sent over the network to Keeper's servers. Therefore, zero-knowledge is retained and Keeper has no ability to access or decrypt the information.
(3) The recipient opens the URL on their device browser, and a single-page Vault application is loaded on the device. The One-Time Access Token is handed off directly to the local vault application (not sent to the server).
(4) Upon loading the URL, the recipient's device generates a client-side public/private Elliptic Curve key pair, and the private key is stored locally on the Client Device in the browser's CryptoKey storage.
(5) Upon first use, the SDK library authenticates using the hash of the One Time Access Token and upon successful authentication, the server responds with the encrypted record ciphertext plus the Encrypted Record Key.
(6) The Client decrypts the Record Key with the One Time Access Token, and the record contents are decrypted using the Record Key. The Record Key is then stored locally on the client device in the browser's CryptoKey storage or other designated storage location.
(7) On the server, the encrypted record key for that given device is deleted so that the One Time Access Token cannot be used again. After that, the client's requests must be signed with the Client Private Key.
(8) Subsequent calls on the same device to the server are sent with an identifier which uniquely defines the device (hash of the one-time access token) and a request body that is signed with the Client Private Key. The server checks the ECDSA signature of the request for the given device identifier using the Client Public Key of the device. The Keeper Cloud processes the request for the record, and the server returns encrypted record ciphertext to the Client upon successful authentication.
(9) In addition to the record-level encryption, the Client Device creates a randomly generated AES-256 bit Transmission Key which is encrypted with the public key of the Keeper cloud API. The Client Device decrypts the response from the server with the Transmission Key and then decrypts the ciphertext response payload with the Record Key, which decrypts the contents of the record.
Additional details about Keeper's encryption model is documented here.
The use of One-Time Sharing can be restricted by the Keeper Administrator in the Roles section of the Keeper Admin Console.
Elevated rights to Shared Folders and Records
Keeper's Share Admin feature is a role-based permission that gives administrators elevated access rights over your organization's shared folders and shared records.
Share Admins have full user and record privileges for any shared record that they have access to.
From the Admin Console, assign a role with Share Admin privilege
From the Vault, add the Share Admin user to the folder or record
The Share Admin will immediately have full access rights on their Shared Folders
Restrictions
(1) The Share Admin can only take effect on Shared Folders that are owner/created by users within the Enterprise.
(2) The Share Admin can only take effect on Shared Folders that are owner/created by users within nodes under management by the Share Admin
(3) These restrictions are useful when you have Share Administrators that are managing just an organizational unit (or Node) and not the entire company.
(4) The Share Admin user must be added to folders they wish to manage. Anyone with "Can Manage Users" can add the Share Admin to the designated shared folder or record.
Add or remove records and users from shared folders
Change folder default permissions
Modify record permissions
Transfer record ownership to other users
Delete shared folders
In support of least-privileged access, Share Administrator permissions are granted via Role-Based Enforcement Policies. This provides the ability to grant Share Administrator rights to a limited group of administrators and provide elevated access rights to your organizations shared records and folders.
To assign someone in your organization Share Admin permissions, first create a role or select an existing role. Under administrative permissions click on the gear icon to display the list of permissions and select “Share Admin”.
In Keeper Commander, you can also run this command on the CLI:
To learn more about Keeper Commander visit: https://docs.keeper.io/secrets-manager/commander-cli/overview
While in edit mode for the shared folder, select the Users tab then click within the user search bar. Your organization’s available Share Admins will appear at the top of the list. Select the share admin(s) you would like to invite to the folder and click Add.
Individual Records
Share Admins can also be added directly to an individual record through the Share Record screen.
Once a shared record or folder is shared with the Share Administrator, they will immediately be granted full permissions over the Shared Folders or Records.
From the vault, a user with Share Admin permission for a shared folder is able to view all shared folder content, change shared folder default permissions, add or remove records and users, and delete the shared folder. The Share Admin can change record permissions for those records owned by users managed by the Share Admin. Changing record permissions includes editing, sharing, or transferring ownership.
Users can view who has Share Admin permissions over a folder by clicking on the Folder Information icon.
Share Admins can add or remove users and records from Shared Folders, no matter who owns the record.
Share Admins can change record permissions of any record within a Shared Folder or a direct share.
Share Admins can change the Default Folder Settings of any Shared Folder.
Share Admins can delete Shared Folders or Shared Records.
Share Admins have full record edit permissions including the right to transfer ownership of single or multiple records at once. To transfer ownership of multiple records, select the records, then right-click to reveal the context menu and select transfer ownership.
Enter the new owner’s email address or select it from the dropdown and click the transfer ownership button.
The transfer is verified if successful, if not, you will receive a notification of any records that are unable to be transferred. Share Admins can also perform a transfer of ownership of a single record directly from the record’s “Options” menu.
Share Admins can use the Commander CLI for making changes to Shared Folders and Shared Records. For example:
Record Commands such as edit
Sharing Commands such as share-record
, record-permissions
and share-folder
To learn more about Keeper Commander visit: https://docs.keeper.io/secrets-manager/commander-cli/overview
Share Admins will show up in the Compliance Reports interface as seen below:
Some use cases for Share Admin include:
Simplifies the process of editing record permissions when there are multiple users who contribute to a Shared Folder with mixed permission settings
Shared Folders that were created with unintentionally restrictive settings can be updated easily
Shared folder contains records that need to be moved to another shared folder
Records need to be transferred without having to completely transfer an entire vault
Temporarily elevate rights to make folder permission and record changes
How do I view the Share Admins for a shared folder in my vault?
Click the “Info” icon to reveal the shared folder detail panel. Share Admins are listed in the information dialog.
As a shared folder participant, how do I know who the “Share Admins” are for the organization so that I can invite them to participate in my shared folder?
While in edit mode for the shared folder, select the “Users” tab and “Add” users button. The organization’s available Share Admins will appear at the top of the list.
What happens to a consumer’s shared folder with owned records, if the consumer shares the folder with an enterprise user who is a Share Administrator, and the records in the shared folder have “read only” access?
The Share Admin does not manage the consumer, which means that the Share Admin cannot change record permissions and would have “read only” access to the records owned by the consumer. However, the Share Admin can manage the shared folder, users and records in the shared folder. These permissions allow the Share Admin to remove or invite users to the shared folder, change default folder permissions, or even delete the shared folder.
Given this scenario: A consumer has a shared folder with owned records and the consumer shares the folder to two users of the same enterprise with Manage Record permissions, where one of them is a Share Administrator. The non-share administrator adds a record to the folder. Can the Share Administrator manage users for this folder in this scenario since they can manage user access for records of managed record owners?
Yes. The Share Admin can manage (add/remove) any record or user from the shared folder. Additionally, if the non-share admin is associated with a node managed by the share administrator, the share administrator can change record permissions for those records owned by the administrator that does not have share admin permission.
What happens if a shared folder is shared between two businesses and there are shared folder administrators participating in the shared folder from both businesses.
The Share Admin can edit the default shared folder permissions, add/remove users and records from the shared folder, and edit record permissions for records that are owned by their managed users. If a record is removed from the shared folder, and it is the last reference to that record, it is moved to the record owner’s trash bin.
Are Share Admin permissions shown in Compliance Reports?
Yes. If a user has Share Admin access to records in a Compliance Report, this is shown in the report.
Can a Share Admin be removed from the Share Admin role and/or removed from a shared folder? If so, what happens to their permissions?
A Keeper Administrator can be temporarily assigned to a role with Share Admin permission. When they are removed from this role, their permissions to shared folders and records will revert to their previous shared folder permissions. A Share Admin can be removed from a Shared Folder by any participant that has “manage users” permission.
Will Share Admin permission be turned "on" by default for the Keeper Administrator role?
Yes. This permission is automatically turned on for the default Keeper Administrator role.
Time-Limited Access allows you to securely share records and folders with other Keeper users on a temporary basis.
Time-Limited Access allows you to securely share credentials or secrets with other Keeper users on a temporary basis, automatically revoking access at a specified time. Time-Limited Access prevents long standing privileges and ensures that information is removed from the recipient’s vault, greatly reducing the risk of unauthorized access.
Revoked access at a specified time designated by the record owner, minimizing the workload on the owner to remove the share at a later time.
Enhances security as traditional short term sharing has been done in insecure ways like using sticky notes, text messages or instant messengers.
Simplified compliance with event tracking on all sharing activity, ensuring least privilege access is maintained.
When paired with Keeper Secrets Manager (KSM) automatic service account rotation capabilities, users can schedule rotation of the shared credential upon the expiration of access, ensuring the recipient never has standing privilege
Select the record from your vault and click Share, entering their email address or selecting it from your contacts list. Set their permission level and click Add.
Select the “Permissions” dropdown and click Set Expiration. Here you can select one of the default expirations or click custom date and time to set your own. Next, check the box if you would like the record owner, such as yourself, or users with edit access to be notified via email when the recipient's record access expires. Click Done to save.
The recipient of a shared record with time-limited access may have "view" and "edit" permissions but will not be able to share the record. If "share" permissions are applied, the expiration will be removed.
Open the shared folder from your vault and click the edit icon and from the “Users” tab, add the user or team you would like to share the folder with.
Set their permissions and from the dropdown menu click Set Expiration, following the same steps you would for a single record share (described above).
Next, check the box if you would like users with "can manage records" permissions over the folder to be notified via email when the recipient's record access expires. Click Done to save.
The recipient of a shared folder with time-limited access may have "can manage records" permissions, but the ability to "manage users" is restricted. If these permissions are applied, the expiration will be removed.
Self-Destructing Records allow you to share records with user's outside of Keeper, while automatically deleting the record from your vault and disabling the share link at specified time
Self-Destructing Records utilize Keeper’s existing One-Time Share technology which allows time-limited, secure sharing of a record to anyone, even if they don’t have a Keeper account.
Self-Destructing Records take our One-Time Share feature even further by automatically deleting the record from your vault once the share link is disabled and the recipient’s access is revoked. This reduces your workload to revoke record access and removing it from your vault at a later time.
Providing the most secure, encrypted method to send sensitive information to users outside of your organization without exposing sensitive information in plain text over email, text message or messaging.
Avoids the accumulation of unnecessary privileges within an organization over time.
Assurance that the details of a shared record remain with the recipient, on a single device.
To create a Self-Destructing Record, create a new record as you normally would. Enter the record details and click Add Self-Destruct.
From the menu that is now presented, select when you want the share link to expire.
Once you've made your selection, click Save & Share to generate a One-Time Share link.
You have the option to copy the link directly, or send it in an invite or QR code format.
The recipient of a Self-Destructing Record simply clicks on the provided link and is instantly presented with the shared record in their web browser. One-Time Share links are bound to a single device, further strengthening security and preventing unauthorized distribution or viewing on multiple devices. The link will expire at the specified time or once the recipient has viewed the record for five minutes, whichever comes first.
Keeper's Self-Destructing Records allow you to securely share records with file attachments that self-destruct at a specified time.
Create a record as you normally would and click Add Attachments to upload your file, or simply drag and drop the file directly into your vault.
Click Add Self-Destruct, select when you want the share link to expire, then click Save & Share to generate a One-Time Share link.
The recipient of a Self-Destructing Record simply clicks on the provided link and is instantly presented with the shared record in their web browser. They can then click on the file to download it to their local device.
You can delete a Self-Destructing Record at any time, thus disabling the share link by clicking Delete Now. Deleted Self-Destructing Records will appear in your vault's “Deleted Items” with the option to "Restore".
How to create, manage, import and export data in your Keeper vault
A Keeper record can be any password, file or secret information that is stored in your encrypted vault. When a new user signs up for Keeper, they are walked through a step-by-step guide to import existing passwords from their web browser, other password manager or file upload. They will also be walked through the process of creating records manually through their desktop computer.
Users can create new vault records many different ways including:
Manual creation on the Desktop App, Web Vault, Browser Extensions or Mobile App
Import from another password manager like Chrome, iCloud Keychain, Keepass, LastPass, Dashlane, 1Password and many more.
Import from a .CSV or .JSON text file
Automated LastPass transfer Vault-to-Vault
Command-line and automated SDK
Records created in any platform will instantly sync to the user's other devices. Records that are shared among users will receive updates in real time.
Keeper's Import Tool will seamlessly import passwords that are stored in Chrome, Firefox, Safari, iCloud, Edge and Internet Explorer web browsers on your computer.
From the Web Vault or Desktop App, click your account email address > Settings > Import. On the Web Vault, you will be then prompted to download Keeper's Import Tool. On the Desktop App, the import will start immediately.
More information about the Keeper Import tool can be found at the User Guide below: https://docs.keeper.io/user-guides/import-records-1/import-from-chrome-firefox-ie-edge-and-opera
Keeper support drag-and-drop import of files from other password managers or text files. From the Web Vault or Keeper Desktop app, select Settings > Import and then select the password manager you'd like to import your passwords from. Click View Import Instructions for step-by-step instructions to generate the proper file format from the original password manager. Once the file has been created, drag-and-drop it into the "Drop a File Here" field.
Keeper's Desktop Application supports an automated transfer of vault records from LastPass to Keeper. To perform an import, follow these steps:
Download the Keeper Desktop App from: https://keepersecurity.com/download
Login to Keeper Desktop using your Master Password.
Click on your account email address in the upper right-hand corner.
Click Settings > Import.
Choose LastPass.
Input your LastPass Email and Password and click Next.
Keeper's CSV import method also supports advanced structure including Folders, Subfolders and Shared Folders.
File Format
• To specify subfolders, use backslash "\" between folder names • To make a Shared Folder specify the name or path to it in the 7th field
Example 1: Create a regular folder at the root level with 2 custom fields
Example 2: Create a shared subfolder with edit and re-share permission, inside a regular folder
Example 3: Create a shared folder with edit and re-share permission on the outside and a nested folder tree underneath.
In this 3rd example, the outer shared folder is called "Family Records" and underneath is a folder tree. The record is added to the nested folder 3 levels down.
To visually see how the import will look, drag and drop the file into the Import screen and click Next. You'll see a preview of the structure:
More detailed and advanced CSV import instructions can be found here: https://docs.keeper.io/user-guides/import-records-1/import-a-.csv-file
The Keeper Commander SDK provides command-line or scripted capabilities to import records and folders into your Keeper Vault. Supported import formats are JSON, CSV, LastPass and Keepass.
JSON import files can contain records, folders, subfolders, shared folders, default folder permissions and user/team permissions.
CSV import files contain records, folders, subfolders, shared folders and default shared folder permissions.
Keepass files will transfer records, file attachments, folders and subfolders.
LastPass import will transfer records, file attachments, shared folders and permissions.
Most features available in the Keeper Admin Console are available through Commander's interactive shell and SDK interface. Learn more about Keeper Commander at https://docs.keeper.io/secrets-manager/commander-cli/overview
Keeper provides many ways of importing structured data. See the Importing Data page for additional details.
From any Keeper Vault application, select Create New > Record to add a record. When creating a record, you may select the Dice icon to generate a strong, unique password. Once you have entered the details of your records, click Save to finish.
Keeper's password generator "Dice" button will auto-generate a strong and complex password. The user can customize the length and complexity level. Admin policies can also enforce the password complexity strength on a global or per-domain basis via Role policies.
Using the password generator feature will not automatically change the website's existing login password. You still must visit the corresponding website's "Change Password" form to update the old password to match the new, stronger password.
The Keeper Browser Extension for Chrome, Firefox, Safari, Edge, Opera and Internet Explorer browsers can be used to dynamically add records to your vault and Autofill passwords.
To download KeeperFill for your browser, visit: https://keepersecurity.com/download.html
Create New records From any website login screen, select Create New and then fill in the appropriate fields. Select the check mark to save the record and autofill the login and password.
Prompt to Login & Fill When visiting a website login screen, Keeper will ask you to automatically login with your saved password.
Prompt to Change Password KeeperFill makes it easy to change your passwords. When a user visits a site's "Change Password" form, you will receive a prompt from Keeper asking if you would like help changing your password. By clicking Yes Keeper will run a wizard that walks you through a few quick steps to change your password and simultaneously update the record in your vault. These steps will include a series of prompts detailing the following actions:
Autofill your old/current password
Automatically generate and autofill a new secure password
Confirm the changes and save them to your vault
A Keeper Login record is made up of the following fields:
Title
Login (Email or Username)
Password
Website Address - This field is required to Autofill forms on websites. For security reasons, the website address (e.g. google.com) must match the website that you are visiting.
Custom Fields - Creating Custom Fields takes away the pain of having to manually copy and paste your information into websites. For example, if you have a website like this one from the USAA Bank, it requires a PIN field, in addition to Password. Corresponding the website field title and the Custom Field Name will allow Keeper to auto-fill these fields with their values. Custom Fields may also allow the user to use the same record for multiple websites. For example, if a user has the same login and password for Amazon.com and eBay.com, the user may add the website address in the Custom Field Value and that single record will now recognize two different website logins. This allows the user to not have to create a record for each website where that username and password are used.
File Attachments - File attachments can be any type of file, photo, video or other document. An unlimited number of files can be attached to any Keeper vault record. File storage is an add-on subscription. If file storage is disabled, please contact your Keeper administrator or email sales@keepersecurity.com.
Two-Factor Codes - Keeper can protect and generate 2FA codes for any website or service that supports the use of TOTP (Time-Based One-Time-Passwords).
Notes - Any free-form notes can be protected in this field such as access instructions or confidential documentation.
Keeper records can be shared on an individual basis to other Keeper users. Keeper sharing technology uses secure RSA encryption to exchange the individual record keys. Therefore, in order to share or transfer a record to another user, the recipient must first have a Keeper account. Attempting to share to a user without a Keeper account will invite them to the platform. For more detailed information, visit Keeper's Security Architecture. To share a Keeper record with another user, while viewing the record, select Options > Share and then enter the email address of the recipient (or select from previously shared users). Edit and re-share permission can be applied to any shared records. Role enforcement policies can be applied from the Keeper Admin Console to control the ability for records to be shared. 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.
Shared folders can also be created which contain records, teams, users and permissions. You can create Shared Folders from the Web Vault, Commander CLI, import files or Desktop/Mobile Apps.
For more information on Shared Folders see page: Folders and Shared Folders
Record ownership can be transferred to another Keeper user. To perform a transfer, while viewing a record, select Options > Share and enter the email address of the recipient (or select from previously shared users). Select Transfer Ownership from the sharing permission dropdown menu. Note that after transferring record ownership, the record will no longer be accessible from your vault.
Through the use of Keeper Commander, records can be pushed to users in bulk.
Example usage of the "enterprise-push" command:
The "push.json" file is structured an an array of password object, for example:
Supported template parameters:
For more information about Keeper Commander please see our Github Page.
Every record created by a user is automatically backed-up through the Keeper Cloud Security Vault architecture. Every record change is also backed-up and a record version is created upon each change event. Each record is identified by a record UID and each record can have an unlimited number of version identifiers. Version History is a critical capability to ensure that a password or record change is never lost by accident. Version History also ensures that a deleted record can be recovered. When a record is deleted by the record owner, the record is moved into the Deleted Records trash bin. Records will remain in this location until the record owner explicitly empties the trash bin. Users can view the Version History of any Keeper record through Keeper Web Vault or Keeper Desktop App. To view a record's history, select a record, then select Options > Record History.
Each record version is tagged with a version number and modification date. Click on the record to display the old version. Then click on "Restore" to revert back to the old version. Restoring the version will also generate a new revision.
The Keeper Web Vault and Keeper Desktop App include an Export capability which can be enabled by the Keeper Administrator. Exporting records from your vault can serve as a backup mechanism, however this does not retain any information about sharing relationships, folder structure or file attachments. If Export is allowed by the Keeper Administrator, we recommend that the customer stores the exported files in a secure location on an encrypted file system. The security and encryption model of Keeper purposely does not permit a Keeper Administrator to export user vaults. A user must be authorized on a Keeper record via the Team or User sharing capability in order to access and export vault information.
Keeper Commander has the additional capability of exporting data to an encrypted Keepass file which retains file attachments.
Offline Mode allows users to have access to their vault from a web browser when they are not able to connect online to Keeper or to their SSO (if they have one). Note that “thick clients” such as desktop and mobile phones already have this capability, but it has been extended to users operating from web browsers.
Offline Mode is made possible by making a copy of your online vault to your local device. A user's vault data is stored in an encrypted format which is only accessible by providing their Master Password. Note, multiple users can share a single device (e.g. a laptop PC) and all users are able have their vault stored safely on that PC when offline.
A user’s devices (e.g. laptops that might not have offline access) will need to be “primed” with a cache of their vault by logging in with an online connection at least once. A mirror copy of their vault will be replicated to that device once completed.
User’s will know if their vault is available when offline via a lightning bolt icon indicating it has been loaded on that device when they attempt to access their vault offline. If the icon is not present, then that device will need to be setup using the steps described above. The X next to the user's email address allows a user to delete the local copy of their vault from the device.
Click on "Work Offline" to use Keeper in offline mode. Offline mode must be explicitly approved by the Keeper Administrator in the Role enforcement settings.
Once logged in, a user will know if they are offline by an Offline Mode text indicator at the top of their vault screen.
Not all vault features are available online and records will be "read only". For instance users can't create any new vault content such as record or folders when offline. When such a limitation occurs then a notice will be displayed.
SSO Account
If your organization's SSO is not available (e.g. is offline), then click on Work Offline to gain access to your vault offline using a Master Password.
Note: A user's Master Password has to be setup by the user via the Settings menu for this offline access to be available.
See the Role, RBAC and Permissions, Account Settings page for instructions on how to restrict Offline Access.
Keeper's data import capabilities are advanced and flexible.
Keeper provides several methods of migrating vault data from 3rd party products and automatically importing data into the vault. Each method is fully documented with screenshots and example data.
The Keeper Web Vault and Desktop App provide automatic import of passwords from all popular web browsers. Keeper provides a standalone Importer tool that is downloaded and installed from the Web Vault
https://docs.keeper.io/user-guides/import-records-1/import-from-chrome-firefox-ie-edge-and-opera
Customers can also import passwords through the Keeper Desktop native application. From the Desktop App, simply click on Settings > Import > click "Import" to begin the import process.
Download Keeper Desktop here:
https://www.keepersecurity.com/download.html
CSV files and Excel files are supported. More instructions here:
https://docs.keeper.io/user-guides/import-records-1/import-a-.csv-file
For advanced users, Keeper Commander CLI supports CSV file import.
JSON files are supported. More instructions here:
https://docs.keeper.io/user-guides/import-records-1/import-json
For advanced users, Keeper Commander CLI supports CSV file import.
Looking for a different import source? Drop us an email at feedback@keepersecurity.com.
How to create and manage new types of records in your Vault
A Keeper Record Type is a structured template that can contain any type of information such as logins, payment cards, bank accounts, and many more. There are several out-of-the-box record types available, and Admins can create custom types that fit the needs of your organization. Custom types can be created for all users, or users within specific roles.
Below are the list of available record types.
Record Type | Description |
Login | The set of data needed to successfully login to a website. |
Payment Card | Credit card information, used in autofilling of forms. Payment cards can also be "linked" to other records, to reduce duplication of data. |
Contact | Identity information about a particular person. We recommend you create one with your information, used in autofilling of forms. |
Address | Address information used to identify a physical location. Address records can also be "linked" to other records, to reduce duplication of data. |
Bank Account | Banking information, such as account number and routing numbers. |
File Attachment | One or more files can exist in a file record. |
Photo | One or more photos can exist in a photo record. |
Driver's License | Drivers license information, such as name, number and expiration. We recommend you store pictures of both the front and back in this record type. |
Birth Certificate | Birth information such as date of birth and name. We recommend you store a high quality scan of your birth certificate in this record type. |
Database | Database information such as Type, hostname and port. Can be used to rotate database credentials in Commander. |
Server | Server information such as hostname and login info. Can be used to rotate or connect to servers in Commander. |
Health Insurance | Health insurance information such as account number and the insured's contact info. |
Membership | Membership information including account information and name. We recommend you store a scan of membership barcodes in this record type. |
Secure Note | Secure information that is masked when the record is viewed. The record contents can be unmasked at will. |
Passport | Passport information such as number and expiration. We recommend you store a high quality scan of your main passport page in this record type. |
Identity Card | Identity information such as number and expiration. We recommend you store a high quality scan of your ID card in this record type. |
Software License | Software license information such as the license number and purchase date. |
SSH Key | SSH information, such as public and private key strings. We recommend you attach any relevant key files in this record type. |
Custom | Business customers can create custom types that will appear for users. |
General | Legacy format, used for records created before the launch of Record Types. |
On any record created as a new Record Type, there are several new "Custom Field" types available that can be added to any record.
Available Custom Record Fields
Text
Date
Pin Code
URL
Phone Number
Security Question & Answer
Name
Payment Card
Multi-line Text
Address
Hidden Field
Native App Filler (see KeeperFill for Apps)
Record Types can be shared to other users, either direct sharing or within a Shared Folder, just like any other record. This now includes Payment Cards and Contact record types.
The Payment Cards stored in the "Identity & Payments" section of the vault is separate, and cannot be shared to other users. To make a Payment Card available for sharing, please create the record within the Vault section. Migration from data stored in Identity & Payments is planned for a future release.
To create Payment Cards that can be shared to other users, click on Create New > Record > then select the Payment Card type.
Each user can set sorting of the record types which appear when creating new records. Visit Settings > Record Type Sorting > Edit Order.
Keeper Business and Enterprise customers can define totally custom Record Types for their specific needs.
In order to create new custom Record Types, the user must be in an Administrative role with the "Manage Record Types in Vault" permission activated as seen below in the Admin Console role permission interface.
To activate this permission, visit Roles > Select Role > Hover over gear icon > Administrative Permissions.
Once the permission is activated, the Admin can login to the Web Vault or Desktop App to create a record type.
From the Keeper Vault application, select Create New > Custom Record Type:
You can create the new template based on an existing template, or you can start with a blank record and add the required fields:
Within the new Record Type screen, you are able to define what fields will exist within this template. You are able to add, remove and re-order any field types you wish to. Add new fields by clicking the Add New Field button.
Available Fields
Login
Password
URL (website address) used for Autofill
Two-Factor (TOTP) code with seed
File attachment
Security Question & Answer
Single-line Text
Multi-line Text
Hidden Field
Hostname or IP Address
Date
Payment Card
Bank Account
PIN Code (4-digit numeric)
Name
Email Address
Address
Phone Number
Native App Filler (see KeeperFill for Apps)
As an example, here's a custom record type that may represent a "Crypto Wallet" type:
One of the core benefits of Custom Record Types is the ability to specify password security settings at the Type-level. You can specify the following:
Require the password field to have a value
Require the use of the "dice" button to generate the password
Set password complexity rules
Enable "Privacy Screen" on the record
Keeper's Privacy Screen feature gives you the ability to control the viewing (unmasking) of all passwords at the team level. With Privacy Screen enabled, passwords are not visible from the user interface serving as a deterrent from casual observation. This feature is commonly used to limit viewing of passwords for the non-technically savvy users. It is important to note that password masking is only visual in nature and the password is still stored in the user's vault and accessible via API communication and browser inspection.
Field Name | Description |
Title | Mandatory field, the title of the record, does not have to be unique |
Login | The standard login field, this is used to autofill records. |
Password | The standard password field, this is used to autofill records. Only one password field can be present for a particular record. If an account has multiple, use hidden fields or pin codes. |
URL | The website address of a record, if included will be used for site matching and autofill. |
Email address field, validates the string entered matches an email format. | |
Two-Factor Code | Keeper can protect and generate 2FA codes for any website or service that supports the use of TOTP (Time-Based One-Time-Passwords). |
File or Photo | File attachments can be any type of file, photo, video or other document. An unlimited number of files can be attached to any Keeper vault record. File storage is an add-on subscription. If file storage is disabled, please contact your Keeper administrator or email sales@keepersecurity.com. |
Notes | Mandatory field. Any free-form notes can be protected in this field such as access instructions or confidential documentation. |
Security Question and Answer | Typically used for account recovery, one or more security questions and answers can be stored in a record. |
Text | Free form text field, single-line. |
Multi-line text | Free form text field, multi-line. |
Hidden field | Free form text field, hidden by default. |
Pin Code | Alphanumeric code field, hidden by default. |
Date | Date field, can be manually input or selected via a date picker, validates the string entered matches a date format. |
Hostname or IP Address | Hostname or IP field used to store identification information to devices. |
Name | Multiple value custom field. It will add First Name, Middle Name, and Last Name fields to the form. |
Bank Account | Multiple value custom field. It will add Account number and Routing Number fields to the form. |
Phone Number | Multiple value custom field. It will add phone number and extension fields to the form |
Payment Card | Dynamically linked to a Payment card record. Data will be displayed within this record, but the source of truth and ability to edit reside in the original record. |
Address | Dynamically linked to an Address record. Data will be displayed within this record, but the source of truth and ability to edit reside in the original record. |
Native App Filler | Pre-defined Native Autofill capability with OCR screen recognition and auto-type of keystrokes. See the KeeperFill for Apps documentation for detailed instructions on Native App Filler. |
All fields can have a custom label associated with them and any field can be marked as a required field. Additionally, masking can be enabled on any non-password field, which will prevent the field values from being displayed by default. The visibility can be toggled via the eyeball icon.
After all needed fields have been added to the page, they can then be sorted via drag-and-drop. Click the Publish button to make it available to all users who have the record type enabled in their role policy enforcements.
To add and remove record types for your users, login to the Keeper Admin Console > Roles > Enforcement Policies and visit the Record Types screen. From here, you can turn on or off different record types on a role basis.
By default, a role can use all Record Types
If a user is part of multiple roles, disabling a record type in any role will prevent creation of those record types for the user.
If all record types are disabled, the user will be unable to create records.
If you would like to make a global change for all users, disable the Record Type in the default role.
The "General" record type is Keeper's legacy record version.
A newly created record can be converted between types, however "legacy" records created prior to the launch of Record Types cannot be converted to a Record Type.
Converting existing records to Login record type is planned for a later release.
Keeper provides several 2FA options that can be enforced at the role level.
Two-Factor Authentication (2FA) can be enforced through Keeper's Role-based Enforcement Policies and can also be configured by the end-user directly in their vault. Keeper supports popular methods of 2FA including:
SMS/Text Message
TOTP generator apps such as Google and Microsoft Authenticator
Duo Security
RSA SecurID
Keeper DNA (using Apple Watch and Android Wear devices)
FIDO2 WebAuthn physical keys such as Yubikey
Inside their vault, each user is able to individually configure their Two-Factor Authentication settings from their vault Settings screen. Upon creating a new Keeper account, the end-user is also prompted to enable 2FA.
Detailed 2FA setup steps for the various platforms can be found in the End-User Guides.
Two-Factor Authentication can be enforced by the Keeper Administrator, and this is controlled at the role level.
The Keeper Administrator can enforce the method of 2FA, how long the tokens stay valid and other related settings. Policies can be enforced at the role-level, so different policies can apply to different sets of users.
For more details instructions about enforcement policies, click here.
Certain 2FA methods such as Duo Security and RSA SecurID require the Keeper administrator to login to the Admin Console and perform up-front configuration. To access the Two-Factor Authentication configuration, navigate to the 2FA tab in the Keeper Admin Console for the selected Node. 2FA methods and token retention behavior can also be enforced from the Role Enforcement policy screen. Role enforcement policies can enforce the use of 2FA channels on the specific node. Therefore, different nodes can be provisioned with different 2FA methods.
Keeper has built a tight integration into the DUO Security API which is fully integrated into all of our device platforms. Both push and SMS methods are supported. To activate DUO Security, use take the following steps:
Login to Duo.com and create an account (or login if you already have an account).
Select Applications from the left menu.
Select Protect An Application to display a list of applications, then select Keeper Security from the list.
Copy the provided credentials from Duo's site (including the Secret Key which must be selected to view)
Return to Keeper's Admin Console and select the 2FA tab. Select the gear icon under DUO and paste the copied credentials from DUO's site. Toggle the Enable switch "on" and click Save to finish.
If you receive an error when attempting to login with Duo, you may need to check your "Username normalization" setting. The Keeper email address is used when the Keeper backend communicates with Duo's API. If your Duo environment is configured with a username instead of an email address, make sure to check the "Username normalization" setting in the Duo Console configuration page and select "Simple".
DUO has a helpful knowledge base article discussing username normalization here: https://help.duo.com/s/article/aliases-guide?language=en_US
Once activated, each individual user can enroll in DUO by logging into their Keeper app and navigating to the Settings > Security screen and enabling DUO. The user is then walked through a process to activate their device.
After activation, the user will be prompted with Duo Security on all devices.
Set-up Two-Factor Authentication method of your choice directly from your vault. Click your account email address in the upper right corner, click Security > Settings then toggle Two-Factor Authentication on. You will then be prompted to select one the 2FA methods discussed below.
Keeper supports Text Message (SMS) delivery of two-factor authentication codes. From the list of methods, toggle Text Message "on" then enter your phone number.
From the list of methods, toggle Google and Microsoft Authenticator (TOTP) "on". Download the Google Authenticator, Microsoft Authenticator or any TOTP-compatible application on your mobile device and add a new entry by scanning the QR Code 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 the Smartwatch (KeeperDNA) method, from your mobile device, tap Settings > Two-Factor Authentication and chose Smartwatch (KeeperDNA) as your method.
Keeper's certified backend integration with RSA SecurID can be configured by Keeper's engineering team for your account. To enable RSA SecurID, additional customer integration points are necessary. Please contact your Keeper account manager to initiate this integration at business.support@keepersecurity.com.
Users can protect their Keeper vault with FIDO WebAuthn compatible hardware security keys, including YubiKey and Google Titan keys, which provide secure and easy two-factor authentication (2FA).
Security Keys are configured in the Keeper Web Vault or Keeper Desktop App. To activate 2FA using Security Keys, follow the steps below:
Click your account email address in the upper right corner of your vault, then click Settings > Security
Enable 2FA and click Edit Two Factor to activate a standard 2FA method. This will be used as a backup method when your Security Key is not supported or not available. Google Auth or TOTP should be used a backup method rather than SMS, otherwise you will receive an SMS code every time you login with the Security Key. Keeper recommends using a TOTP (Google Authenticator or equivalent) generator for two-factor authentication to eliminate the possibility of SIM takeover attacks.
From the previous Security menu, click Setup next to Security Keys.
Follow the on-screen prompts, provide a name for your Security Key and select Register.
If your Security Key has a button or gold disc (e.g. Yubico), press the button to register.
Keeper's authentication system as described in the Keeper Encryption Model requires device verification and 2FA verification prior to Master Password authentication.
When using Security Keys and logging into the Browser Extension, the flow is slightly different from a user perspective but the security level is the same. Users on the Browser Extension login flow are prompted for the Master Password, but this information is not processed until the device verification and 2FA step has been performed. This workflow is due to the fact that Browser Extensions do not currently support native Security Keys.
Currently, Keeper requires that users have a backup 2FA method using either TOTP, SMS, Duo, RSA or Keeper DNA. The Backup 2FA method is utilized on devices that do not support hardware security keys, or if you do not have access to your key.
For customers who do not wish to have a backup 2FA method, we recommend using the TOTP method and discarding the seed after setup. Please note that authentication with some devices will be impaired without a backup 2FA method. Also, note that if you lose all your registered Security Keys, you will need to contact your Keeper Administrator or Keeper Support teams to assist in changing 2FA methods.
Admins have the ability to disable 2FA for any of their users.
Keeper provides encrypted 2FA code storage for websites and applications.
Keeper has developed a fully-integrated security layer that adds two-factor codes directly in vault records. A Keeper user simply adds the two-factor code into the vault record field and then it will automatically be filled when logging in via the Web Vault or Browser Extension. The Keeper vault is also capable of storing and managing TOTP / 2FA codes for 3rd party applications.
Keeper two-factor codes are more secure than using SMS text messages.
Two-factor codes stored in Keeper are protected with strong Zero-Knowledge encryption.
They can be auto-filled quickly while logging in to a site, saving time and reducing friction.
Keeper records are securely backed up so if you lose a device you don’t have to reset all the codes.
Keeper records are shareable. If you have multiple people that need to log in with the same credentials, they won’t need to track down the person who has the only device containing the code.
See the Video Demo below of Two-Factor Codes Integration:
Two-Factor codes can be filled directly with the Keeper Browser Extension.
Alternatively, Two-Factor codes can be filled in any login screen using the Right Click menu.
To add a Two-Factor Code, you can use the Web Vault, Desktop App or mobile apps.
From the Desktop App, click on "Add Two-Factor Code". There are 3 ways to input the code:
Scan (Desktop App Only)
Upload a QR code image (.jpg, .png, etc)
Manual Entry (advanced)
The "Scan" feature on the Keeper Desktop application lets you drag a small scanner window on top of the target QR code. This is useful when setting up applications on the desktop computer.
It's also very easy and straightforward to use the Keeper mobile app on iOS or Android to add a Two-Factor code. Tap on "Add Two-Factor Code" from the record edit screen and use the device camera.
Password security strength reporting in the Admin Console
In each end-user's vault, the Security Audit screen provides information about the password strength and password reuse taking place. The calculation of password strength and reuse is performed continuously from the user's Vault on all platforms including Keeper Desktop, Web Vault, iOS and Android devices.
Keeper's Password 'strength' is a calculated score based on the complexity of the password, with a score rating between 0 and 100 according to the below metrics:
Weak: < 40 Fair: 40-59 Medium: 60-79 Strong: >= 80
To preserve Zero Knowledge, the summary of each end-user Security Audit score is encrypted with the Enterprise Public Key, then stored encrypted in the Keeper Cloud.
When the Admin logs into the Admin Console, the Audit Data is decrypted locally on the Admin Console device and made available for administrators in an aggregated format from the Security Audit screen.
The Security Audit screen provides summary and user-level security score information that includes:
Overall Security Score
Record Password Strength
Unique Record Passwords
Use of Two-Factor Authentication
For more information on how these scores are calculated, visit the following:
Security Audit Score CalculationThe Security Audit screen contains a table that displays the record password strength, unique record password count, and 2FA status for all users across the enterprise.
The table is sorted by default on the users’ overall Security Audit score, showing users with the lowest Security Audit score first. You can reverse this sort order or sort instead on the user's name, password strength, resued passwords, or two-factor method.
Additionally, you can filter the table on the following fields:
Record Password Strength: Strong, Medium, Fair, or Weak
Unique Record Password: Resued or Unique
2FA: Text Message, Authenticator App (TOTP), Smartwatch (KeeperDNA), Security Keys, RSA SecurID, Duo Security, or No 2FA
Administrators can refresh the security scores on the UI without having to log out of the Console and log back in. The ability to refresh scores is useful when the admin is expecting users to log into their Vaults to have their latest security scores sync with the Console. When the user has logged into their Vault, the admin needs to simply click the Refresh Scores button to sync the latest scores to the Console.
Administrators can reset security scores from the UI if the scores have gotten out-of-sync with user Vaults. The administrator can either reset scores for the entire enterprise using the Reset Scores button on the Security Audit screen or for specific users. Please note that only Root Admins can reset the Security Audit score.
The Reset Scores button on the Security Audit screen will reset scores for the entire enterprise. Once the scores are reset, users will need to log in to their Vaults for the scores to sync to the Admin Console due to the constraints of Keeper’s Zero Knowledge architecture.
Alternatively, the administrator can navigate to the User Details modal and select Reset Security Score under User Actions to reset individual users' Security Audit scores. As is the case with performing an enterprise-wise score reset, once the scores are reset, the user will need to log in to their Vault for the scores to sync to the Admin Console due to the constraints of Keeper’s Zero Knowledge architecture.
In addition to Security Score, Keeper also provides a Dark Web scan summary of end-user passwords through the BreachWatch secure add-on.
BreachWatch alerts can be configured in the Advanced Reporting & Alerts module to alert users and Administrators when a password has been found on the dark web.
The Keeper Commander CLI provides direct access to the audit data and event data, with other advanced capabilities. For more information, see the Keeper Commander reference guide and reporting commands.
Information on how the security scoring is calculated in the Admin Console
This document will cover how the following Security Audit Scores are calculated:
The Record Password Strength score represents the percentage of record passwords, across all record passwords for all users, that are strong, medium, or weak. This score is calculated by adding all user's individual Record Password Strength, and then dividing it by the total number of records.
For each user, the Record Password Strength is calculated by the taking the number of strong, medium, or weak passwords and dividing it by the total number of records.
For example, if a user's vault has 10 total records where:
6 of the records have a strong password
3 of the records have a medium password
1 of the record has a weak password
The Record Password Strength score for this user will be as follows:
Strong passwords: 6/10 = 0.6 = 60%
Medium passwords: 3/10 = 0.3 = 30%
Weak passwords: 1/10 = 0.1 = 10%
The Unique Record Passwords score represents the percentage of record passwords, across all record passwords for all users, that are Unique or Reused. This score is calculated by adding all user's individual unique password score, and then dividing it by the total number of records.
For each user, the Unique Passwords Record Score is calculated by taking the number of unique passwords in the user's vault and dividing it by the total number of records.
For example, if a user's vault has 10 total records where:
6 of the records have a unique password
2 of the records share the same password
2 of the records share the same password
There are 6 unique passwords, 1 unique password that is shared between 2 records, and another unique password that is shared between 2 records. Thus, there are a total of 8 unique passwords. The Unique Passwords Record Score for this user will be as follows:
Unique passwords: 8/10 = 0.8 = 80%
Reused passwords: 2/10 = 0.2 = 20%
The Two-Factor Authentication score represents the percentage of users that have enabled Two-Factor Authentication. This score is calculated by adding all the Two-Factor Authentication scores of all users and then dividing it by the number of total users.
For each user, the Two-Factor Authentication score will be one of the following values depending on whether the user has Two-Factor Authentication On or Off:
0% if Two-Factor Authentication is Off
100% if Two-Factor Authentication is On
The Master Password Strength is not displayed on neither the Vault Clients nor Admin Console. Instead, the Master Password Strength is displayed upon Account Creation:
For each user, the Master Password will be 100% if the Master Password's strength is Strong, and 0% otherwise.
For the overall Security Audit Score calculation, the average Master Password across all users is used.
The Security Audit Score represents the Overall Average Security Score across all your users in your organization.
For each user, the Average Security Score is calculated by taking the average of the user's score from the following categories:
Security Score Category | Values used to Calculate Average Security Score |
---|---|
The Strong password % is used | |
The Unique password % is used | |
If Two-Factor Authentication is On, 100% is used, if Off 0% is used | |
If Master Password strength is strong, 100% is used, otherwise 0% used. |
User's Average Security Score is calculated as follows:
User's Average Security Score = (% of Strong Password Strength + % of Unique Password + Two-Factor Authentication + Master Password Strength)/4
For example, if a user has the following scores:
Strong Password Strength = 60%
Unique Record Passwords = 80%
Two Factor Authentication is Off = 0%
Master Password Strength = 100%
The Average Security Score for the above user would be the sum of all the category scores divided by 4:
Since the following variables affect the Security Audit Score:
Record Password Strength
Unique Record Passwords
Master Password Strength
Two-Factor Authentication
if the user has 0 records, this disqualifies the Record Password Strength and Unique Record Passwords variables, but the calculation of the Security Audit Score still takes the Master Password Strength and Two-Factor Authentication into consideration.
Across the various Keeper Vault Clients, user's Security Scores are independently calculated which may rarely cause the overall Security Audit Scores to be negative. If the Keeper Admin Console displays negative scores, visit the following page to correct this issue.
Zero Knowledge dark web breach scanning for Keeper Enterprise
BreachWatch provides organizations oversight of the vulnerabilities of user's passwords through active monitoring of dark web breach data. Users and administrators are notified if any of their passwords in a record have been used in publicly known breach that could leave your organization vulnerable to a credential stuffing attack or an account takeover.
Watch the video below to learn more about dark web monitoring with BreachWatch
BreachWatch will prompt the user on their client device to Resolve the breached password by either changing the password or ignoring it. If a password alert is ignored, then that record will be skipped on future scans until the password is reset. The user may also do nothing (deferring a response) and leave the risky password unchanged and thus still "at risk".
BreachWatch provides Admins a dashboard overview and a summary table in the Admin Console detailing how users have dealt with their BreachWatch notifications.
If users have "At Risk" or "Ignored" passwords, the Keeper Administrator can click on a user's name to bring up the 'User Detail' to gain access to their email address so they can request the user to take action.
The user-specific BreachWatch data does not include shared records, only the records the user owns. Additionally, if a record does not contain a password, it will not be shown in the count.
If the Advanced Reporting & Alerts module is activated on the Enterprise license, then BreachWatch specific events can be sent from the devices/clients and used to report activity with a variety of filters, and/or generate an alert.
IMPORTANT: To activate event-level reporting of BreachWatch data to the Advanced Reporting & Alerts Module you must enable the event role enforcement policy under the specific role > Enforcement Policies > Vault Features screen.
By default, Keeper does not send BreachWatch event data from the user's device to connected SIEM and Advanced Reporting & Alerts reporting tools. The Keeper Admin must explicitly enable this feature. After it's enabled, the event data will begin to flow through to the Advanced Reporting engine and connected SIEM systems such as Splunk.
Note that this is not retroactive. Events will only flow through Advanced Reporting & Alerts after this feature is activated.
After BreachWatch events are flowing into the reporting module, visit the "Reporting & Alerts" screen to generate a report.
Click on Add Custom Report then select the BreachWatch events.
Alerts can also be created with custom event tracking.
Webhooks can receive alerts, so that you can perform any custom logic such as Slack channel alerts, Microsoft Teams, etc.
To enable webhook alerts:
Click on the event name.
Click the Recipients tab.
Add or click on an existing Recipient.
Click the Add Webhook button.
Configure the URL, HTTP Body, and an optional token.
Click Save.
Events can also be streamed to 3rd party SIEM solutions.
The BreachWatch capability can be deployed selectively to your organization via Role Enforcements. The Pause BreachWatch on client devices toggle controls whether devices send events for reporting purposes, and whether to pause the service so it will not appear on the user's devices at all. Note that enabling events to the reporting module will send record event metadata (User Email, Record UID, IP Address and Device Type) from Keeper’s backend to any connected SIEM product.
If you do not want to deploy BreachWatch to your entire organization at once, you can control the deployment using the Pause BreachWatch on client devices toggle. Users in this node will not have BreachWatch enabled on their client devices.
BreachWatch is a Zero Knowledge architecture that uses a number of layered techniques to protect our customer’s information. For detailed technical information regarding the security and encryption model of BreachWatch, please visit the BreachWatch section on the Keeper Encryption Model documentation by clicking This Link.
BreachWatch can be managed and used through the Keeper Commander CLI. See the below related commands:
Secure File Storage and sharing capabilities for Enterprise and public sector
Keeper offers Secure File Storage to protect your confidential files, IT documentation, photos, videos and any other type of documents.
File attachments are end-to-end encrypted. The encryption is performed locally on the user's device before being uploaded to the Keeper Cloud Security Vault. The user is in complete control of the encryption keys to access and decrypt the files for complete privacy and security. Users also have the ability to securely share files with other Keeper users via shared folders, individual record sharing and one-time share. Sharing records uses Elliptic Curve encryption, making Secure File Storage the best way to save, transfer and share the most sensitive documents.
Role-based enforcement policies can be applied by the Keeper Administrator to restrict file attachments and sharing records with files.
Keeper Secure File Storage solution can be added on to any Enterprise or public sector subscription. There are several critical use cases:
Storing and sharing of confidential PDF, Excel, Word or other doc types
Protection of SSH Keys, SSL certificates and other private keys
Safe backups of ID cards such as passports and drivers licenses
Encrypted storage of private financial information
Sharing confidential IT documentation among engineers
Simply drag-and-drop files into the Web Vault or Desktop App. Or on iOS/Android devices, you can load content from the local device. Files are then encrypted locally on the device and the ciphertext is stored in the Keeper Cloud Security Vault.
The Secure File Storage feature is a secure and convenient method of storing your SSH keys, SSL keys and other cloud infrastructure access keys.
ID cards such as passports and drivers licenses can be easily stored and retrieved on any device with full encryption.
Confidential financial documents or any other private file can be stored in the vault.
Files can be securely shared either directly to other Keeper users, or within a Shared Folder.
Sharing can be disabled by Keeper Administrators from the Keeper Admin Console. Sharing features are controlled as role-based enforcement policies.
If allowed by role policies, users can also create a one-time share. One-time share links are useful for sharing a file with an outside vendor, contractor or 3rd party. In this case it's set to be revoked after 1 hour. One-time shares can be opened with a QR code or a link sent through email or a messaging platform.
On the recipient side, the one-time share is cryptographically bound to the receiving device.
For more information about one-time shares, see this page.
A record can be saved as a self-destructing one-time share. In this scenario, the record is going to be deleted from both sides after the file has been downloaded. When creating a record, select "Add Self Destruct".
Learn more about self-destructing records at this page.
Files can be attached and viewed from the Keeper iOS and Android applications. Files can be stored offline for fast access if an Internet connection is not available.
All file related actions such as uploading a file, downloading a file or sharing a record is tracked and monitored through Keeper's advanced reporting and alerts module. This provides event-based reporting that contains information such as: the user's IP address, location, software version, the record identifier, file identifier and other metadata.
You can run reports right here in the console, or if you are using a 3rd party SIEM solution like Splunk, these event logs can be streamed directly into your SIEM provider's collector endpoint in real time.
Secure File Storage is pooled among the organization's users. To add storage to your Business or Enterprise plan, from the Admin Console, click on Subscriptions then Add Storage.
At the checkout screen, you will have the opportunity to select the file storage level.
Keeper Administrators can configure Secure File Storage capabilities at the role level. To disable sharing or file upload capabilities navigate to Roles > Enforcement Policies > Creating and Sharing.
For automation and migration of files into Keeper, the Keeper Commander CLI is useful for IT admins or developers to either bulk add content or build automated actions into workflows.
For example, to add a file attachment to a record, the command upload-attachment is executed:
For more information about Keeper Commander record related commands, see the page below:
https://docs.keeper.io/en/v/secrets-manager/commander-cli/command-reference/record-commands
Just like our password encryption technology, Keeper protects your confidential files with 256-bit AES encryption using record-level keys.
Sharing files between users takes advantage of Keeper's built-in Elliptic Curve cryptography method. The record key or folder key which protects the individual record is encrypted with the public key of the recipient(s).
Secure file storage is available across all of your devices including iOS, Android, Web Vault, and Desktop App.
Files can be easily and securely shared with other Keeper users, from vault-to-vault.
Like your other Keeper records, you can set sharing permissions for records that contain your secure files (can edit, can share, can edit & share, and read only).
Individual file sizes are supported up to 5GB for Desktop App, 100GB for iOS, 100GB Android, 100MB for Web Vault.
Keeper's Advanced Reporting and Alerts Module (ARAM) provides advanced event logging to meet compliance requirements.
Keeper's Advanced Reporting & Alerts Module ("ARAM") is a critical component of the Keeper Security platform which provides Keeper Administrators and Compliance teams tools for monitoring overall usage and adherence to policies.
Reporting Engine Run custom time-based reports with 100+ different event types that are broken down by category (e.g. Security Events, Administrative Actions, General Usage, etc). Filter on User, Event Type, Attribute (e.g. Record UID, Shared Folder UID, Geolocation).
Alerts Set alert triggers which can send email, SMS or Webhook notifications based on specific event types (For example, notify Admins upon any policy changes).
External Logging Integrate with any existing SIEM solution such as Splunk, Sumo or LogRhythm.
BreachWatch monitoring Get notified and track BreachWatch events (user notified of high risk password, resolved high risk password).
Commander CLI / SDK Integration Keeper Commander can perform customized reporting and automation.
Compliance Auditing Generate reports specifically to address SOX, ISO, SOC compliance auditing requirements.
The Reporting & Alerts dashboard provides an overview of the top 5 events, two built-in reports and your custom reports. The "Recent Activity" report is a built-in report that provides basic event tracking for the last 1,000 events across 16 event types. Customers can upgrade to the Advanced Reporting and Alerts module to track over 100 event types and generate custom reports and alert notifications.
The "Recent Activity" and "All Security Events" reports are provided in all Keeper Business and Enterprise subscriptions. Custom reporting and alerts is a feature of the Advanced Reporting and Alerts Module (ARAM). To take advantage of this capability, please contact your Keeper Security account manager or upgrade your subscription through the Secure Add Ons interface of the Admin Console.
Additionally, a user status report is available via the dashboard. See the Dashboard section in this guide.
Admins can also create custom reports by clicking Add Custom Report.
Preview the results by clicking Apply, and if you want to use the report in the future, click the Save button. You can export the events as a file in JSON, CSV or SysLog formats.
New events generated by Keeper vault devices can take up to 15 minutes to appear in the reporting module.
Accuracy of geolocation based on IP address varies depending on the database used to identify the user's location. The precision of geolocation data depends on several factors. Most importantly is how well registries validate the data they receive. If information connected with an IP address is incorrect, it reduces its usefulness. Geolocation is incredibly challenging in the case of mobile phone usage where IP address changes are frequently and mobile carriers use centralized gateways that users reach the internet. Additionally, if users are using proxies or VPN's the location data will invariably be incorrect.
Keeper subscribes to one of the industries most reliable providers who performs quality assurance by validating data quality against known IP addresses sourced from the public on a regular basis.
The Timeline Chart provides a chart of events over a 24-hour, 7-day and 30-day period. Clicking on any event row will open a report containing all events from the time period.
The Alert module allows you to create event-based triggers that will generate either email or SMS-based alerts.
New alerts are created similarly to new reports, by clicking Add Alert and specifying a name and a filter criteria. You can add one or more recipients using email address, phone number (for SMS) or both. Recipients don't have to be a part of your enterprise and any email address or phone number can be provided. The first recipient is predefined to be the user who generated the event. This will be "off" by default, and you will need to toggle it "on" to enable sending the alerts (email only) to the originator.
Specifying a broad event and attribute filter could generate a lot of alerts. Adjust alert frequency and set narrow event types and filters to reduce alert noise.
To prevent the recipients from receiving too many emails or SMS, alerts can be throttled. One way to throttle is to specify Alert Frequency. For example, if you set the frequency to "Once Per Time Period" with a period of 1 hour than all events matching the alert filter will still trigger the alert "occurrence" but the message will be sent only if 1 hour has passed since the time of the previous message. Another way to throttle the alert is to pause it using the toggle switch. Paused alert will also accumulate "occurrences" without sending the actual messages. When resumed, the very next event matching the alert will trigger sending the message which will contain the number of events that happened while being on pause.
Below is an example of an email alert:
You can view the alert history in the Alerts Sent tab, with the ability to drill down to see the individual events:
If you are utilizing a 3rd party SIEM solution, the Keeper Admin Console can be configured to automatically feed live event data into external SIEM products. Currently supported systems include:
Event data is transmitted from Keeper's servers to the destination SIEM collector. Only one method of the external sync can be active at a time.
Click Setup to activate the external logging solution. Setup is easy on each logging platform and typically only requires a few attributes to integrate.
Within the Admin Console, the default "Recent Activity" report contains 16 event types. Keeper's Advanced Reporting and Alert module supports ~ 100 event types.
The events captured by Keeper Enterprise are visible in the drop-down menus for report and alert configuration.
By default, BreachWatch events from the end-user devices are not collected and transmitted to the Advanced Reporting & Alerts module. These events are managed by the Role policy. To activate this feature, visit the Role > Enforcement Policies > Vault Features and toggle Send BreachWatch events to Reporting & Alerts and connected external logging systems "on".
A list of all available events captured by the Keeper Advanced Reporting and Alert Module are provided in the chart below. The Event Code is utilized in the user interface and within the Keeper Commander CLI command parameters. The "Message" field is utilized for the Alerting module.
Within each event, there may be additional attributes such as Record UID, Shared Folder UID, Team UID, Username, etc. These attributes will appear within the event description and they are also provided to the 3rd party SIEM provider in the format as specified by the destination.
Below are examples of 2 events in JSON format that are sent. Note that Record UID is provided with the "record_update" event since it relates to a specific record.
Below is an example of a Syslog-format event that can be exported via Keeper Commander or into the 3rd party SIEM solution:
Note that "enterprise_id" is useful for distinguishing different Keeper Enterprise tenants within the same SIEM collector.
The event data references several types of UID values such as Record UID, Shared Folder UID and Team UID. The Record UID and Shared Folder UID can be found either through the Keeper Commander CLI or through the Web Vault user interface.
The Keeper Commander CLI provides command-line and SDK integration into Keeper's reporting system for more advanced use cases. The event data can be used for generating actionable reports.
Please see the following reporting related commands for more information:
Details on what triggers each event
A list of all available events captured by the Keeper Advanced Reporting and Alert Module are provided in the chart below. The Event Code is utilized in the user interface and within the Keeper Commander CLI command parameters. The "Message" field is utilized for the Alerting module.
Within each event, there may be additional attributes such as Record UID, Shared Folder UID, Team UID, Username, etc. These attributes will appear within the event description and they are also provided to the 3rd party SIEM provider in the format as specified by the destination.
Integrating Keeper SIEM push to Splunk Enterprise
Keeper supports event streaming into Splunk Cloud and Splunk Enterprise deployments. External logging is real-time, and new events will appear almost immediately.
An example configuration is displayed below. Note that Host field should only contain the domain portion of the collector URL.
Keeper supports the HTTP Event Collector (HEC) feature of Splunk Cloud deployments.
The standard form for the HEC URL in self-service Splunk Cloud is as follows:
In Keeper, you only need to supply the domain portion of the URL. For example:
Host: input-prd-p-2dm85a8f6db.cloud.splunk.com Port: 8088 Token: HEC token generated in Splunk
Keeper supports the HTTP Event Collector (HEC) feature of Splunk Managed Cloud deployments. The standard form for the HEC URL in managed Splunk Cloud is as follows:
In Keeper, you only need to supply the domain portion of the URL. For example:
Host: http-inputs-prd-p-2dm85a8f6db.splunkcloud.com Port: 443 Token: HEC token generated in Splunk
Ensure that your endpoint has the "Indexer Acknowledgement" feature disabled.
Keeper supports the HTTP Event Collector (HEC) feature of Splunk Enterprise and Splunk Cloud deployments. To configure Keeper with Splunk, a few things to note:
Instructions on creating a HEC for Keeper can be found on Splunk's documentation here: https://docs.splunk.com/Documentation/Splunk/8.1.1/Data/UsetheHTTPEventCollector
Keeper requires that the collector endpoint uses SSL with a valid certificate signed by a certificate authority. If the collector is not using SSL, Keeper will reject the connection.
The collector endpoint URI needs to be accessible from Keeper's servers. See the AllowList section below for a list of IP addresses.
(1) On the Spunk interface, create a new HEC or select an existing collector.
(2) Generate a token and store it for Step 4.
(3) In the Global Settings, ensure that "Enable SSL" is selected and ensure that the collector is configured to use SSL.
(4) On Keeper, plug in the endpoint Host, Port and Token from the HEC. In Keeper, you only need to supply the domain portion of the URL.
(5) Click on "Test Connection" to ensure that the connection is successful. If it's successful, the "Save" button will become active. If there is a communications error, nothing will happen or you will receive an error message.
(6) Click "Save" to activate the collector. Keeper will then show the active status.
If the status shows "Paused", it could mean that there was a communications error when transmitting events to the Splunk server. A common reason for this is because the HEC is not using SSL with a valid certificate signed by a certificate authority (CA).
As stated above, the HEC in Splunk Enterprise must be secured with SSL having a certificate that is signed by a certificate authority. As a way to check this from a Mac or Linux command line, type the following (replacing your endpoint URI and Token):
If you receive an error about the SSL certificate like below, then it's not configured correctly.
If you add a "-k" to the curl request to ignore the certificate, you may receive a successful response. This is a good indicator that the HEC certificate is not valid.
To configure Splunk Enterprise for SSL on the collector, refer to the documentation. The local/server.conf file should be modified to include the [sslConfig] section that enables SSL on the splunkd service with a bundled certificate file chain.
The certificate file chain (my_bundle.pem) can be created by concatenating the certificate, private key and CA certs such as below:
For additional details, see the Splunk Enterprise documentation related to securing Splunk with SSL: https://docs.splunk.com/Documentation/Splunk/8.1.1/Security/AboutsecuringyourSplunkconfigurationwithSSL https://docs.splunk.com/Documentation/Splunk/8.1.0/Security/Securingyourdeploymentserverandclients
Once activated, the event logs will stream automatically from Keeper's backend servers to the Splunk HEC. As seen in the screenshot below, the event logs will contain the event type, client application version, IP address, timestamp and username of the Keeper user.
Ensure that your Firewall allows traffic from Keeper servers. See Firewall Configuration page.
Integrating Keeper SIEM push to Sumo Logic
Keeper supports event streaming into Sumo Logic deployments. External logging is real-time, and new events will appear almost immediately. Setup instructions are below.
The Sumo Logic integration requires a single sync URL.
To configure an HTTP Logs and Metrics Source:
In Sumo Logic, select Manage Data > Collection > Collection.
In the Collectors page, click Add Source next to a Hosted** **Collector.
Select HTTP Logs & Metrics.
Enter a Name to display for the Source in the Sumo web application. Description is optional.
(Optional) For Source Host and Source Category, enter any string to tag the output collected from the source. (Category metadata is stored in a searchable field called _sourceCategory.)
SIEM Processing. This option is present if Cloud SIEM Enterprise (CSE) is enabled. Click the checkbox to to send the logs collected by the source to CSE.
Fields. Click the +Add Field link to define the fields you want to associate, each field needs a name (key) and value.
A green circle with a check mark is shown when the field exists in the Fields table schema.
An orange triangle with an exclamation point is shown when the field doesn't exist in the Fields table schema. In this case, an option to automatically add the nonexistent fields to the Fields table schema is provided. If a field is sent to Sumo that does not exist in the Fields schema it is ignored, known as dropped.
When the URL associated with the source is displayed, copy the URL so you can use it to upload data.
When you are finished configuring the Source, click Save.
Processing Rules. Configure any desired filters, such as allowlist, denylist, hash, or mask, as described in Create a Processing Rule. Processing rules are applied to log data, but not to metric data.
Integrating Keeper SIEM push to LogRhythm
Keeper supports event streaming into LogRhythm deployments. External logging is real-time, and new events will appear almost immediately. Setup instructions are below.
LogRhythm uses a standard "Syslog" push capability over TCP.
Ports TCP Ports 514 and 6514 (TLS)
Fields Exported "audit_event", "username", "client_version", "remote_address", "channel", "result_code", "email", "to_username", "client_version_new","username_new", "file_format", "record_uid", "folder_uid", "folder_type", "shared_folder_uid", "attachment_id", "team_uid", "role_id"
Payload Format Pipe-delimited, e.g. "audit_event=login|username=bob@foo.com|..."
Important: Ensure that the endpoint is using a valid signed SSL certificate that has a domain matching the subject name in the certificate. The certificate must also include the full certificate chain from your CA. Keeper's systems will refuse to connect to a self-signed certificate. Also, ensure that your LogRythm server allows traffic from Keeper servers. See Firewall Configuration page.
Integrating Keeper SIEM push to standard Syslog endpoints
Keeper supports event streaming into standard TCP Syslog collectors. External logging is real-time, and new events will appear almost immediately. Setup instructions are below.
Keeper supports a standard "Syslog" push capability over TCP.
Ports TCP Ports 514 and 6514 (TLS)
Fields Exported "audit_event", "username", "client_version", "remote_address", "channel", "result_code", "email", "to_username", "client_version_new","username_new", "file_format", "record_uid", "folder_uid", "folder_type", "shared_folder_uid", "attachment_id", "team_uid", "role_id"
Example Payload
Important: Ensure that the endpoint is using a valid signed SSL certificate that has a domain matching the subject name in the certificate. The certificate must also include the full certificate chain from your CA. Keeper's systems will refuse to connect to a self-signed certificate.
Also, ensure that your syslog server allows traffic from Keeper servers. See Firewall Configuration page.
Integrating Keeper SIEM event pushes to IBM QRadar
Keeper supports event streaming into IBM QRadar deployments. External logging is real-time, and new events will appear almost immediately. Setup instructions are below.
QRadar uses a standard "Syslog" push capability over TCP.
Ports TCP Ports 514 and 6514 (TLS)
Fields Exported "audit_event", "username", "client_version", "remote_address", "channel", "result_code", "email", "to_username", "client_version_new","username_new", "file_format", "record_uid", "folder_uid", "folder_type", "shared_folder_uid", "attachment_id", "team_uid", "role_id"
Example Payload
Important: Ensure that the endpoint is using a valid signed SSL certificate that has a domain matching the subject name in the certificate. The certificate must also include the full certificate chain from your CA. Keeper's systems will refuse to connect to a self-signed certificate. Also, ensure that your QRadar server allows traffic from Keeper servers. See Firewall Configuration page.
Integrating Keeper SIEM event pushes to Azure Sentinel and Log Analytics
Keeper supports event streaming into Azure Sentinel / Log Analytics environments. External logging is real-time, and new events will appear almost immediately. Setup instructions are below.
In Azure, go to Log Analytics workspaces > Select Workspace and then "Agents Management". From here you can retrieve a Workspace ID and Key. Provide these two fields to Keeper to start streaming logs to your selected workspace.
Integrating Keeper SIEM push to an Amazon S3 bucket endpoint
Keeper supports event streaming into an Amazon S3 bucket. Setup instructions are below.
(1) In AWS, create an S3 bucket and of course ensure that all permissions are locked down.
(2) Create a user account without console access and assign a basic role policy which can only put files within the bucket. Example below.
(3) Generate Access Key and Secret Key, provide those to the Admin Console user interface along with the Bucket Name. You can select different time intervals for the file uploads. You can also select the file format which includes:
JSON
Syslog
CSV
For the Bucket Name, provide a full ARN that includes the region. For example:
arn:aws:s3:us-west-2::my-keeper-events
Files will be posted only when events occur during the interval. In the example below, the json files are posted every hour when there is activity in the system.
If you set the time frame to a "day", all events will accumulate until the day has ended (using UTC clock) and then a new file containing all day events will be added to your S3 bucket.
Integrating Keeper SIEM push to Devo
Keeper supports event streaming into Devo deployments. External logging is real-time, and new events will appear almost immediately. Setup instructions are below.
Devo uses a standard "Syslog" push capability over TCP.
Ports TCP Ports 514 and 6514 (TLS)
Fields Exported "audit_event", "username", "client_version", "remote_address", "channel", "result_code", "email", "to_username", "client_version_new","username_new", "file_format", "record_uid", "folder_uid", "folder_type", "shared_folder_uid", "attachment_id", "team_uid", "role_id"
Payload Format Pipe-delimited, e.g. "audit_event=login|username=bob@foo.com|..."
Important: Ensure that the endpoint is using a valid signed SSL certificate. Keeper's systems will refuse to connect to an invalid or self-signed endpoint. Also, ensure that your Devo server allows traffic from Keeper servers. See Firewall Configuration page.
Integrating Keeper SIEM push to Datadog
Keeper supports event streaming into Datadog deployments. External logging is real-time, and new events will appear almost immediately. Setup instructions are below.
The Datadog integration requires two fields:
URL (For example: datadoghq.com or datadoghq.eu)
API Key
To retrieve an API Key, please follow the below instructions
In the Datadog interface, go to Organization Settings > API Keys
Create a new API key
Ensure that your API Key matches up with the destination server where your Datadog environment is hosted.
Integrating Keeper SIEM push to Logz.io
Keeper supports event streaming into Logz.io deployments. External logging is real-time, and new events will appear almost immediately. Setup instructions are below.
Logz.io uses their HTTPS listener method.
The connection to Logz.io requires two fields:
Host (e.g. mycompany.logz.io)
Token
Please refer to your Logz.io documentation for generating a security token.
Important: Ensure that the endpoint is using a valid signed SSL certificate that has a domain matching the subject name in the certificate. The certificate must also include the full certificate chain from your CA. Keeper's systems will refuse to connect to a self-signed certificate. Also, ensure that your Logz.io server allows traffic from Keeper servers. See Firewall Configuration page.
Integrating Keeper SIEM push to Elastic
Keeper supports event streaming into Elastic deployments. External logging is real-time, and new events will appear almost immediately. Setup instructions are below.
Elastic integration uses a TCP push to the destination endpoint. The fields required are:
Host (e.g. mycompany.gcp.cloud.us.io:9243)
Search Index (e.g. keeper)
API Key
Please refer to the Elastic documentation for generating an API key:
https://www.elastic.co/guide/en/elasticsearch/reference/current/security-api-get-api-key.html
Important: Ensure that the endpoint is using a valid signed SSL certificate that has a domain matching the subject name in the certificate. The certificate must also include the full certificate chain from your CA. Keeper's systems will refuse to connect to a self-signed certificate. Also, ensure that your Elastic server allows traffic from Keeper servers. See Firewall Configuration page.
If Keeper is unable to connect to your Elastic instance, please check the following:
In the host field, do not type http or https
Make sure to include the port
If you are using a "Space", add the space name to the end of the Host field after the port. For example: example-elastic01.us-east.found.io:9243/s/spacename
Make sure any firewall in front of Elastic is configured per this page
Ingress Requirements for direct SIEM push
Event logs configured through the Keeper Admin Console are pushed from Keeper's backend logging system through a static set of IP addresses. For added security, you can lock down your SIEM HTTP collector to the specific IP/ports listed below.
For customers who are receiving inbound requests from the Keeper production environment, use the below IP addresses. This applies to SIEM event reporting and SSO Cloud Automator.
34.194.242.137/32
18.235.39.229/32
54.208.20.102/32 (Connection verification only)
34.203.159.189/32 (Connection verification only)
54.246.149.209/32
34.250.37.43/32
52.210.163.45/32 (Connection verification only)
54.246.185.95/32 (Connection verification only)
54.206.253.126/32
52.64.85.78/32
3.106.40.41/32 (Connection verification only)
54.206.208.132/32 (Connection verification only)
18.253.101.55/32
18.253.102.58/32
18.252.135.74/32 (Connection verification only)
18.253.212.59/32 (Connection verification only)
CA / Canada Hosted Customers
35.182.155.224/32
35.182.216.11/32 (Connection verification only)
15.223.136.134/32 (Connection verification only)
JP / Tokyo Hosted Customers
35.74.131.237/32
54.150.11.204/32 (Connection verification only)
52.68.53.105/32 (Connection verification only)
After external logging is established, it might be automatically put on pause if the external system becomes unavailable and the number of the events in the queue reaches a threshold of 50. If this happens, you will have to manually resume the external logging after correcting the issue. We recommend setting up an alert for the "Paused Audit log Sync" event so you get notified if the external logging is paused.
SIEM event push to local or on-prem endpoints using Keeper Commander
In addition to using the user interface for generating custom reports, Keeper supports a command-line interface (CLI) and Python SDK to programmatically generate reports. Keeper Commander is an open source tool that provides command-line access and automation / integration capabilities.
Learn about Keeper Commander here: https://docs.keeper.io/secrets-manager/commander-cli
For example, below is a screenshot of the "audit-report" command usage which can be used to generate custom reports through the CLI:
Keeper Commander also integrates into 3rd party SIEM solutions that operate on-premise. For a comprehensive look at how Keeper Commander can be utilized in your environment, please visit the Documentation Portal for Keeper Commander SDK. If you require assistance with Keeper Commander, please contact commander@keepersecurity.com.
Best Practices and Recommended Alerts for Advanced Reporting System
Keeper's Advanced Reporting System provides built-in Alerting capabilities that will notify users and Administrators for important events. As a best practice, Keeper has created a list of recommended alerts that can be configured by the Keeper Administrator.
To create an alert, login to the Admin Console and visit Reporting & Alerts > Alerts.
Alerts is only available to customers who subscribe to Advanced Reporting & Alerts module. To upgrade, please contact your Keeper customer success representative.
It is important that the Keeper Admin is notified when any administrative changes are made on the Keeper Admin Console which can affect the security and usage of the platform. We recommend selecting all "Policy Change" events.
Critical system events in this category include the following:
Event | Threat / Description |
Created Node | Ensure this action is approved. |
Deleted Node | Ensure this action is approved. |
Created Role | Ensure this action is approved. |
Deleted Role | Ensure this action is approved. |
Created Team | Ensure this action is approved. |
Deleted Team | Deleting a team could also removed Shared Folder access. Ensure this action is approved. |
Changed Role Policy | Role enforcement policies can affect many different threat vectors |
Set 2FA Configuration | Duo or RSA integration could be interrupted. |
Created Alert | Admin created an alert in the Advanced Reporting system |
Deleted Alert | An Admin deleted an alert which could prevent detection - ensure that this was an expected action. |
Paused Alert | An Admin has paused an alert which could prevent detection - ensure that this was an expected action. |
License reached maximum | Notifies if you are reaching your maximum user count, will ensure that new users can be onboarded to the platform. |
We recommend that the Keeper Admin (and the user who performs the action) is notified when any User-Specific changes occur. At minimum, we recommend generating alerts on several key events within the "Security" category.
Critical User Management and Security Change events include the following:
Event | Threat / Description |
Invited User | Ensure that only approved users are invited to the platform. |
Created User | Ensure that users who join the Enterprise are approved. |
Deleted User | Ensure that user deletion is approved. Note this action also deletes all vault contents. |
Locked User | Admin has locked a user from the platform. Ensure this action is approved. |
Disabled 2FA By Admin | A user's 2FA has been turned off by the Keeper Admin. Ensure this action is approved. |
Device Approved | A user has signed into a new device. This event may generate a lot of alerts depending on number of users. |
Admin approval for device requested | User may need assistance to approve a new device. Login to the Admin Console to approve. |
Transferred vault | The user's vault has been transferred to another user account. Ensure that this action is approved. |
Granted Admin Permission | The user has been added to a role with Administrative permission. Ensure that this user is approved for administrative duties. |
BreachWatch provides organizations oversight of the vulnerabilities of user's passwords through active monitoring of dark web breach data. Users and administrators are notified if any of their passwords in a record have been used in publicly known breach that could leave your organization vulnerable to a credential stuffing attack or an account takeover.
Before you configure the alert, ensure that BreachWatch events are configured to flow through the Advanced Reporting & Alerts module. This is disabled by default.
Go to the Role of the users affected by the policy > Enforcement Policies > Vault Features and turn the setting to ON.
In the Alerts section of the Advanced Reporting & Alerts module, create an alert with all 3 event types within the BreachWatch category.
Critical BreachWatch events include the following:
Event | Threat / Description |
BreachWatch detected high-risk record password | The user has either created a record or imported data with weak passwords or a password known to be breached on the Dark Web. |
User ignored detected high-risk record password | The user has clicked "Ignore" on a detected breached password. |
User resolved detected high-risk record password | The user has successfully changed a password that was previously flagged by BreachWatch as a breached password. |
Depending how many Keeper Administrators you have in the organization, you may want to be alerted every time an Admin Console login occurs.
Event | Threat/Description |
Console Login | Ensure that the user should be granted Administrative rights. |
Note that new Keeper events are added on a monthly basis as the functionality and features of the platform are enhanced. Therefore, we recommend reviewing the latest event types on a regular basis to ensure that you are informed of the latest capabilities.
Integrate Keeper Webhook events into Slack, Microsoft Teams and other cloud services.
Webhooks are user-defined HTTP requests that are triggered by an application and pushed into other applications.
Popular uses of Webhooks are the following:
Sending realtime notifications to Slack, Microsoft Teams or other messaging platforms
Integrating Keeper events into your custom software, hosted in the Cloud
Developing integrations into Keeper using 3rd party platforms such as IFTTT
The Keeper Admin Console supports the ability to push custom Webhook events.
When sending a Webhook, you can substitute fields with one of the below variables.
Name | Description |
#alert_name | Title of the event as appears in the Admin Console |
#description | Description of the Event. See reporting & alerts page for list of all possibilities. |
#timestamp | Time which the event occurred |
#remote_address | External IP address of the user generating the event |
#username | User who generated the alert or could be empty depending on the event |
#json | Raw JSON event data (useful for debugging and inspecting fields) |
Depending on the type of event, there are other variable substitutions available.
Name | Description |
#to_username | For sharing events, the destination user |
#from_username | For sharing events, the source user |
#record_uid | For Record events, the Record identifier |
#shared_folder_uid | For Shared Folder events, the folder identifier |
#folder_uid | For Folder-specific events, the folder identifier |
#team_uid | For Team events, the Team identifier |
#role_id | For Role events, the Role ID |
#node | For Node events, the Node ID |
#enforcement | For Role Policy changes, the enforcement name |
#seats | For MSP events, the number of seats |
#seats_added | For MSP events, the number of seats added |
#seats_removed | For MSP events, the number of seats removed |
You can also include hyperlinks for convenience into various areas of the Keeper platform. A few examples:
Vault Login URL:
US: https://keepersecurity.com/vault
EU: https://keepersecurity.eu/vault
AU: https://keepersecurity.com.au/vault
CA: https://keepersecurity.ca/vault
JP: https://keepersecurity.jp/vault
US_GOV: https://govcloud.keepersecurity.us/vault
Admin Console URL:
US: https://keepersecurity.com/console
EU: https://keepersecurity.eu/console
AU: https://keepersecurity.com.au/console
CA: https://keepersecurity.ca/console
JP: https://keepersecurity.jp/console
US_GOV: https://govcloud.keepersecurity.us/console
Keeper supports Deep Linking into the Web Vault for a particular Record UID. Example:
https://keepersecurity.com/vault/#detail/XXXXXX
replace XXXXXX with the Record UID as it appears in the Keeper record or substitute #record_uid
Make sure to replace .com with the proper domain as listed above
We have documented a few examples for popular endpoints below.
Send Keeper advanced reporting and alert notifications to Slack
Using the Webhook feature, you can send custom alerts and actions to your Slack channel following the steps below.
(1) Go to https://api.slack.com/apps and Create a new app
(2) Name the App, select your desired Workspace and click Create App.
(3) Click on Incoming Webhooks
(4) Activate the Webhook and click "Add New Webhook to Workspace.
(5) Select the Slack channel you would like the alerts to be sent. Then click "Copy" to grab the Webhook URL required to plug into the Admin Console interface in the following steps.
(6) In the "Basic Information" section on the left, you can populate the icon with the Keeper icon. Right-click and save the image Use the link below to download a 512x512 PNG icon for Keeper: https://keeper-email-images.s3.amazonaws.com/common/Keeper_512x512.png
(7) Login to the Keeper Admin Console and visit Reporting & Alerts > Alerts and create a new alert. After selecting the desired Event Types and Attributes, click on "Add Recipient". In the example below, I have selected all Policy Changes.
(8) Enter the Name and Email address to receive the event, and click Add Webhook.
(9) Paste the Webhook URL from Step 5 and copy and paste the HTTP body content below
(10) Copy-paste the below JSON content into the HTTP Body section.
(10) Click Save on the recipient and Save the alert.
That's it. Please note that it can take up to 15 minutes for events to start transmitting. You can modify the HTTP Body according to your preferences. Slack's Block Kit Builder allows you to customize the look and feel completely.
Creating new Webhook body content and editing content may take up to 15 minutes to take effect.
Another use case is to be notified when a record is added to a particular Shared Folder.
(1) Follow the Slack setup steps above to create a baseline Slack integration.
(2) In the Web Vault, grab the Shared Folder UID that you would like to report on
(3) On the Admin Console, create a new Alert for this event that is tracking "Add Record to Shared Folder"
(4) Under the Attributes section, paste the Shared Folder UID
(5) Under "Recipients", create a new Webhook recipient.
(6) Copy Paste the below JSON text body into the HTTP Body section. In the "text" field, you will want to edit it to match up with the alert that you are creating.
Send Keeper advanced reporting and alert notifications to Microsoft Teams
To send rich formatted alerts to your Microsoft Teams platform, follow the instructions below:
(1) From the Teams main screen, go to applications and search for incoming webhooks. Click Add to a team.
OR click ... on an existing channel and choose "Connectors".
(2) Give it a name and click "Create".
(3) Click the copy button next to the URL
(4) Login to the Keeper Admin Console and visit Reporting & Alerts > Alerts and click on an existing alert or create a new one.
(5) Select Recipients > Add Recipients
(6) Type in the Recipient Name and email address and click Add Webhook.
(7) Paste the Webhook URL from Step 3 and then copy and paste the content for the HTTP body below.
(8) Copy this JSON content and paste it into the HTTP Body section in the screenshot above.
(10) Click Save on the recipient and click Save on the alert.
That's it. Please note that it can take up to 15 minutes for events to start transmitting. You can modify the HTTP Body according to your preferences. See the Microsoft Connectors website to customize the look and feel completely.
Creating new Webhook body content and editing content may take up to 15 minutes to take effect.
For Mac / Linux users, a quick way to test your format is to use curl:
Put the Webhook content into a test file such as test.json
Run the Curl command with the following syntax, replacing URL with your Slack or Teams URL
Send Keeper advanced reporting and alert notifications to Amazon Chime chats
Setting up a Webhook in Amazon Chime is straightforward and can be done in just a few steps. Follow the instructions below to create a Webhook for your Chime chat room:
(1) Log in to Amazon Chime
Access Amazon Chime: Open the Amazon Chime app on your desktop or go to the web version at Amazon Chime Web.
Log in: Enter your credentials to log in to your Amazon Chime account.
(2) Select a Chat Room
Navigate to the Chat Room: From the Chime home screen, find and select the chat room where you want to receive notifications via Webhook.
Open Room Settings: Click on the room name at the top of the chat window to open the room settings.
(3) Access Webhook Settings
Scroll to Integrations: In the room settings, scroll down to the Integrations section.
Add Webhook: Click on Add Webhook. This will bring up the Webhook creation interface.
(4) Create the Webhook
Name the Webhook: Enter a name for your Webhook (e.g., “Keeper Alerts”). This name is for your reference and helps you identify the Webhook later.
Create the Webhook: Click Create to generate the Webhook URL.
(5) Copy the Webhook URL
Copy the URL: After the Webhook is created, a unique Webhook URL will be displayed. Copy this URL as you will need it to send notifications to the chat room.
(6) Login to the Keeper Admin Console and visit Reporting & Alerts
Login to the Keeper Admin Console and visit Reporting & Alerts > Alerts and create a new alert. After selecting the desired Event Types and Attributes, click on "Add Recipient".
Enter the Name and Email address to receive the event, and click Add Webhook.
Paste the Webhook URL from Step 5
Copy-paste the below JSON content into the HTTP Body section.
(7) Click Save on the recipient and Save the alert
Creating new Webhook body content and editing content may take up to 15 minutes to take effect. Chime Webhooks primarily use simple text messages and support basic Markdown formatting.
Reference:
https://docs.aws.amazon.com/chime/latest/ug/chat-webhooks.html
Compliance Reports provide on-demand visibility of the access permissions associated with your enterprise records.
As Identity and Access Management (IAM) cybersecurity regulations increase, it is important for companies and public institutions to employ a broad set of policies and tools to ensure compliance. Access control to credentials and sensitive information is foundational to achieving this compliance. Some regulations that companies may be required to adhere to include: SOX, GDPR, PCI, HIPAA, HiTRUST, GLBA, FERPA, and New York SHIELD ACT. Each industry has a specific set of data security rules to follow, and compliance with these regulations can be complex and time-consuming.
In addition to the access controls and ARAM reports that Keeper Security already provides for compliance, Keeper offers an add-on reporting feature called Compliance Reports.
Compliance Reports provide on-demand visibility to access permissions on records and credentials in your enterprise. These reports simplify the compliance auditing process for Sarbanes Oxley (SOX) and other regulations requiring periodic access control auditing. These Keeper Administrator-defined Compliance Reports run on-demand and can be forwarded to automated compliance systems or sent directly to external auditors. Since the reports contain some non-credential encrypted record data, an administrator must have permission to run and view these reports. The encrypted record data is included in the report and can also be used as report filters.
The encrypted record data ONLY includes:
Record Title
Record Type
URL
Zero-knowledge remains preserved because the encrypted data is decrypted on the Keeper Administrator Console using the Enterprise Private Key, restricted to administrators that have Compliance Reporting permission.
Privileged user reports for SOX auditing: Select privileged users and run a report showing all owned and shared records for these privileged users.
Corporate credit cards report for PCI compliance: Select all users ( if 5000 or less) then select one or more record types (i.e. payment card, database, login) and generate a report showing all user access and permissions for the selected record types.
Decommissioning user report: Before decommissioning users and transferring their Keeper accounts, run a report showing all the users’ owned records.
Report of access permissions on records containing specific URLs (i.e. financial services): Select all users (if 5000 or less) and select 1 or more URLs then run a report showing all records and access permissions for records containing the selected URLs.
Visit the Subscriptions screen and click on Free Trial to activate your trial of the Compliance Reports Add On.
Once the Keeper Compliance Reports feature is activated through a trial or purchase, there will be a new administrator role permission in your Admin Permissions popup menu called “Run Compliance Reports”. Select this permission for administrator roles that will be authorized to create, view, and edit compliance reports.
If “Cascade Node Permissions” is selected, the administrator will also be able to run, view or edit reports for the sub-nodes.
No other administrator permission is required to run, view or manage Compliance Reports. The auditor does not need “Manage Users” or “Manage Nodes” permissions to run Compliance Reports.
When an administrator with permission to “Run Compliance Reports” logs in to the console, they will have access to the “Compliance Reports” left-side menu item.
When “Compliance Reports” is selected, the list of saved compliance reports will be shown. The administrator will only see those reports associated with nodes where the administrator has “run compliance reports” permission.
After selecting “New Compliance Report” from the Compliance Reports screen, you will be prompted to enter the report criteria.
User Criteria
Initially, “User Criteria” is selected. User criteria include:
Node
User names/email addresses
Job Titles
Records
The “Node” selected will determine the report association and also the users available for the report. “Job Titles” are available if manually entered in user data or imported via a CSV file. In a future release, “Job Titles” will be available via import from an IdP using SCIM provisioning. “Records” may include all owned records or only those records which are owned and also shared.
Selecting a “Node” will determine the users to be included in the report data filtering. If the root node is selected and the Administrator has “Cascading Node” permission in addition to “Compliance Reports” permission, all users in the enterprise will be selected as an initial user filter.
The user count will be displayed on the right side of the screen. As other user criteria filters are selected, the matching user count will reflect the added filters.
After selecting all user criteria or some subset of users through the filters, select “Get User Data” and the screen will show how many total records are available for those selected users.
Keeper limits the number of users to 5000 for performance reasons. A Compliance Report is limited to 1000 records. Report records can be selected by filtering the data by a single filter or a combination of filters. To get more than 1000 records, run multiple reports with similar filters, as an example: One report per node, instead of one report for all nodes.
Record Titles
Record UIDs
Job Titles
Record Types
Website URLs
Each set of filters added will potentially add additional records to the report. If a record matches the search criteria for multiple rows of filters, the total record count and report will reflect unique records and not duplicate records.
Once the filters have been defined, the user can select “View Data” to preview the report which reflects the current users and permissions for each of the selected records.
The report data is displayed in layers, first showing the list of record owners and the number of records for each owner.
For each record owner, there is a “User Report” page that shows user details which includes the user’s owned records and the number of users sharing each of these records.
The record access permissions for each user can be viewed by selecting the ">" at the end of a record row.
If a user has access to the record from multiple sources, there will be a popup to view the “Effective Permissions” and all the permission sources for access to that record.
Individual User Reports can be exported in PDF, JSON, or CSV format. The administrator may want to review one or more User Reports before generating the final snapshot report containing all of the users selected.
After reviewing the report data and filters, the administrator can save the settings as a report template by selecting “Create Report”.
The system will generate and save a snapshot report containing the following:
Header with the report name
Date and time
Report criteria used to generate the report.
This header information is followed by the user records pages which contain the records and associated user access information. Creating a report will result in the system fetching the latest record data, which will reflect any permission changes that may have occurred while the report data was being viewed.
Saved reports can be viewed and rerun from the “Compliance Reports” tab. When re-running a report, the report criteria can be edited, and the new report criteria will be saved with the new report snapshot.
An administrator with Compliance Reporting permission may want to create and save report criteria without running a report. This is useful for reports that are going to be run at a later date or run periodically (i.e. quarterly SOX report).
Select “Criteria Filters” to see the report criteria that have been saved. To create new report criteria, select “New Compliance Report”, name the criteria and then save it by selecting “Save Filters”.
Any administrator with “Run Compliance Reports” permission can create, edit, delete or run any compliance report or report criteria associated with a node where they have “Run Compliance Reports” permission.
Keeper Commander CLI/SDK provides a few extra capabilities that are not available in the user interface of the Admin Console, for advanced searching and parsing of compliance reporting data.
For more information about the Keeper Commander tool visit this page:
https://docs.keeper.io/secrets-manager/commander-cli/overview
Ensure that you're using the latest version of Commander, either through binary installation or using pip3
.
For a full description of the compliance-report
command capabilities, type:
Searching on a specific user:
Searching for a partial URL match, e.g. amazon.com
Full command details are available at the documentation page.
Keeper Compliance Reports adheres to Keeper's Zero-Knowledge encryption model. From an encryption standpoint, here's how it works. When the Enterprise end-user logs into their vault, the Type, Title and URL fields are encrypted with the Elliptic Curve Enterprise Public Key. This data, we call the "Audit Data", is encrypted locally on the user's device and stored in the Keeper cloud. The Audit Data is continuously updated by the end-user devices over time.
The Keeper Administrator logs into the Admin Console using either a Master Password or Single Sign On. After a successful login, the Admin decrypts what we call the AES 256 Enterprise Tree Key and then decrypts the Elliptic Curve Enterprise Private Key. If the Administrator has permissions to run Compliance Reports, they can run a report over any user within the node that they have been granted permissions.
The encrypted audit data is delivered to the Admin Console and the Admin is able to decrypt audit data locally on their device using the Elliptic Curve Enterprise Private Key. The report contents are then displayed locally on the user interface and available for export into CSV, JSON or PDF format. Only the designated Keeper administrator can retrieve and decrypt the compliance report data for the nodes that they have been granted admin rights over.
Offline access is a common use case for organizations who require vault access in poor network conditions or when SSO is unavailable.
Offline Mode allows users access to their vaults from any device when they are not able to connect online to Keeper or to their SSO Identity Provider. Offline access is available for Keeper Web, Desktop, iOS and Android Mobile Apps.
This capability works by making a copy of your encrypted vault to your local device. The vault ciphertext is stored in an encrypted format which is only accessible if the user provides their Master Password or biometric authentication. Offline access also works with multiple accounts on the same device.
Master Password
Biometrics
Mobile | iOS |
Mobile | Android |
Desktop | Keeper Desktop (Mac, Windows, Linux) |
Web Browser | Web Vault (Chrome, Safari, Firefox, Edge) |
If your organization's SSO is not available (e.g. is offline), click Work Offline in the lower right corner of your screen then click Enterprise SSO Login > SSO User with a Master Password to gain access to your vault offline.
From the login screen, enter your Master Password to login offline.
For users who normally login with SSO and do not have a Master Password setup, you must first configure one in order to login to Keeper when offline by visiting your vault Settings Menu.
This feature can be activated by the Keeper Administrator from the Keeper Admin Console. The role enforcement policies are documented here.
To access Offline Mode, your device will need to be “primed” with a local copy of your vault by logging in with an online connection at least once. Moving forward, you will have access to all of the records in your vault and you can create new records and edit existing records, all without requiring a network connection.
Users can confirm their Keeper Vault is available offline via a lightning bolt icon or "Available Offline" text which indicates your vault data has been loaded onto that device. If the availability indicator is not present, you will need to login to your vault at least once while online.
To activate Offline Mode from the vault login screen or from within your vault on Keeper Web or Desktop, click on the Work Offline button in the lower right corner of your screen. On iOS and Android, Offline Mode will automatically be initiated when logging in if you aren't connected to the internet.
The "Offline Mode" indicator will appear at that top of your vault window.
When biometrics (Touch ID, Windows Hello) have been activated on an account from the Keeper Desktop application, you can use this to authenticate offline instead of a Master Password.
To login offline with biometrics, first activate it from the Settings > Security screen.
To login offline with biometrics, click on Work Offline, then click on the Touch ID or Windows Hello icon.
You can resume a session online at anytime (provided you have a stable network connection) by clicking Go Online in the upper right corner of your vault window.
Keeper's offline capabilities are central to a user's ability to retrieve important data even in the poorest of network conditions. Key vault features that are available offline include:
Creating new records
Editing records
Moving records and shortcut creation (Mobile App)
Viewing your Security Audit score
Viewing Deleted Items (Web and Desktop)
A notice will appear if you attempt to perform an action that is not available while offline.
If a device is being used temporarily (e.g. a borrowed PC), then the stored offline vault can be deleted from that device.
From the vault login screen, click the dropdown icon in the email address field, then click the "X" to the right of your email address to delete all offline data associated with that vault from the device. This action can be similarly performed on all Keeper platforms.
When logging in offline on a Web Browser (Chrome, Firefox, Safari, Edge), the user must navigate to the exact URL: US Data Center: https://keepersecurity.com/vault US Public Sector / GovCloud: https://govcloud.keepersecurity.us/vault EU Data Center: https://keepersecurity.eu/vault AU Data Center: https://keepersecurity.com.au/vault CA Data Center: https://keepersecurity.ca/vault JP Data Center: https://keepersecurity.jp/vault
Offline access for users can be enabled or disabled via the Admin Console's Enforcement Policies menu with a simple toggle, by default Offline Access is enabled.
To provide users who normally login with SSO the ability to access their vault in offline mode, the Keeper Administrator can enable the use of a Master Password as a role-based enforcement, this feature is disabled by default.
To enable SSO users the ability to set a Master Password for offline access, turn "on" the Allow users who login with SSO to create a Master Password toggle in the Login Settings section of Enforcement Policies menu.
In order have a local repository to access offline the vault needs to have been authenticate and synchronized online first at least once.
Ensure that the Remember Email checkbox is selected at the login screen of the Web Vault.
The data in the vault will be as current as the last data push.
Master Password or Biometrics support offline access.
By definition, Two-Factor Authentication protects cloud-based APIs and online authentication. When users authenticate to their vault, they authenticate both locally and on the server. During offline mode, the user is authenticating locally and decrypting their vault. Therefore, during offline mode, users are not prompted for Two-Factor Authentication.
If 2FA is enforced for every login from role policies or user selection, offline mode will not function on that particular device.
Manage and protect your cloud infrastructure with zero-trust and zero-knowledge security.
Keeper Secrets Manager provides your DevOps, IT Security and software development teams with a fully cloud-based, Zero-Knowledge platform for managing all of your infrastructure secrets such as API keys, Database passwords, access keys, certificates and any type of confidential data.
See: Secrets Manager Documentation
Common use cases for Secrets Manager include:
Removing hard-coded credentials from source code
Replacing configuration file secrets
Pulling secrets into CI/CD systems like Jenkins, GitHub Actions and More
Protecting access to privileged passwords, API keys and other managed secrets.
Providing vault access to machines and applications
Powering automated password rotation for AD users, machines, databases and more.
To start using Keeper Secrets Manager, click on "Free Trial" from the Admin Console Subscriptions page.
After activation, you can turn on Secrets Manager within the role enforcement policies for particular users and roles at the company.
When users in the role login to the vault, a new "Secrets Manager" tab appears on the left. This is where your team can create and manage their applications.
Shared Folders in the Vault will have a 3rd tab next to Records and Users. This is where you can assign folders to Applications. Below, the "Development Secrets" folder can be accessed by the Jenkins build server, Azure DevOps and Glyptodon, among other apps.
Secrets Manager is pre-built with support for the most popular CI/CD tools such as Ansible, Docker, Github Actions, Kubernetes, Terraform and more.
Developer SDKs in all the most popular languages is also available.
With the launch of Keeper Connection Manager, secrets from the vault can be used to establish privileged sessions to target machines and databases.
To get started with Keeper Secrets Manager, follow our Quick Start Guide