SecureLink UI Setup

SecureLink administrators can configure the Delinea plugin and credentials from the SecureLink UI.

Configuring PAM Server

To get started, first set up the PAM server in SecureLink.

  1. From the System Admin module, hover over the Settings option and select Plugin Settings.

  2. Confirm that the Delinea Plugin is in the Plugins list and is running. The version may not match the following example. If the status is not RUNNING click the Start link.

  3. Click New PAM Configuration below the Plugins list.

  4. The Delinea plugin requires the information.

    • Name (required) - name of the configuration

    • Description (required) - description of the configuration URL (required) - URL for the Delinea wsdl

    • In some cases, the SSL certificate needs to be uploaded

      • Export the PEM from Delinea

      • Upload using the Choose File button.

    • Plugin (required) - select the plugin from the dropdown list

    • Domain (not required) - AD Domain if API user is a domain account

    • Organization - leave blank

    • Password (required) - SecretServer user's password

    • SecretServer User Name (required) - API user account which will authenticate the plugin

  5. Click Test Configuration.

  6. Click Save to complete the plugin configuration.

Add PAM Credentials

To add PAM credentials to SecureLink, they must first be configured as external credentials. The following are configurations commonly used.

  1. From the System Admin module, hover over Credentials and select List Global Credentials.

  2. Click New External Credential Provider, above the External Credential Providers box.

  3. Fill in the following Credential Provider information:

    • Name (required) – provide a simple name for the external credential. This is what you will see in the dropdown when selecting the credential.

    • Description (Required) - description of the credential or access

    • Credential Category (optional) - future feature, for now leave this blank

    • PAM Server Configuration (required) - Select the PAM where the credential is stored

    • Restrict to specific Port Types (optional) - Select the type of service the credential can be applied to if desired

    • Machine - host name to search for a matching credential

    • Secret Name - the Secret Name to search for a matching credential

    • Username - username to search for a matching credential

      It is important to note that these are case-sensitive. For example, if you enter HVAC-server in SecureLink, entering hvac-server in Delinea will not match. It is best to copy and paste to avoid errors.

    • Matching on specific attributes – passes the specific Machine, Secret, or Username to Delinea to search for a matching secret. SecureLink values are to be checked against a secret by Delinea.

    • Using only the Secret Name is the best way to avoid mismatches when compared to using multiple fields.

    • Matching on the Host Name – passes only the server's hostname from SecureLink to Delinea to search for a matching secret. This will work for many different machines and applications with one external credential entry in SecureLink. This is used when each machine has a unique secret in Delinea and the secret matches the hostname in SecureLink.

      Additional Commonly Used Configurations

    • ${userId} for the Secret Name field above - searches for a secret that matches the logged in user's userid - this can be used for multiple users as it will query using the logged in userid. Vendor reps will have an email address for a userid, so the secret would be the vendor rep's email address.

    • ${applicationName} - In newer versions of SecureLink, a wildcard for the Application in SecureLink will pass the application name with the password request to match a secret. This would be used when a host, or multiple hosts, within an application use a single service account for all. In Delinea, the Secret Name would match the Application's name in SecureLink.

    Wildcards

    SecureLink can assist with configuring external credentials to find Secret Server accounts. For more detailed use-case questions, or help with wildcards, open a SecureLink support case for assistance.

    The following are the descriptions of the supported wildcards.

    Wildcard Description Sample Use Case
    ${userId} The login of the user accessing the service.

    Match a field in Secret Server to the SecureLink user's userid This could be matched to the Username or Secret Name in Secret Server Used when a unique login to the host is required for each vendor rep or internal user - such as devices with PCI data.

    Note: A vendor rep’s userid is the email address, which is commonly more than 20 characters, so use the Secret Name field in Secret Server to match the vendor rep's email address.

    ${userEmail} The email of the user accessing the service.

    Match the SecureLink user email address to the Secret Name field of an account in Secret Server (usernames are usually not emails in AD for example).

    In Secret Server, the Secret Name of an account would be set as the user's email address in SecureLink to create a match.

    ${userEmailUsername} The first half of the email of the user accessing the service (before the @ sign).

    Match the first half of the logged in user email address to the Name or User field of an account in the Secret Server.

    Used when a unique login to the host is required for each vendor rep or internal user - such as devices with PCI data.

    ${userDomain} . The email domain from the user accessing the service (for example, securelink.com)

    Match the user's email domain in SecureLink to the Secret Name field of an account in Secret Server.

    This is information is typically used to assign a service account that multiple reps would use on a host or hosts in one or multiple applications.

    ${vendorId} The user's vendor id  
    ${vendorName} The user's vendor name

    Match the vendor rep's vendor name (the company) in SecureLink to the Secret Name field of an account in Secret Server.

    This is typically used to assign a service account that multiple reps would use on a host or hosts in one or multiple applications.

    ${userDeptId} The user's department id $  
    ${userDeptName} The user's department name  
    ${applicationName} The name of the application

    Match the Application name in SecureLink to the Secret Name field of an account in Secret Server.

    This is typically used to assign a service account that multiple reps would use on a host or hosts in one application.

    Note: This configuration is used in the example above

    ${applicationDeptId The applications department id  
    ${hostName} The hostname Match the hostname in SecureLink to the Host field of an account in Secret Server. This is typically used to assign a single account for a single host.
    ${hostDescription} The host's description

    Match the host description in SecureLink to the Secret Name field of an account in Secret Server.

    This is typically used to assign a single account for a single host or multiple hosts as long as the descriptions are the same.

    ${serviceName} The service name Match the service name to the Secret Name
    ${serviceDescription} The service description Match the service description to the Secret Name
    ${portType} The service port type  

    For more detailed use-case questions, open a SecureLink support case for assistance.

  4. Click Save to complete.

Attaching the Credential to a Service

When editing a service, external credentials can now be added as an External Credential from the Credential Type dropdown.

Caveats

This solution is a basic integration using a single authenticated API user to the Delinea PAM API. SecureLink does not store passwords passed from Delinea via the API.