Keeper Bridge consists of a client application and a windows service. The client 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 Tree for Nodes, Roles, Teams and Users, providing a familiar structure for Role, Team and User management within the Keeper Admin Console and inviting users to join Keeper. The Polling Interval can be configured from 5 to 1440 minutes. The client application can be installed on multiple systems for use by multiple admins. The service must be installed on only one host system per Keeper Bridge instance. All client applications access the single instance of the service.

The Bridge Architecture Diagram for the Directory is below.

Use the link below to install the latest Keeper Bridge: Download Keeper Bridge

1. On the server, extract the zip file and then double click the KeeperEnterpriseBridge.msi file.

2. If applicable, Process the User Account Control window.

3. Select Next on the Welcome screen.

4. Choose I accept the agreement and select Next on the End-User License Agreement screen.

5. Accept the default installation location or browse for a new one and then select Next.

6. Click Install on the Ready to Install screen .

7. Select Finish to complete the installation.

The Tray Application and Windows Service can be installed on the follow operating systems:

1. Windows Server 2008 R2

2. Windows Server 2012

3. Windows Server 2012 R2

4. Windows Server 2016

5. Windows Server 2019

6. Windows Server 2022

The following data needs to be known in order to configure the Tray Application:

1. Domain or Forest name of the Directory.

2. An account used to bind the Keeper Bridge to the Directory (e.g. keeperbind@yourcompany.com ). This is a Directory account which requires at least read only access to the Directory domain. No other special privileges are needed.

3. A Security Group called Keeper Admins. Only users that are member of the Keeper Admins Security group will be permitted to login to the Tray application and configure the service. This group name can be changed and the Admin Security Group setting in the Keeper Admin Security configuration modified accordingly later. For a multi-domain forest create this group as a universal group so that users in this group are cached in the Global Catalog.

4. Ensure the Email Property (typically “mail” or “userPrincipalName”) in Directory Service Options is set to the correct value to pick up the user's Email address.

5. The Keeper Bridge needs access to the Directory on either ports 389 or 636 and to the Keeper Cloud on port 443. (keepersecurity.com or keepersecurity.eu depending on your data center location).

The Keeper Bridge allows businesses running Microsoft Active Directory or OpenLDAP to integrate Keeper password management software within their current systems, automatically managing the lifecycle of users and syncing any number of Nodes (organizational units), Users, Roles and Teams to Keeper. Keeper Bridge is designed to use the Lightweight Directory Access Protocol (LDAP and LDAPS) to communicate with LDAP based Directory Services for the purpose of onboarding and offboarding users to the Keeper platform.

The latest version of the Keeper Bridge can be downloaded from the Keeper Admin Console or the link below:

• Download Keeper Bridge

• View Release Notes

1. Before installing the executable on the server, the Admin console will need to be prepared to register the Keeper Bridge. The bridge cannot be registered to the Root Node (top level) of the organization tree structure, therefore a sub node will need to be created in order to register the bridge.

2. To create a new node underneath the Root Node click on the three dots and select the '+ Add Node' button.

3. Type in the name of the node and select create.

4. Select the node created in Step 3 above.

5. Select the Provisioning tab and select the + Add Method button.

6. Select the Active Directory or LDAP Sync radio button, then select the Next button.

7. Leave the LAN and WAN IP Address fields blank. The registration process of the bridge will automatically link to the admin console. Select the Save button.

8. The Keeper Bridge executable is now displayed and can be downloaded from the Provisioning tab and staged on the computer that the bridge will be installed on.

1. Run the Bridge Client. On Windows environments that are attached to a domain controller, Keeper Bridge will default to Active Directory authentication. Otherwise, the Keeper Bridge will assume generic LDAP authentication.

2. Log into the Bridge application: For LDAP:

• Enter the Server Address, the User Common Name (For the Admin) and the password. This is just an admin that is a member of the group. Once logged into the bridge, a different user can be used for binding.

• If using Secure Socket Layer (SSL port 636) for LDAP authentication ensure the SSL box is check. If not, ensure the check box is not checked to use standard LDAP authentication (port 389)

For Active Directory:

• Domain\User Name: Input the domain and AD\LDAP username of the user that is a member of the Keeper Admins group created in the prerequisites.

• Password: Input the password of the user.

• Use Global Catalog: In multi-domain forest configurations you should uncheck Use Global Catalog option otherwise keep it check to locate the username in the Global Catalog.

• SSL: If using Secure Socket Layer (SSL port 636) for LDAP authentication ensure the SSL box is check. If not, ensure the check box is not checked to use standard LDAP authentication (port 389)

• Settings: If the client is running on a different computer than the service, select Settings to specify the hostname and port of the Keeper Bridge Service. (The Setting button will be grayed out while app is connected to the service. To access settings stop the service).

3. Select Login. If you get a Login Failed message, it means either of the following:

• The username/password is not correct

• The user is not a member of the Keeper Admins Security Group

• The server does not support SSL and SSL is checked

• The username was not found in the Global Catalog. In multi-domain forest configurations if the Keeper Admins group is a Global Security Group the Use Global Catalog option should be unchecked or the Keeper Admins group can be made to be a Universal Security Group. In a multi-domain forest only users in Universal Groups are added to the Global Catalog.

Navigate to the Configuration tab of the Bridge client.

Publish Interval

Set the publish interval which will determine how often the Bridge service runs. The Bridge can automatically run as often as every 5 minutes and as little as once a day (1440 minutes). The default setting is set to 60 minutes.

Debug Logging

Adds additional debug logs to the Bridge Log. Helpful for troubleshooting with Keeper Support.

Automated Team Approval

If selected, Admin Login is required to generate team encryption keys and distribute team keys to users.

Delete Override

Flag which allows the Bridge to delete users and teams if they are not in the designated LDAP filter. By default, this is disabled, which prevents accidental deletion of users and teams in Keeper.

Admin Security Group

This is the group that the user needs to be a member of in order to login to the Keeper Bridge. By default, this is set to "Keeper Admins". You can configure this after initial login.

Always Use Global Catalog

This applies to Active Directory only. It means that Keeper Bridge will always query the GC in the forest.

Email Property

Before configuring the LDAP/AD queries, ensure that the Email Property is set correctly according to your organization's environment. This will ensure that the proper Keeper email maps to the organization email address. By default the property is set to 'userPrincipalName', however if that address doesn't correlate with the users actual email address the 'mail' attribute can be selected which will use the email populated in the users profile.

Saving Changes

Once the connection status is Online for the Keeper Service and Directory Service, configure the domains which will be exported to the Keeper Admin Console. Select on the LDAP/AD tab and then select either the Export Forest option or select individual domains.

To assist in the monitoring of events in AD Bridge during the testing and configuration phase, we recommend enabling the debug logging.

On the Configuration tab under Service Options check the Debug Logging selection.

On the main menu select Bridge Log.

The Bridge Log window will open.

When activity in the AD Bridge is activated from selecting Publish you will start to see the logging information.

Logs can be exported to a .csv file.

Other Logging

In addition to the Bridge Log in the application, all bridge logs can be viewed via Windows Event Viewer.

A variety of filters are available to enable admins to map specific objects from Active Directory to Nodes, Roles, Teams and Users which can then be Managed by the Keeper Admin Console. It is important to understand what the individual filters do and how to apply them. Each domain can configure a Top Level Node which defines the root object where all filters will be applied. Each domain enabled can then set a Node filter, a Role filter, a Team filter and a User filter. These filters are used to define the objects which will be exported to the Keeper Admin Console.

Top Level Node

• The Top Level Node can be set to a Distinguished Name path at any point in the Domain Tree. All applied filters will start from this path. As the name implies the DN Path defined becomes the Root of the organization in the Keeper Admin Console allowing the Admin to define which portion of the tree to export. If the whole domain tree is to be exported the Top Level Node should be left undefined.

Domain Filters - Node

• Nodes define the Tree in the Keeper Admin Console. This provides a familiar organizational structure when managing Roles, Teams and Users. The default filter defined for all domains will map all Organizational Units with the exception of the Domain Controllers OU. Using standard LDAP filter syntax the OUs map can be reduced or additional objects such as containers could be mapped if necessary.

Domain Filters - Role

• Roles provide the organization the ability to define enforcement policies for Users grouped in Roles. Having a large number of roles will require more maintenance than having only a few roles. The organization should plan how enforcements will be applied and how many Roles will be required to manage those enforcements. For this reason the default role filter is left blank.

• By default all Users will be mapped to a default role when they create their account. This default role is visible in the Admin Console and is not part of AD.

• See "Filter Examples" section for example Role filters if additional Roles are to be defined based on specific security groups. When defining a Role filter only the objects mapped which are present in the Nodes mapped by the Node Filter will be returned.

Domain Filters - User

• The primary function of the Keeper Bridge is to onboard users by sending them an invitation to join the Keeper account. The default filter returns all user objects which are present in the Nodes mapped by the Node filter. The AD Bridge exports users while also maintaining the Role and Team membership status. The AD Bridge will Lock a user's account when the User account has been disabled in AD. If an Active User is removed from the Role filter, the user account is locked, pending deletion by the Keeper Administrator.

Domain Filters - Team

• Teams provide the ability to share folders within the Keeper Vault to a collective group of individuals. By default the Team filter maps all security groups to Teams which are present in the Nodes mapped by the Node filter. When Teams are exported to the Admin Console they are not distributed to their home location in the Node tree as they are in Active Directory. All Teams are distributed to the Bridge node where the Bridge was created. This keeps all Teams within sharing scope of each other. Teams can then be manually distributed in the Admin Console so as to only allow sharing between certain teams.

Default Filters

• Default filters are provided which are expected to work for most organizations. Only the Role filter should need modification in a basic implementation. The Node filter maps Organizational Units to Nodes which are used by the Keeper Admin Console to provide a familiar tree structure.

Default Role Filter

The Default role filter is blank. In order to manage user enforcements users must be grouped into Roles. Each Role must be configured in the Keeper Admin Console to set enforcements for the specific User Role. It is suggested that some Security Groups in Active Directory are mapped as roles containing the users which will be joining the keeper organization. For maintenance reasons it is suggested that a select number of groups are used for this purpose. Mapping a large number of Role will require more configuration on the part of the keeper Admin. See custom filter for an example on how to add a role.

Default Team Filter

The default Team filter maps all security groups to Teams. This allows all members of the organization to share records between teams. The objectClass specifies group type object and (using an AND operator: &) any one of (using an OR operator: |) the group types Local, Global or Universal.

(&
    (objectclass=group)
    (|
            (grouptype=-2147483640)
            (grouptype=-2147483644)
            (grouptype=-2147483646)
    )
)

Default User Filter

The default user filter maps all user objects. In Active Directory some objects such as domain controllers also have an objectClass of User. To get only User objects an additional parameter is added, (with an AND operator: &) objectCategory of Person.

(&
    (objectclass=user)
    (objectCategory=Person)
)

Custom Filters - Examples

Each filter is defaulted so that most organizations can easily export their domain structure and map objects to Nodes, Roles, Teams and Users. In many cases filters will need to be customized to meet the needs of some organizations. If an Organizational Unit is not mapped as a Node, all objects in that OU path will not be exported even if the Filter for the object type maps the object.

Custom Node Filters

Example to map all Organizational Units as Nodes and excludes the specific OUs Office Users and Home Users. In the example below the OUs Office Users and Home Users and all objects within them will not be mapped even if other filters (Role, Team, User) target the objects within these OUs.

(&
    (objectclass=organizationalunit)
    (!name=Domain Controllers)
    (!ou=Office Users)
    (!ou=Home Users)
)

Example to map only specific Organizational Units as Nodes. Only Office Users and Home Users are mapped as Nodes. When including specific nodes the grouping with the OR (|) operator is necessary. In the example below only the OUs Home Users and Office Users and objects within them if targeted by other filters (Role, Team, User) will be exported.

(&
    (objectclass=organizationalunit)
    (!name=Domain Controllers)
    (|
         (ou=Office Users)
         (ou=Home Users)
    )
)

An important rule with Node Filtering is that if the OU is not exported, all objects targeted by other filters (Role, Team, User) within the OU will not be exported.

The bridge leverages standard LDAP Query language. Please refer to this web page for syntax: https://social.technet.microsoft.com/wiki/contents/articles/5392.active-directory-ldap-syntax-filters.aspx

Custom Nodes

The Nodes filter will allow the administrator to define what OU's are found or excluded. Only objects (OUs, Security Groups, Users) will be found in the Node filter if the LDAP query allows the OU that the object belongs within to be found in the domain tree. For example if all OU's are intended to configured as Nodes in Keeper admin console except for Domain Controllers (default setting), Finance, and Marketing then the LDAP query would look similar to:

(&    
  (objectclass=organizationalunit)        
  (!name=Domain Contollers)
  (!name=Finance)
  (!name=Marketing)   
)

Keep in mind, if any users, security groups, or other OU's reside inside the Finance or Marketing OU's (in this example) will not be found in the query.

Container vs OU

Another important aspect to configuring LDAP query statements, in order to meet the organizations objectives, is that some organizations do not have users residing in an OU. Instead users are placed in a container (Often titled as the User Container). While Microsoft does not recommend this as a best practice, many organizations are configured this way. When this happens an organization should consider converting the container to an OU. But if that is not feasible, then the Nodes filter should contain a statement to find the container vice an OU. In the below example the filter is configured to find both an OU named WestCoast and a container named Users.

(&
    (|
       (objectclass=organizationalunit)
       (objectclass=container)
       (!name=Domain Contollers)
    )
    (|
       (name=WestCoast)
       (cn=Users)
    )
)

(&
   (objectCategory=person)
   (objectClass=user)
   (primaryGroupID=513)
)

Custom Roles

Roles are required to apply enforcements on the Users in the Keeper organization. By default the filter is blank. Since the Active Directory names for groups are specific to the organization a default filter cannot be supplied. It will be necessary to decide which Security Groups in Active Directory will be used as roles. If all Security Groups are to be mapped as roles then copying the default Team filter is an easy way to export all groups as Roles. This means the Admin will need to manage each group as a Role and each Group as a Team. Maintenance on many Roles can be unnecessary and a time consuming for the keeper Admin. In this case only one or a few roles may be necessary. Example mapping all Security Groups as Roles and excluding the specific groups Local Admins and Regional Admins.

(&
    (objectclass=group)
    (!CN=Local Admins)
    (!CN=Regional Admins)
    (|
     (grouptype=-2147483640)
        (grouptype=-2147483644)
        (grouptype=-2147483646)
    )
)

Example mapping only specific Security Groups as Roles. This example groups Local Admins and Regional Admins with an OR (|) operator when including only specific groups.

(&
    (objectclass=group)
    (|
        (CN=Keeper Admins)
        (CN=Keeper Users)
    )
    (|
        (grouptype=-2147483640)
        (grouptype=-2147483644)
        (grouptype=-2147483646)
    )
)

An important rule with Role filtering is that if a group the user is in is not exported the user will still be exported, just not assigned to the Role.

Custom Team Filters

Teams are required to share folders and records to other Users in the keeper organization. By default the Team filter maps all security groups to Teams. Roles and Team filters act on security groups. It is valid that some groups would be mapped as both a Role and a Team. For instance an Organization may have LA Admins and LA Users mapped as Roles and then also have all security groups mapped as teams. This would mean LA Admin and LA Users are also a team. Since Roles also act as team please refer to roles for custom filtering examples.

Custom User Filters

The User filter maps User objects in Active Directory. If the user is a member of a security groups which is mapped as a role or team the Bridge will Invite the user and assign them to Roles and Teams of which they are a member based on the Active Directory group membership. Example mapping all Users in Active Directory except specific users. User52 and User58 are excluded by Common Name.

(&
    (objectclass=user)
    (objectCategory=Person)
    (!cn=User52)
    (!cn=User58)
)

Example mapping only specific Users in Active Directory. User52 and User58 are included exclusively by Common Name.

(&
    (objectclass=user)
    (objectCategory=Person)
    (|
        (cn=User52)
        (cn=User58)
    )
)

Example mapping all Users in Active Directory which are part of specific groups. Members of the RDP Users & Console Users group are included.

(&
    (objectclass=user)
    (objectCategory=Person)
    (|
    (memberOf=CN=RDP Users,OU=Office Users,DC=keeper,DC=local)
    (memberOf=CN=Console Users,OU=Office Users,DC=keeper,DC=local)
    )
)

Example mapping all Users in Active Directory except users which are part of a specific group. Members of the RDP Users and Office Admins group are excluded.

(&
    (objectclass=user)
    (objectCategory=Person)
    (!memberOf=CN=RDP Users,OU=EDH Office Users,DC=keeper,DC=local)
    (!memberOf=CN=Office Admins,OU=EDH Office Users,DC=keeper,DC=local)
)

Example mapping all Users in Active Directory except users which are part of a specific group or any group nested below the specific group. Members of groups RDP Users and Console Users are included as are members of all sub groups of these two groups due to use of the Active Directory OID (:1.2.840.113556.1.4.1941:).

(&
    (objectclass=user)
    (objectCategory=Person)
    (|
    (memberOf:1.2.840.113556.1.4.1941:=CN=RDP Users,OU=Office Users,DC=keeper,DC=local)
    (memberOf:1.2.840.113556.1.4.1941:=CN=Console Users,OU=Office Users,DC=keeper,DC=local)
    )
)

To map only users which are part of a specific OU, or not map users who are in a specific OU please refer to Node filter.

Preview Filter Results

The Preview option above the filter edit box will display the effective result of the filters defined showing the Tree defined by the Node filter and the objects to be exported by the other filters (user, role, team) within the tree structure.

Teams always display regardless of the tree node selected. Roles and Users display based on their location in the tree. A total count of objects is also displayed below the tree structure. Selecting a Node, Role, Team or User will display the associated Active Directory properties for the object selected. This information is helpful to determine properties and property values that can be used to filter for the object.

Publish Changes

Once your configuration is complete, select Save to to retain your current settings. Once all settings are complete use Publish button to push the changes live and activate the integration.

Using the Export Forest option

Includes all domains for which the user defined in LDAP Connection settings is a member. Selecting Export Forest will automatically select the root forest domain and enable that domain. All other domains will not be visible. When Export Forest is selected all domain object queries are done using Global Catalog. The Top Level Node is not editable when using this option.

Selecting Individual Domains for Export

Checking the box for any domain enables that domain for export, Top Level Node and Filters become editable for that domain. Selecting the row will display the top level node and filters for that domain.

Top Level Node

The Top Level Node filters is the DN path that will filter all objects from that path downwards. For example, a top level node might be:

After logging into the Bridge, the main client application will launch.

Configuration Steps:

• Configure the AD Connection or LDAP Connection

• Authenticate against the Keeper Cloud

• (Optional) perform Keeper Admin Login if automated team approvals are required.

On an LDAP service, several additional fields are required.

If automatic team approvals are preferred, encryption keys must be generated dynamically and shared to the appropriate team members. To perform this function, an Admin must login to the Keeper Bridge via the "Admin Login" button.

Once the Admin Login is complete, all status indicators show green.

As described in the previous section, the AD Bridge will provision new Users, Roles and Teams to the Keeper Admin Console based on the configuration and filters applied. The creation of NEW teams and the action of adding users to a team require an encryption key generation and key exchange that can occur within the Keeper Admin Console, Keeper Bridge or when a team member logs into Web Vault. In addition to the encryption aspect of this process, a level of security is in place to prevent the AD Bridge administrator from adding himself to a team which is privileged. The Bridge will Notify the Admin of Pending Team Approvals through the Bridge Notification feature. The Team notification will always sort to the top. This notification summarizes the Teams and Team User Assignments which are pending approval.

For this reason, the Keeper Admin Console contains an Approval Queue which allows the Administrator to quickly approve the creation of new teams and addition of users to teams. To view pending approvals, navigate to the Approval Queue on the right side of the Admin Console interface. There are two approval queues - Teams and Users.

Team Approval Queue

Teams that are dynamically created by the AD Bridge must be approved by the administrator in the Admin Console. Navigate to the Approval Queue and select the Teams option to display all pending team names. Approvals can be processed in one batch by selecting the bulk selection checkbox, or by selecting individual checkboxes. In each of the Disable columns, the admin can turn on the restrictions Disable record re-shares, Disable record edits and Disable viewing passwords.

User Approval Queue

Users that are invited to Keeper within teams must be approved by the administrator in the Admin Console. Navigate to the Approval Queue and select the Users option to display all pending user accounts.

Automating Team Approval

The Keeper Bridge can automate Team approval. This feature requires that the admin be logged into the bridge client locally with their keeper credential. The admin is added to every team in Keeper which they approve. This allows the bridge to use the admin credential to automate User Team assignment. The Admin credential is only retained in memory and is not stored for as this account will have all team keys. If the admin is not logged in during a Publish cycle the Team or Team User Assignment will be queued. A Notification will appear alerting the Admin to log in the Bridge client. Teams and Team users can be approved from the console ad-hoc if needed. It is best to use the same Admin account as is set up for bridge registration. An Admin can only approve teams for which they are members. It a team is approved by a different admin than is used for Bridge Registration and the Bridge admin is not specifically added to that team, the bridge will not be able to approve member to that team. To enable automated team approval selection the Option on the Options tab.

Team keys are also automatically distributed when a team member logs into the Web Vault or desktop application.

Team Notification

The Team notification will always sort to the top. This notification summarizes the Teams and Team User Assignments which are pending approval. The notification can be cleared manually, but will also clear itself when no Teams or Team Users require approval after the most recent Publish event has run. If Automated Team Approval is enabled this notification will only appear when the Admin login is not available or a Team User cannot be approved because the Registered Admin is not part of the Team.

Keeper Security provides end-user support through email, phone and live chat. To contact your business support team, please email business.support@keepersecurity.com.

If the automated Team Approval is selected in the Bridge Service Options, an Admin Login status will be displayed at the top of the page and the ability to provide the admin credentials will be at the bottom of the Connections page under the Keeper Connection section. Only the Admin which registered the Bridge can be used.

The Admin Login does not allow the user name to be changed. It is important that the Same admin be used across all team approvals. This ensured the admin is part of an approved team so that they have permission to assign users to the Team.

Two Factor Authentication will be prompted when enabled for the Admin account. The Admin login will be retained by the bridge service in volatile memory and used to assign users to their teams as required. The Admin remains logged in until the Keeper Bridge Service or the system to which it is installed is restarted. A new login is then required.