Keeper MSP Best Practices and General Recommendations
It is very important to maintain at least two users within the root node with full administrative access to the Keeper Administration Portal. If an admin gets locked out of the admin interface due to forgotten password, SSO service failure, enforcement policy settings, ect, the second account will be needed to recover the other. Keeper has no way of correcting such a situation.
Client (Managed Company)
Certain configurations require an administrative account within the MC: “SSO Connect” and “Keeper Bridge” both require an account with administrative access within an MC. The account is needed to bind the provisioning method to the MC instance. This is also true when “Keeper Commander” is used to independently manage an enterprise MC instance.
It's a good practice to only create as many roles as necessary and to name them for their functionality. For example, you have a team of traveling sales people who require offline access. It’s far better to name the role “Enable offline access” than “Traveling sales people”. This way, when you have an access issue six months down the road, you can easily tell what each role does as opposed to who it’s for.
Stacking of multiple roles against the same user and/or team is a common practice. Do keep in mind you will always get the least permissive / most restrictive outcome of the sum of the rules.
It’s a good practice to create a default role to host newly provisioned users. This is especially helpful when using a just in time advanced provisioning method. This way you know exactly what enforcement setting will be applied out of the gate. Common default settings include master password length and complexity and any 2FA requirements. This way you are insured all user vaults are secured at first login.
As your managed company(MC) and user count increases, so does the overhead of managing access control. For this reason it's a good practice to develop a set of standardized roles to use across the entire client base. This way, no matter which MC you are administering, you are ensured access control is consistent across the enterprise.
Account Transfer is an optional feature that should be configured by the Keeper Administrator during the initial deployment phase of the Keeper rollout. The reason for this is because Account Transfer relies on the sharing of encryption keys between users that have rights to perform the transfer. The exchange of keys occurs when the user logs into their vault to retain Keeper's Zero Knowledge infrastructure. Therefore, the Account Transfer setup must be configured prior to the user's account being transferred.
A successful transfer requires that the users had logged in at least once prior to the transfer action.
When an employee leaves the organization, an administrator with the proper Administrative Permissions can transfer a user's vault to another user within the organization. This account transfer functionality is an important and powerful way to take ownership of the content within the user's vault while retaining a secure role-based hierarchy in the organization.
Team sharing is localized within any Keeper instance. Teams are MC centric and may not contain users external to the MC such as a top-level MSP administrators. To circumvent the limitation, perform the following operation per shared resource (shared folder):
The following needs to be performed from an account located within the given MC. Not from an MSP admin account. The account needs to be local to the MC for the team sharing to work correctly.
Within the vault interface, edit each shared folder “Users” and add the email address of the MSP administrators who should have access to the shared folder. Be sure “Can Manage Records” or “Can Manage Users Records” is set as the user’s permissions for said folder. Then add any desired teams to the folder. Repeat this step for shared resources the MSP admins need access to.
MSP to MC Team "Re-Share"
Below is a list of recommended Enforcement Settings The following is applicable to your MSP technicians and end users alike:
Require Use of 2FA - Toggle to enable. Located under “Two-Factor Authentication”
Purging Deleted Records - Toggle to enable both “Days before records can be cleared permanently” and “Days before deleted records automatically purge” - We recommend setting this to 365 days Located under “Vault Features” at the bottom of the page
Prevent exporting of records from Web Vault and Desktop App - Toggle to enable. Prevents Techs from walking away with passwords if they were to leave. Located under “Sharing and Uploading”.
Transfer Account - Toggle to enable (very important and recommended for every user, regardless of role.) Located under “Transfer Account”
As an MSP, it is critical vault transfer is enabled. Otherwise, you run the risk of users getting locked out of the platform and loosing access to their vault.
Advanced reporting and Alerts (ARAM)
Below is a list of recommended Reports and Alerts to build within the MSP Admin Console:
(Report) Managed Company Changes:
Event types to select:
Under “MSP,” select all. Select desired time range. Click save.
(Report) Admin Activity:
Under users, select all admins.
Event types to select:
Under “Security,” Disabled Two Factor, Created User, Invited User, Transferred Vault, Added User to a Role.
Under “Policy Change,” Created Node, Deleted Node, Created Team, Deleted Team, Created Report, Deleted Report, Created Alert, Deleted Alert Under “General Usage,” Emptied Trash Bin, Imported Records, Exported Records
Under “MSP,” Increased Number of Seats, Decreased Number of Seats, Changed Plan, Paused Managed Company, Removed Managed Company, Deleted Managed Company Select desired time range. Click save.
(Alert) BreachWatch Alerts:
Event types to select:
Under “BreachWatch,” BreachWatch detected high-risk record password, User ignored detected high-risk password.
Under “Attributes” select “Email Addresses” and select all.
Choose desired alert frequency (We suggest every occurrence). If you would like to add other recipients to this alert, select “Recipients” and click Add. Click save.
(Alert) Brute Force Attack Watch:
Event type to select: Under “Security,” Failed Console Login.
Under “Login,” select Failed Login. Under “Attributes” select “Email Addresses” and select all.
Under “Alert Frequency” set to Number of Events > Every 5 occurrences If you would like to add other recipients to this alert, select “Recipients” and click Add. Click Save.
(Alert) Paused Companies:
Event type to select:
Under “MSP,” Paused Managed Company Under “Attributes” select “Email Addresses” and select all. Choose desired alert frequency (I suggest every occurrence). If you would like to add other recipients to this alert, select “Recipients” and click Add. Click save.
These same Reports and Alerts can be set at the Managed Company level, if desired, as long as the MC is part of a plan that includes ARAM (Business Plus and Enterprise Plus licenses only).