Configure the Endpoint Credential Manager Plugin for Integration with Remote Support
You must purchase this integration separately from both your BeyondTrust Remote Support and Password Safe solutions. For more information, contact BeyondTrust sales.
The Endpoint Credential Manager (ECM) must be installed on a system with the following requirements:
- Windows Vista or newer, 64-bit only
- .NET 4.5 or newer
- Processor: 2 GHz or faster
- Memory: 2 GB or greater
- Available Disk Space: 80 GB or greater
Install the Endpoint Credential Manager
- To begin, download the BeyondTrust Endpoint Credential Manager (ECM) from BeyondTrust Support
- Start the BeyondTrust Endpoint Credential Manager Setup Wizard.
- Agree to the EULA terms and conditions. Mark the checkbox if you agree, and then click Install.
If you need to modify the ECM installation path, click the Options button to customize the installation location.
You are not allowed to proceed with the installation unless you agree to the EULA.
- Click Next on the Welcome screen.
- Choose a location for the credential manager, and then click Next.
- On the next screen, you can begin the installation or review any previous step.
- Click Install when you are ready to begin.
- The installation takes a few moments. On the Completed screen, click Finish.
To ensure optimal up-time, administrators can install up to five ECMs on different Windows machines to communicate with the same site on the Secure Remote Access Appliance. A list of the ECMs connected to the appliance site can be found at /login > Status > Information > ECM Clients.
When multiple ECMs are connected to a BeyondTrust site, the Secure Remote Access Appliance routes requests to the ECM that has been connected to the appliance the longest.
Install and Configure the Plugin
- Once the BeyondTrust ECM is installed, extract and copy the plugin files to the installation directory (typically C:\Program Files\Bomgar \ECM).
- Run the ECM Configurator to install the plugin.
- The Configurator should automatically detect the plugin and load it. If so, skip to step 4 below. Otherwise, follow these steps:
- First, ensure that the DLL is not blocked. Right-click on the DLL and select Properties.
- On the General tab, look at the bottom of the pane. If there is a Security section with an Unblock button, click the button.
- Repeat these steps for any other DLLs packaged with the plugin.
- In the Configurator, click the Choose Plugin button and browse to the location of the plugin DLL.
- Click the gear icon in the Configurator window to configure plugin settings.
- The following settings are available:
The full URL to the PS SDK Web Services.
API Registration Key
The Key for the API Registration created for the integration.
The username for the account created to allow automated approval of requests for credentials via the integration.
|Release Duration||The number of minutes for which the generated release request is valid and can be used to retrieve the credential.||Default is 360 minutes.|
Test Plugin Settings
You can test the settings specific to Password Safe directly from the plugin configuration screen using the Test Settings button.
The test functionality allows you to test new or updated configuration without the need to go through the Representative Console or to save the changes first. The form collects information to simulate a request from the Secure Remote Access Appliance to the ECM. Naturally, this means you can test the settings without having the ECM service running or connected to the appliance.
While the test does simulate a request from the appliance to the ECM, it does not in any way test configuration or connectivity to the appliance. It is used only for configuration, connectivity, permissions, etc., related to the password vault system.
The fields collected in this section simulate the information that is sent to the ECM about the user logged into the console and requesting credentials from the password vault.
- SRA Console Username: The username of the console user. Depending on the type of Security Provider and how it is configured, this could be username-only ( joe.user), which is the most common format, or it could include other information and in other formats, such as down-level domain info (ACME\joe.user) or email / UPN (firstname.lastname@example.org).
- Distinguished Name: For LDAP Security Providers, the provider often populates the Distinguished Name of the user in addition to the username. The Distinguished Name includes domain information which is extracted by the integration and used to help identify the matching account in the password vault. An example DN is: uid=joe.user,ou=HelpDesk,dc=acme-inc,dc=com.
The fields collected in this section simulate the information that is sent to the ECM about the endpoint or Jump Item to which the console user may connect.
- Jump Item Type: Because different Jump Items result in different pieces of information being sent to the ECM, as well as how the ECM may query the password vault for applicable credentials, it is important to identify the type of Jump Item you wish to simulate as part of the test process.
The Jump Client type should be used to simulate Remote Jump and Local Jump items as well.
- Hostname / IP Address: For most types of Jump Items, the primary piece of information used to find credentials in the password vault is the endpoint's hostname or IP address.
- Website URL: For Web Jump items, rather than a hostname, the ECM is provided with the URL to which the item points. This field validates that the supplied string appears to be an actual URL.
- Additional IP Address: For Jump Client items, in addition to the machine's name, the installed client also makes the machine's public and private IP addresses available to the ECM. Some integrations use this information to query for credentials in addition to or even instead of those which match the hostname value.
- Application Name: For testing credential retrieval for injection into an application via an RDP + SecureApp item, the ECM is provided with both a value to identify the endpoint (Hostname / IP Address) and one to identify the specific application. The required value for Application Name may vary across integrations. The integration specific installation guides should contain more information on possible values.
If the test fails for any reason, error information is displayed to assist in diagnosing the cause of the failure. In most cases these errors are handled and then assigned a type, such as an authentication-related error, and then displayed with the inputs as well as any specific error messages. However, there may still be some instances where a particular error could not be anticipated, so the information is displayed in a more raw form.
It's important to note that, either way, the same information is included in the Configurator.log, along with more detail as to exactly what point in the execution the failure occurred.
It's possible that the test succeeds in that it doesn't encounter any errors and yet it doesn't return any credentials. Because this is a perfectly valid result, it is not treated as an error.
In either case, if the test succeeds but the results do not match what was expected, it's important to make note of the inputs which led to those results and verify permissions and access to credentials within the password vault.
When the search does yield one or more matching credentials, the test does allow for one additional level of verification by allowing a tester to retrieve a specific credential as would occur if it were selected for injection within the console. The tester simply clicks the Retrieve Credential button in the right column of the results list, and the integration then attempts to retrieve that credential on behalf of the supplied user.
The test will display the result of the attempt to retrieve the credential, but for security reasons no password is ever displayed in clear text.
Only credentials are retrieved; no actual passwords are retrieved or displayed. The settings used for the test are the ones currently entered on the screen, not necessarily what is saved.