Configure the LDAP Security Provider Settings

Configure LDAP Server

Name

This field displays the name you assigned to this configuration.

Service Type

This field displays the service type you selected on the previous page.

Server Type

This field displays the type of server for which you are configuring this connection.

Keep Display Name Synchronized with Remote System

If this option is selected, the display names of users authenticating against this security provider will always match the display names pulled from the directory store. If this option is deselected, display names can be edited locally on the Bomgar Appliance.

LDAP Server Host Address

Specify the hostname or IP address of the server that houses your external directory store.

Note: If you will be using LDAP w/TLS or LDAPS, the hostname must match the hostname used in your LDAP server's public SSL certificate's Subject Name or the DNS component of its Alternate Subject Name.

LDAP Server Port

Specify the port for your LDAP server. This is typically port 389 for LDAP or port 636 for LDAPS. Bomgar also supports global catalog over port 3268 for LDAP or 3269 for LDAPS.

Security Mode

Select the type of encryption to use when communicating with the LDAP server. If you select Use LDAPS or Use LDAP w/TLS, you must upload the LDAP server's Root SSL Certificate in the CA Public Key field.

Note: For security purposes, LDAP w/TLS or LDAPS is recommended.

CA Public Key

To encrypt this connection, you must upload the Root SSL Certificate used by your LDAP server. This is necessary to ensure the validity of the server and the security of the data. The Root Certificate must be in PEM format.

Note: If the LDAP server's public SSL certificate's Subject Name or the DNS component of its Alternate Subject Name does not match the value in the LDAP Server Host Address field, the provider will be treated as unreachable. You can, however, use a wildcard certificate to certify multiple subdomains of the same site. For example, a certificate for *.example.com would certify both support.example.com and remote.example.com.

Configure LDAP Server

Use Anonymous Binding

If your server supports anonymous binds, you can choose to continue without specifying a username or password.

Note: Anonymous binding is considered insecure and is disabled by default on most LDAP servers.

Bind Username

Specify a username with which your Bomgar Appliance can bind to and search the LDAP directory store. This account must have permission to read the attributes you will specify in the User Query for all users that you want to be able to authenticate against this LDAP server. It is not recommended to use an administrative account. Using a standard user account is usually sufficient and is more secure. It may be necessary to prefix the username with the domain (e.g., exampleDomain\john).

Note: By default, Active Directory requires that you specify a bind username and password. This user account must have permission to read other users' attributes. If you are using Active Directory and do not already have a bind account set up, create a unique user account for use with the Bomgar Appliance and grant the user this read privilege. For details on how to grant this privilege, see Configuration Specific to Active Directory on Windows 2000/2003.

Bind Password

Specify the password to use with the bind username entered above.

User Search Base

Determine the level in your directory hierarchy, specified by a distinguished name, at which the Bomgar Appliance should begin searching for users. Depending on the size of your directory store and the users who require Bomgar accounts, you may improve performance by designating the specific organizational unit within your directory store that requires access. If you are not sure or if users span multiple organizational units, you may want to specify the root distinguished name of your directory store.

Example Explanation
dc=example,dc=local This will search the entire directory structure of the company domain.
ou=users,dc=example,dc=local This will search just the users organizational unit within the directory hierarchy, ignoring other organizational units such as computers or groups.
ou=Atlanta,dc=example,dc=local This will search users and groups with a location of Atlanta.

The Appliance Can Communicate Directly with This Server

Indicate whether the Bomgar Appliance can attempt direct communication with the LDAP server (checked) or whether you will be using a connection agent (unchecked).

If you are using an LDAP server in the same LAN as your Bomgar Appliance, the two systems may be able to communicate directly, and you will not need to install a connection agent. However, if your LDAP server and Bomgar Appliance are on different networks or are separated by a firewall, you will need to install a connection agent to enable communication.

Connection Agent Password

If your Bomgar Appliance cannot communicate directly with your LDAP server, you will need to install a connection agent at the end of this server configuration. Create a Connection Agent Password for use in the installation process.

Configure LDAP Server

User Query

Specify the query information that the Bomgar Appliance should use to locate an LDAP user when the user attempts to log in. The User Query field accepts a standard LDAP query (RFC 2254 – String Representation of LDAP Search Filters). You can modify the query string to customize how your users log in and what methods of usernames are accepted. To specify the value within the string that should act as the username, replace that value with %s.

Example Explanation
(&(sAMAccountName=%s)(|(objectClass=user)↵
(objectClass=person)))
When jsmith logs into his account, the Bomgar Appliance will search the LDAP server for an object where the sAMAccountName is equal to jsmith.
(&(|(sAMAccountName=%s)(specialVendorAttribute=%s))↵
(|objectClass=person)(objectClass=user))
This will search for an object where either the sAMAccountName or specialVendorAttribute contains jsmith and has an object class of either person or user.

User Object Classes

Specify valid object classes for a user within your directory store. Only users who posses one or more of these object classes will be permitted to authenticate. These object classes are also used with the next two fields (User Object Unique ID and User Object Display Name) to indicate to your Bomgar Appliance the schema the LDAP server uses to identify users. You can enter multiple object classes, one per line.

Example Explanation
user Users must have an object class of user.
user

person
Users must have an object class of user or person.

Configure LDAP Server

User Object Unique ID

This field requests a unique identifier for the object. While the distinguished name can serve as this ID, a user's distinguished name may change frequently over the life of the user, such as with a name or location change or with the renaming of the LDAP store. Therefore, most LDAP servers incorporate some field that is unique per object and does not change for the lifetime of the user. If you do use the distinguished name as the unique ID and a user's distinguished name changes, that user will be seen as a new user, and any changes made specifically to the individual's Bomgar user account will not be carried over to the new user. If your LDAP server does not incorporate a unique identifier, use a field that is least likely to have an identical entry for another user.

The syntax for this field is in the form of [object]:[attribute].

[object] Specifies the user object class, which must be in the form of a descriptor or the wildcard *, indicating all valid user classes.
[attribute] Specifies the attribute that contains the unique user ID. This must be in the form of a descriptor or the special value ?, indicating the distinguished name of that user object.

 

Example Explanation
*:objectGUID All classes have an objectGUID attribute which is a unique identifier.
user:userGUID

person:personGUID
A user object has a userGUID attribute, a person object has a personGUID attribute, and both are unique.
user:userGUID

*:objectGUID
A user object has a userGUID attribute which should be used, but all other classes have an objectGUID attribute.
user:?

person:objectGUID
A user object has no unique identifier other than its distinguished name, but the person class has an objectGUID attribute which should be used.

You can mix and match specific definitions, entering each definision on a separate line. However, only one *:[attribute] definition is supported. If multiple wildcard definitions are entered, only the last one will be used.

Configure LDAP Server

User Object Display Name

These values determines which fields should be used as the user's private and public display names. The syntax for these fields is in the form of [object]:[attribute].

[object] Specifies the user object class, which must be in the form of a descriptor or the wildcard *, indicating all valid user classes.
[attribute] Specifies the attribute that contains the desired display name. This must be in the form of either a descriptor or the special value ? or !. The special value ? uses the fully qualified distinguished name, while ! returns the value of the leftmost element of the distinguished name.

 

Example Explanation
*:displayName All classes have a displayName attribute.
user:! A user object should use the leftmost element of its distinguished name.
user:displayName
person:fullName
A user object has a displayName attribute, and a person object has a fullName attribute.
*:! For all classes, the leftmost element of the distinguished name should be used.
user:displayName
*:!
A user has a displayName attribute which should be used, but all other classes should use the value of the leftmost element of the distinguished name.
user:?
*:!
A user object should use the full distinguished name, but all other classes should use the value of the leftmost element of the distinguished name.

Display Query

The display query affects how results are displayed when browsing via group policies or Embassies. This filters results so that only certain results display in the member selection dropdown when adding members to a group policy or Embassy.

Example Explanation
(objectClass=*) Default. Displays all objects returned by a query.
(|(objectClass=user)(obectClass=organizationUnit)) Displays all user or organizationUnit object classes, filtering out any other objects.

Configure LDAP Server

Default Policy

Each user who authenticates against an external server must be a member of at least one group policy in order to authenticate to your Bomgar Appliance, logging into either the /login interface or the representative console. You can select a default group policy to apply to all users allowed to authenticate against the configured server.

Note that if a default policy is defined, then any allowed user who authenticates against this server will potentially have access at the level of this default policy. Therefore, it is recommended that you set the default to a policy with minimum privileges to prevent users from gaining permissions that you do not wish them to have.

Note: If a user is in a default group policy and is then specifically added to another group policy, the settings for the specific policy will always take precedence over the settings for the default, even if the specific policy is a lower priority than the default, and even if the default policy's settings are set to disallow override.

Click Add Server to save this security provider configuration.