General Overview

Integration with Microsoft Active Directory Version 5.1
Keeper Bridge allows businesses running Microsoft Active Directory to fully integrate Keeper password management software within their current systems, automatically adding any number of users to Keeper and deploying Keeper to any user.

Keeper Bridge is designed to use the Lightweight Directory Access Protocol (LDAP and LDAPS) to communicate with LDAP based Directory Services for the purpose of automating the Keeper group Invite process within an enterprise organization.

Keeper Bridge consists of a tray application and a windows service. The tray application allows the user to configure settings specific to the Directory Service and also functions as a service controller allowing the user to adjust LDAP Filter settings and publish to the service for updates. The windows service is designed to Poll the Directory for users within the Distinguished Name (DN) path provided, inviting users to join the Keeper group. The Polling Interval can be configured from 5 to 1440 minutes. The Tray Application can be installed on multiple systems for use by multiple admins. The service should be installed only on one host system. All tray applications access the single instance of the service.

Installation

Installation is performed using the setup program provided. Several pieces of information are required to complete setup:

1. Domain Name or Host Name or IP Address for the Active Directory server.

2. An existing Security Group defined which the application will use to authorize users for access to the application.

3. The Host Name or IP Address of the system running the Keeper Bridge Service and the port used during the installation of the Keeper Bridge Service. In cases where both are installed to the same system defaults can be used or specific values can be defined.

Windows Tray Application

Login Form
The Login form secures the Tray Application and the service using Active Directory credentials and authorizes users with the Admin Security Group defined during installation. Active Directory credentials and all communication from the Tray Application to the service are encrypted and signed. The connection settings for the service can be changed using the Settings drop down.

Tray Icon
The Keeper Bridge tray icon provides a convenient menu for accessing the Settings form, the Help form or the Enterprise Admin Console online application.

Settings Form

The Settings form can be accessed from the tray icon allowing the user to define their LDAP connection settings, the Bridge Access Identity, the Distinguished Name path and User Filter. The primary purpose of the form is to configure the LDAP Settings and the Keeper group identity for use by the windows service. With these settings defined the form allows the Admin to review the Users and Groups returned by the filter and adjust the filter accordingly. Making changes to the form and using the Save button allows the Admin to review the results of the filter before Publishing the changes for the service.

LDAP Account Settings

1. Domain Name
The Domain Name used for Authentication and object lookups. When Global Catalog is enabled (default) the Domain Name is used to find the Global Catalog.

2. LDAP Port
The default TCP Port for LDAP connections is set to 389. All communications on port 389 are encrypted with Kerberos using Sign and Seal. Selecting the SSL checkbox will change the port to 636 and will encrypt data using SSL. When Global Catalog is enabled (default) ports 3268 (Kerberos) and 3269 (SSL) will be used for object lookups.

3. User Name
The User Name for the Principal User account used to browse the Distinguished Name (DN) path and invite users to join the Keeper group. This user should be set up with read-only permissions. The Principal User is a read only account that provides access to the Directory from the tray application or windows service even when the console is not logged in to the system. In cross domain environments it may be necessary to use DOMAIN \ USERNAME format if the user context is not within the domain name specified.

4. Password
Principal User account password. This password is stored locally, encrypted using AES 256.

5. Test Connection
Performs an LDAP Bind using the Domain Name and Port with the user credentials. A successful test indicates that all LDAP connection settings are valid.

6. Group DN Path
The Distinguished Name path to a Security group within the Directory where the windows service will read for user objects. If the user is not found to be already Invited or Accepted into the Keeper group, an invite will be sent to the user. This could be an existing group in the Directory or a group created specifically for Keeper users, where existing groups or users are then added for invitation to the Keeper Group.

7. User Filter
The User Filter is defaulted to a basic filter that will work for many Directory implementations. The default filter is created when the user provides a DN path and Saves the local settings or uses the Apply Filter button. Once the default filter has been set, changing the DN Path will have no effect on the filter. The filter must also be modified for the same change or reset to the default filter using the Apply Filter button.

8. Apply Filter Button
The Apply Filter button sets the filter to the default filter based on the DN Path provided. See the User Filtering help document for more information.

9. Service Status
Local Settings reflects the state of local form changes. When making changes to the form the Local Settings status will change to “Save Required” reflecting that the form has been edited from the Saved or Published changes. Using the Save button will commit the changes locally and update the metrics on the form to reflect the updates. At this point the changes are considered “Not Published” meaning that the local form is using the changes but the service is still running on the last changes Published. This allows the admin to carefully make and assess changes to the filter while not interrupting the currently published settings. Once the Admin is satisfied with the changes they can then be published to the service allowing the service to now act on the new settings. NOTE: Locally Saved settings will be lost if not published when the tray application is exited. Using the Reset link button will restore the last published changes to the form.

10. Status Indicators
The status indicators monitor the status of the Keeper API, the Directory server and the Keeper Bridge service based on the last published changes. If there is a problem in network connectivity or responsiveness of the system the indicator will turn red. If systems are functioning normally the indicator will be green. The text for each indicator also reflects the current status.

11. Users/Groups Affected Metrics
In many situations it can be challenging to understand which groups and/or users in the Directory will be affected by the defined filter. These metrics help the Admin to confirm that the filter defined is affecting the intended users. Clicking on either link (Users Affected or Groups Affected) will show a list of the affected users or groups. The tray application polls the Directory every 15 seconds and updates on each change to show in real time the effect of the filter and DN path provided. When the tray application is in a minimized state or closed, the application will not query the directory saving network resources.

12. Options Form Button
The Options link button opens the Options Form. See the section for the options form for detailed description of each option.

13. Bridge Access Identity
The Bridge Access Identity identifies the group to be managed by the application. This Identity token can be obtained by a Keeper Group Administrator by logging into the Keeper Group Admin Console at https://keepersecurity.com/console and clicking on the Keeper Bridge tab. The Enterprise Admin Console allows the Admin to Generate and Revoke and see the status of the current token. The token is single-use only and does not expire.

14. Apply Button
The Apply Button will update the service with the Bridge Access Identity token entered. The token will be removed from the text box and the Keeper status indicator will change from Identity Required to Online and the Keeper Group Metrics will be displayed.

15. Keeper Metrics
The Keeper Metrics are updated every two minutes. This shows a running count of users invited and users which have accepted the invitation to the Keeper group. When the tray application is in a minimized state or closed, the application will not query for Keeper Metrics saving network resources. Clicking on the respective link buttons will display lists of users and their status.

16. Resolve Name
The Resolve Name button allow the Admin to enter just the group name in the Group DN Path field, then using the Resolve Name button will translate the Group Name to a Group DN Path. The LDAP settings must be valid for the Group Name to be resolved.

17. Save and Publish and Reset Buttons
The Save button commits local changes and makes them active on the form. LDAP Metrics for groups and users are updated to allow the Admin to review the results of LDAP changes. The Save button does not persist changes to the service until the Publish button is used. This allows the Admin to review local changes before Publishing them to the service. The Publish button persists the local changes to the service allowing the service to take action based on the new changes. The Reset button loads the last changes published from the service.

Options Form

The Options Form can be accessed from the Settings form with the “Options” link on the top right of the form. The Options Form allows the Admin to configure Keeper Account Options as well as some Service related options. To enhance seamless security of Keeper Accounts with Active Directory the Admin may choose to Disable keeper accounts when the Active Directory account is disabled or Lock accounts for deletion when the Active Directory account is removed. In addition some settings to control service related actions such as the Admin Security Group, The Polling Interval and Debug mode are available here.

1. Delete Keeper Account
The Delete Keeper Account checkbox when checked will “Lock” the Keeper account for deletion when the user’s Directory account has been removed from the filter on the next Polling cycle. User accounts which are added back to the filter will be unlocked if the account is in a locked state and the Delete Keeper Account option is checked. Keeper account access is prevented as long as the account is in the “Locked” state.

2. Disable Keeper Account
The Disable Keeper Account checkbox when checked will “Disable” the keeper account when the Active Directory account has been disabled on the next Polling cycle. Keeper account access is prevented as long as the account is in the “Disabled” state. Enabling the Active Directory account will allow access to the Keeper account on the next Polling cycle when this option is enabled.

3. Admin Security Group
The Admin Security Group is used to secure access to the Keeper Bridge application using Active Directory login credentials. The Login Credentials supplied on the Keeper Bridge login form must be for a valid Directory Services account which is in the Security Group defined. The Admin Security Group information is set by the installer and can only be changed on the Options form or by reinstalling the application.

4. Debug to Event Log
The Debug to Event Log checkbox enables debug logging to the event log. With this box unchecked only errors are logged. Check this box for more verbose logging.

5. Polling Interval
The Polling Interval defines the period of time between Polling cycles. Each Polling cycle the Keeper Bridge Service polls the Directory based on the User Filter defined, inviting users and provisioning/deprovisioning accounts based on the options set.

6. Use Global Catalog
The Use Global Catalog option enables cross domain support by directing object lookups through the Global Catalog for the domain entered in Ldap Connection Settings. User authentication is still performed based on the user’s local domain. When including users from another trusted domain the groups involved must be Universal Security Groups. Global Catalog lookups are performed against port 3268 (Kerberos) or 3269 (SSL).

7. Close Button
Closes the form and updates the the Local Settings status to “Publish Required” if changes were made. All metrics on the settings form are refreshed to reflect any new options set.

Windows Service

The Keeper Bridge service is always running and is set for Automatic restart to ensure that the service is never left offline. The Service receives communication from the Tray application which is secured by Active Directory Administrator credentials using secure, signed kerberos exchanges for all communications.

The service runs as the system user even if the local console is not active, running in the background inviting users and monitoring for user accounts which have been removed or disabled at regular intervals. The Polling interval can be configured from the Options form anywhere from 5 minutes to 1440 minutes (1 day) between cycles. Locking and Disabling users are options and can be enabled on the Options form. Users newly added since the last Polling cycle will be Invited to join the Keeper group. Users who have had their account disabled will be locked out from the Keeper system. Users removed from the Directory Filter will have their Keeper account “Locked” for deletion. A “Locked” account can be managed by the Administrators from the Keeper Admin Console at https://keepersecurity.com/console. Keeper Account status can be reviewed using the Accepted to Group link button or by visiting the Enterprise Admin Console.

Encryption

Keeper Bridge utilizes 256-bit SSL to encrypt all data transport between the client application and KSI’s cloud-based storage which is standard for all Keeper Security, Inc. applications.

LDAP communication with the Directory Service utilizes Kerberos authentication with Signing and Sealing enabled for an encrypted data exchange and to ensure that the data was not modified by a malicious third party.

Removing Users

When a user leaves the company or should no longer have access to the Keeper group, the user must be removed through the Keeper Admin Console online application. This online application can be accessed through the tray icon or by opening https://keepersecurity.com/console.

Addendum A - Quick Start Guide

Welcome to Keeper Bridge

Open the Settings Dialog from the Keeper Bridge tray icon menu and configure the settings described below.

Step 1

Enter LDAP Connection Information

LDAP Port

The default TCP Port for LDAP connections is set to 389. Change this value only if the default LDAP port is not used.

SSL

Check the SSL Box to communicate using SSL over port 636. When not checked the application will use port 389 encrypting all traffic with Kerberos using Sign and Seal so all communication on port 389 is encrypted.

User Name

This is the User Name for the Principal User account used to browse the Distinguished Name (DN) path and invite users to join the Keeper group. This user should be set up with read-only permissions.

Password

Principal User account password.

User Name

This is the User Name for the Principal User account used to browse the Distinguished Name (DN) path and invite users to join the Keeper group. This user should be set up with read-only permissions.

Step 2

Enter Distinguished Name and User Filter

Group DN Path

The Distinguished Name path to the Security Group where the Keeper service should monitor for new Keeper users. All users in this path will be invited to join your Keeper group. A new Security group can be created for this purpose or an existing group can be used.

Example: (CN=KeeperUsers,OU=Chicago Office,dc=adserver1,dc=mydomain,dc=com). The Group DN path can be enetered manually or the Group Name can be entered and the Resolve Name button can be used to translate the Group name to a DN Path.

User Filter

Once the DN Path has been defined, clicking Apply Filter will create or reset to the default filter based on the DN Path entered. The default filter is the base filter generated from the current Group DN path value which searches for person objects in the DN Path and all sub groups in the DN Path. The User Filter can be edited to suit the needs of any domain schema.

Step 3

Review Keeper Options

Delete Account

Enables account locking for users which have been removed from the Group DN Path set in the User Filter. Accounts are not immediatly deleted, rather they are “Locked” for deletion. Locked accounts can be managed from the Enterprise Admin Console. Users cannot access their Keeper account while in a “Locked” for deletion state.

Disable Account

Disables the Keeper account when the Active Directory account has been disabled (from User’s and Computer’s -> User Account -> Properties -> Account tab) using the “Account is disabled” checkbox. Unchecking the “Account is disabled” check box will enable the Keeper user account on the next polling cycle.

Admin Security Group

The Security group required for accessing the Keeper Bridge client application. User’s logging in who are not part of this group with not be allowed access to monitor or configure the Keeper Bridge service.

Debug To Event Log

Enables verbose debug logging. When checked all progress and errors are logged. When unchecked only errors are logged. This options should be disabled unless troublshooting.

Polling Interval

Controls the period which the windows service sleeps between performing work in minutes.

Step 4

Enter Keeper Bridge Access Identity

Bridge Access Identity

A one time use token obtained from the Keeper Admin Console is required to authenticate your group identity.

Important

Select Apply to authenticate the Keeper group. The token value will be removed from the box and the Keeper status at the bottom of the form will reflect the Keeper connection status.

Using Save and Publish

The Save button commits changes locally updating the User/Group metrics for Directory Services allowing the user to see the result of filter changes. Saving will not persist settings if the application is closed. The Publish button pushes the local settings to the service persisting them across sessions and runs a Polling cycle on the newly published settings.

Addendum B - User Filtering

User Filtering

Keeper Bridge is designed to invite users to your Keeper group which are found in the Distinguished Name (DN) Path and User Filter defined. The DN Path can be set to any location within the Directory. It is not necessary to create a Keeper-specific Directory group.

Since each Directory Service implementation may differ and each implementation is expected to have varying needs, the User Filter is fully customizable. This allows you complete flexibility to define the portion of the Directory to invite your Keeper users.

Keeper Bridge creates a default filter based on the DN Path defined. This default filter will function for any site with the following assumptions:

1. A person or group in the Directory is defined by objectClass. (Required)

2. Keeper Bridge will search the DN Path and all nested groups for all person and group objects

3. A user account should always be Invited unless it has been deleted or moved out of the DN Path specified.

4. Disabled and accounts will be invited, unless Disable Accounts is Checked on the Options form.

If items 2 through 4 above are not desired, a custom filter can be created. A skilled Directory Services Administrator may be required to determine what a custom filter should include.

Default Filter

The default filter is created based on the DN Path entered.

Example default filter:

(&(objectclass=person)(memberOf:1.2.840.113556.1.4.1941:=CN=keeper, DC=ad1,DC=testdomain, DC=com))

The default filter has two filter conditions:

(objectclass=person) - Restricts object returned to a type of “person”. This filter condition is required for Keeper Bridge to distinguish between people, groups and other types ofobjects within the Directory.

(memberOf:1.2.840.113556.1.4.1941:=CN=keeper, DC=ad1, DC=testdomain, DC=com) - The OID (1.2.840.113556.1.4.1941) allows queries for users to be done in the Subtree starting in the DN path specified. Removing the OID restricts the users found to just the DN path specified and users in nested groups would not be returned.

Custom User Filter Examples

Example filtering for users only in the DN Path. Users which are in nested groups will not be invited (bold is the delta from default filter):

(&(objectclass=person)(memberOf:=CN=keeper, DC=ad1, DC=testdomain, DC=com))

Example filtering out disabled accounts (bold is the delta from default filter):

(&(objectclass=person) (!userAccountControl:1.2.840.113556.1.4.803:=2)(memberOf:1.2.840.113556.1.4.1941:=CN=keeper, DC=ad1, DC=testdomain, DC=com))

Example filtering out accounts that have been “Locked Out” (bold is the delta from default filter):

(&(objectclass=person) (!userAccountControl:1.2.840.113556.1.4.804:=18)(memberOf:1.2.840.113556.1.4.1941:=CN=keeper, DC=ad1, DC=testdomain, DC=com))

Example filtering out disabled accounts and accounts that have been “Locked Out” (bold is the delta from default filter):

(&(objectclass=person)(!userAccountControl:1.2.840.113556.1.4.803:=2)(!userAccountCotrol:1.2.840.113556.1.4.804:=18)(memberOf:1.2.840.113556.1.4.1941:=CN=keeper, DC=ad1, DC=testdomain, DC=com))

Example of filtering for users only in a geographic location (bold is the delta from default filter):

(&(objectclass=person) (physicalDeliveryOfficeName=Chicago)(memberOf:1.2.840.113556.1.4.1941:=CN=keeper, DC=ad1, DC=testdomain, DC=com))

Example of filtering out a specific user (bold is the delta from default filter):

(&(objectclass=person) (!sAMAccountName=jjones)(memberOf:1.2.840.113556.1.4.1941:=CN=keeper, DC=ad1, DC=testdomain, DC=com))

Keeper

Customers who purchase Keeper are provided an extra layer of control over their users and devices. Keeper administrators are provided access to an administrative console.The console allows the administrator to manage the users who belong to the organization, control the sharing of records and which devices are permitted to sync.

Keeper Administrative Console

http://keepersecurity.com/console

Delegated Admin & Policies

Keeper supports delegated administration for companies having multiple divisions or work groups. Role-based permissions control which users have access to shared credentials and files. Active Directory can deploy users into subgroups with roles defined by the enterprise or controlled via Keeper’s Admin Console.

Subgroups are defined by the group Admin. Within a subgroup, admin users are defined. Admins can be created in a subgroup via the Admin Console. For example, different divisions of a large enterprise customer can be separated into subgroups. Permissions do not cross subgroups.

Administrators of a Keeper subgroup create Roles via the Admin Console or automatically through AD group filters via the Keeper Bridge.

Roles & Shared Folders

A Role is a set of users that are associated with a set of Shared Folders. Roles are assigned restrictive permissions that limit their ability to edit and share records within a Shared Folder.

The implementation of role-based permissions allow the Delegated Admin of the Keeper group to assign restrictive permissions at a role or user level. Shared Folders are assigned both roles and users for the greatest flexibility and control. Encryption and decryption of records is managed in a zero-knowledge environment through the multi-layered distribution and synchronization of record decryption keys. Mobile and Desktop applications provide users with a seamless and easy-to-use system for accessing and building shared content, if permitted.

A Shared Folder can be created by anyone in the subgroup. A Shared Folder is assigned Roles or individual users. If the subgroup restricts sharing outside of the subgroup, only Roles and Users from that subgroup can be added. From the Shared Folder, the admin of that folder assigns which Roles/Users have the ability to manage the Shared Folder.

Technical Architecture

KSI does not have access to a customer’s master password nor does KSI have access to the records stored in the Keeper vault. KSI cannot remotely access a customer’s device nor can it decrypt the customer’s vault. The only information that Keeper Security has access to is a user’s email address, device type and subscription plan details (e.g. Keeper Unlimited). If a user’s device is lost or stolen, KSI can assist in accessing an encrypted backup file to restore the user’s vault once they have replaced their device.

KSI does not have access to a customer’s master password nor does KSI have access to the records stored in the Keeper vault. KSI cannot remotely access a customer’s device nor can it decrypt the customer’s vault. The only information that Keeper Security has access to is a user’s email address, device type and subscription plan details (e.g. Keeper Unlimited). If a user’s device is lost or stolen, KSI can assist in accessing an encrypted backup file to restore the user’s vault once they have replaced their device.

Information that is stored and accessed in Keeper is only accessible by the customer because it is instantly encrypted and decrypted on-the-fly on the device that is being used - even when using the Keeper Web App. The method of encryption that Keeper uses is a well-known, trusted algorithm called AES (Advanced Encryption Standard) with a 256-bit key length. Per the Committee on National Security Systems publication CNSSP-15, AES with 256-bit key-length is sufficiently secure to encrypt classified data up to TOP SECRET classification for the U.S. Government. In theory, it would take a 10.51 petaflop supercomputer approximately 3.31 x 1056 years to brute-force a 256-bit AES encrypted message.

The cipher keys used to encrypt and decrypt customer records are not stored or transmitted to Keeper’s Cloud Security Vault. However, to provide syncing abilities between multiple devices, an encrypted version of this cipher key is stored in the Cloud Security Vault and provided to the devices on a user’s account. This encrypted cipher key can only be decrypted on the device for subsequent use as a data cipher key.

Data Security

Client Encryption

Data is encrypted and decrypted on the user’s device, not on the Cloud Security Vault. We call this “Client Encryption” because the client (i.g. iPhone, Android Device, Web App, etc.) is doing all of the encryption work. The Cloud Security Vault stores a raw binary which is essentially useless to an intruder. Even if the data is captured when it’s transmitted between the client device and Cloud Security Vault, it cannot be decrypted or utilized to attack or compromise the user’s private data.

Data At Rest

Keeper uses PBKDF2 with HMAC-SHA256 to convert a password to a 256-bit encryption key with a minimum of 1,000 rounds.

The key generated from the Master Password isn’t used directly to encrypt user data, but is instead used to encrypt another key (the “Data Key”). The Data Key is used for encrypting data and other keys, such as the RSA private key.

Any key that is not generated directly from the user’s Master Password is generated by a cryptographically secure random number generator on the user’s device. For example, both the data key and the RSA key pair are generated on the device. Because the keys are generated on the device (not on Keeper’s Cloud Security Vault), we have no visibility into the user’s keys.

All secret keys that must be stored (such as each user’s RSA private key and the Data Key), are all encrypted prior to storage or transmission. The user’s Master Password is required to decrypt any keys. Since Keeper’s Cloud Security Vault does NOT have access to the user’s Master Password, we cannot decrypt any of your keys or data.

Data In Transit

To prevent unauthorized vault access, Keeper’s Cloud Security Vault must authenticate each user when transmitting data. Authentication is performed by comparing a PBKDF2-generated hash of the Master Password. The user’s device uses PBKDF2 to generate the hash from the Master Password and the server compares the hash to a stored hash.

By using the PBKDF2 hash instead of the Master Password itself, the Cloud Security Vault authenticates the user without requiring the Master Password. PBKDF2 is also used for generating encryption data keys, but the authentication hash is not used for data encryption.

KSI supports 256-bit and 128-bit SSL to encrypt all data transport between the client application and KSI’s cloud-based storage. This is the same level of encryption trusted by millions of individuals and businesses everyday for web transactions requiring security, such as online banking, online shopping, trading stocks, accessing medical information and filing tax returns.

KSI deploys SSL/TLS certificates signed by Digicert using the SHA2 algorithm, the most secure signature algorithm currently offered by commercial certificate authorities. SHA2 is significantly more secure than the more widely used SHA1, which could be exploited due to mathematical weakness identified in the algorithm. SHA2 helps protect against the issuance of counterfeit certificates that could be used by an attacker to impersonate a website.

KSI also supports Certificate Transparency (CT), a new initiative by Google to create a publicly auditable record of certificates signed by certificate authorities. CT helps guard against issuance of certificates by unauthorized entities. CT is currently supported in the latest versions of the Chrome web browser. More information about Certificate Transparency can be found at: http://www.certificate-transparency.org/

KSI utilizes Transport Layer Security (TLS) (versions 1.0, 1.1, and 1.2) to securely transfer encrypted customer data between the client and the Keeper servers. KSI also supports Perfect Forward Secrecy (PFS) key exchanges using Diffie-Hellman (DHE) enabled cipher-suites.

Two-Factor Authentication

To protect against unauthorized access to a customer’s account, Keeper also offers Two-Factor Authentication. Two-factor Authentication is an approach to authentication requiring two or more of the three authentication factors: a knowledge factor, a possession factor, and an inherence factor.

Keeper uses something you know (your password) and something you have (the phone in your possession) to provide users extra security in the event your master password or device is compromised. To do this, we generate TOTPs (Time-based One-Time Passwords).

Keeper generates a 10-byte secret key using a cryptographically secure random number generator. This code is valid for about a minute, and is sent to the user by SMS.

When using the Google Authenticator application on your mobile device, the Keeper server internally generates a QR code containing your secret key, and it is never communicated to a third party. Each time a user deactivates, then reactivates Two-Factor Authentication, a new secret key is generated.

Sharing Of Records

Each user has a 2048-bit RSA key pair that is used for sharing. Shared vault records are encrypted with the recipient’s public key. The recipient decrypts the record with their private key. This allows a user to share records only with the intended recipient, since only the recipient is able to decrypt it.

Product Support

If you have any questions please contact Keeper Support at: enterprise@keepersecurity.com