Delinea Secret Server
Important
You must purchase this integration separately for both your Remote Support software and your Delinea solution. For more information, contact BeyondTrust's Sales team.
BeyondTrust's Remote Supportplugin integration to Delinea Secret Server enables automatic password injection to authorized systems through encrypted BeyondTrust connections, removing the need to share and expose credentials to privileged accounts. In addition to machine-specific credentials, the integration also has the ability to retrieve domain credentials that are not machine-specific, giving domain admins and other privileged users access to those credentials for use on endpoints on a domain.
The integration between BeyondTrust and Delinea enables:
- One-click password injection and session spawning
- Credentials never exposed to authorized users of BeyondTrust
- Access to systems on or off the network with no preconfigured VPN or other routing in place
- Passwords always stored securely in Delinea Secret Server
The BeyondTrust Endpoint Credential Manager (ECM) enables the communication between Delinea Secret Server and BeyondTrust Remote Support. The ECM is deployed to a hardened Windows Server inside the firewall, typically in the same network as Secret Server. Once the ECM is deployed, BeyondTrust users see a list of administrator-defined credentials for the endpoints they are authorized to access. A set of these credentials can be selected when challenged with a login screen during a Remote Support session and the user is automatically logged in, having never seen the username/password combination.
Delinea Secret Server handles all elements of securing and managing the passwords, so policies that require the password to be rotated after use are supported. BeyondTrust Remote Support handles creating and managing access to the endpoint and then recording the session and controlling the level of access granted to the user, including what the user can see and do on that endpoint.
Prerequisites
To complete this integration, please ensure that you have the necessary software installed and configured as indicated in this guide, accounting for any network considerations. The integration is provided in the form of a plugin (ZIP archive containing the necessary DLL files and other supporting files) for use within BeyondTrust's Endpoint Credential Manager (ECM).
Applicable versions
- BeyondTrust Remote Support: 15.x and later
- Delinea Secret Server: 8.9.0 and later
Network considerations
The following network communication channels must be open for the integration to work properly.
Outbound From | Inbound To | TCP Port # | Purpose |
---|---|---|---|
ECM Server | BeyondTrust Appliance B Series | 443 | ECM calls to the BeyondTrust API. |
ECM Server | Delinea Secret Server | 443 | ECM calls to Secret Server web services. |
Note
The ECM can be obtained only with a paid BeyondTrust integration service.
Configure Delinea Secret Server
Sign in to Secret Server as an administrative user.
Create API account
- Under Admin > Users, click Create New to create a local user for API calls.
- Enable Local User Password Expiration
- If the API account is the only local account, we recommend you disable local user password expiration so the ECM plugin integration does not break each time the password expires or changes. This setting is found under Admin > Configuration > Local User Passwords.
- Under Admin > Roles, edit the role in which the API account is a member (typically the User role). Click the role name in the list to view it, and then click the Edit button at the bottom of the page below the Permissions list.
- Ensure that the permission Web Services Impersonate (sometimes listed as just Impersonate) is added to the Permissions Assigned list.
- Click Save to update the role permissions.
Enable web services
- Under Admin > Configuration, select the General tab.
- In the Application Settings section, ensure the Enable Webservices setting is set to Yes.
- If not already enabled, click Edit at the bottom of the page, check the box to enable the services, and save the settings.
Configure Remote Support
Several configuration changes are necessary on the BeyondTrust Appliance B Series to integrate with Secret Server.
All of the steps in this section take place in the BeyondTrust /login administrative interface. Access your BeyondTrust interface by going to the hostname of your BeyondTrust Appliance B Series followed by /login, for example: https://support.example.com/login.
Create an OAuth API account
The Delinea API account is used from within Delinea to make Remote Support Command API calls to Remote Support.
- In /login, navigate to Management > API Configuration.
- Click Add.
- Check Enabled.
- Enter a name for the account.
- OAuth Client ID and OAuth Client Secret is used during the OAuth configuration step in Delinea.
- Set the following Permissions:
- Command API: Full Access.
- Reporting API: Allow Access to Support Session Reports and Recordings.
- Endpoint Credential Manager API: Allow Access.
- If ECM groups are enabled on the site, select which ECM Group to use. ECMs that are not associated with a group come under Default.
Note
The ECM Group feature is only present if enabled when your site is built. If it is not present, please contact your site administrator.
- Click Save at the top of the page to create the account.
Allow ECM connections
- Go to /login > Management > API Configuration.
- Add or edit an API account.
- Under Permissions, check Allow Access for Endpoint Credential Manager API.
Configure Delinea plugin
Install the Endpoint Credential Manager
The Endpoint Credential Manager (ECM) must be installed on a system with the following requirements:
System requirements
- Windows Vista or newer, 64-bit only
- .NET 4.5 or newer
- Processor: 2GHz or faster
- Memory: 2GB or greater
- Available Disk Space: 80GB or greater
-
To begin, download the BeyondTrust Endpoint Credential Manager (ECM) from BeyondTrust Technical 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.
Note
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.
Note
- To ensure optimal up-time, administrators can install up to five ECMs on different Windows machines to communicate with the same site on the BeyondTrust Appliance B Series. A list of the ECMs connected to the B Series Appliance site can be found at /login > Status > Information > ECM Clients.
- When multiple ECMs are connected to a BeyondTrust site, the B Series Appliance routes requests to the ECM that has been connected to the B Series 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:
Setting Name | Description | Notes | Required |
---|---|---|---|
Endpoint URL | The full URL to the Secret Server web services | e.g., https:///SecretServer/webservices/SSWebservice.asmx | Yes |
API User | Username of the API account created in Secret Server | Yes | |
API Password | Password of the above user | Yes | |
API Domain | Domain of the API account created in Secret Server | Used only if the API account is not a local user in Secret Server | No |
API Organization | Organization of the API account created in Secret Server | Not typically used for such accounts | No |
Include domain credentials for | When checked, in addition to retrieving machine-specific credentials for the select endpoint, it also retrieves domain credentials where the domain field (configured below) matches one of the configured domains | This field can contain multiple domains separated with commas | No |
Domain Field | API web service field containing domain names | The default value of Domain should be left unless an organization is using another field to store this information on domain secrets | Yes |
Machine Field | API web service field containing machine names | The default value of Machine should be left unless an organization is using another field to store this information on machine-specific secrets | Yes |
Default Domain for Local BeyondTrust Users | When a value is supplied, the plugin initially attempts to retrieve credentials for the user with the username from BeyondTrust and the configured default domain | This setting is necessary if some or all BeyondTrust users are local users but the corresponding accounts in Secret Server are domain accounts with the same username portion | No |
Enable fall-back to local account if domain account not found | When checked, the plugin first attempts to retrieve credentials for the user as a domain user and then, if no match is found, makes a second attempt without the domain | This setting is necessary if some or all BeyondTrust users are domain users but the corresponding accounts in Secret Server are domain accounts with the same username portion | No |
Include default organization | If enabled, the supplied organization is included when querying for a matching Secret Server user | No |
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 B Series Appliance to the ECM. This means you can test the settings without having the ECM service running or connected to the B Series Appliance.
Note
While the test does simulate a request from the B Series Appliance to the ECM, it does not in any way test configuration or connectivity to the B Series Appliance. It is used only for configuration, connectivity, permissions, etc., related to the password vault system.
Console user information
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 might be username-only ( joe.user), which is the most common format, or it might include other information and in other formats, such as down-level domain info (ACME\joe.user) or email / UPN ([email protected]).
- 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.
Jump Item information
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.
Note
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.
Test results
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 might not be anticipated, so the information is displayed in a more raw form.
Note
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 is 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 displays the result of the attempt to retrieve the credential, but for security reasons no password is ever displayed in clear text.
Note
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.
Important
- Access to individual Secret Server user secrets is handled by a delegated trust feature built into Secret Server. This means that a user can grant access to their secrets to an API user. The first time a user attempts to access an endpoint via the BeyondTrust representative console, a request for this access is generated, and an email is sent to the user. The user can either approve the request, granting API user access to their credentials for future sessions, or they can deny the request. This access can be revoked by the user at any time. If for some reason the email is not received, the page to manage this access is available to all Secret Server users under Tools > Manage Applications.
- The Configurator.log should indicate that authentication was successful but that permission to access that user's secrets is pending approval.
Updated 5 days ago