Skip to main content
Version: v45

Setting Up Hosts

This section describes manually setting up hosts and connection targets on them. For information about importing hosts automatically using cloud host tags or the host-deployment script, see Script-Based Certificate-Authentication Setup.

You can add connection targets to PrivX by adding hosts. To do this, go to Administration → Hosts and click Add Host. PrivX host entries are used for specifying, among other things:

To add a connection target, in Administration → Hosts, click Add Host and configure the following host settings:

  • Basic host information: Specify the host name and addresses.
  • Services: Specify the services available for accessing the host, such as SSH, RDP, and Web.
  • Accounts: Specify which roles can access the host and which target accounts they can use.

Connection targets offer the following benefits:

  • To see and connect to known targets, PrivX users can go to the Connections page and select Search from known hosts. PrivX users only see the connection targets they are authorized to access.
  • Connection targets support authentication methods other than user-provided passwords. For more information on the configurations required for additional authentication methods, see Supported Authentication Methods.
  • Administrators can audit connections and view recordings when auditing is enabled for the host.
  • PrivX can periodically check the status of known targets and indicate when targets are unreachable. Settings related to status checks are under the Service health check section on Administration → Settings→Host Store.
note

All known targets must have unique machine IDs. If you need to add cloned machines to PrivX, make sure that each machine has a unique ID and regenerate it if necessary.

Proxying Connections​

Use PrivX Extenders to relay connections to target hosts that PrivX Servers cannot access directly. To proxy connections to the host through Extenders, in the host settings, add either of the following to the host Address:

  • Extender name: Connections to the host are proxied through the named Extender.
  • Routing prefix: Connections to the host are proxied through an Extender HA cluster.

The following examples show the Address syntax for IPv4 and IPv6:

exampleextender/192.0.2.100
exampleextender/2001:DB8::64

Save your host changes. PrivX proxies subsequent connections through the specified PrivX Extender. For more information about PrivX-Extender requirements and setup, see PrivX Extender and Setting up PrivX components respectively.

SSH Targets​

Use the PrivX host-deployment script to add SSH targets automatically. The script also enables certificate-based authentication. For more information about using the host-deployment script, see Script-Based Certificate-Authentication Setup.

To allow connections to SSH hosts, add a host entry with the following considerations:

  1. Add a Service with the type SSH and specify the address and the port of the SSH server on the host.

    • If the Trust on first use option is disabled, add the SSH host keys to the service. In this case regular PrivX users can connect only if the host key matches one of the provided values. PrivX administrators can establish connections even if the host key is missing or incorrect.

    • To also allow non-administrator users to accept changed host keys, enable Trust on changed host keys. This can be useful in automated environments where host keys change frequently or unpredictably, and are not used for target verification.

      caution

      Allowing users to bypass SSH server validation with enabled Trust on changed host keys increases the risk of man-in-the-middle attacks. Enable this setting only in secure networks that verify hosts by other means.

  2. Add Accounts specifying which PrivX roles may access the host, and which target accounts they are given access as. The access options of the accounts can be limited under Allowed Service Options. By default, all Allowed Service Options options are enabled. The default values can be changed in Administration → Settings, under the Hoststore category.

RDP Targets​

To allow connections to RDP hosts, add a host entry with the following considerations:

  • Add a Service with the type RDP, specifying the address and the port of the RDP server on the host.
  • Add Accounts specifying which PrivX roles can access the host and which target accounts they can use.
  • [Optional] Under Allowed Service Options, restrict the features available to the accounts. PrivX enables all service options by default. You can change the default values in Administration → Settings → Host Store.
  • [Optional] Under Windows application restrictions, specify the applications that users can access. Configure the target Windows host to allow the specified applications over RDP.
  • [Optional] Under Additional Settings, enable legacy cipher support or configure the minimum and maximum TLS versions.
  • [Optional] For browser-based RDP connections, the Enable RDPGFX setting can improve rendering performance but increases memory consumption and session-recording storage requirements. For configuration instructions and resource considerations, see Planning Resources for RDPGFX Connections.

For configurations specific to RDS targets, see RDS Connections.

Warning Users About Ongoing RDP Sessions​

When multiple users share an RDP account, starting a new connection might terminate an ongoing session. PrivX can warn users about the ongoing session and allow them to abort or continue the new connection attempt.

To enable the warning:

  1. In Administration → Hosts, select the target host.
  2. Under Accounts, select Notify about ongoing session to enable the ongoing-session warning for the target account.
  3. Save the host.

When a user starts an RDP connection with this account, PrivX checks for an established RDP connection that uses the same account and target address. If PrivX detects an ongoing connection, it prompts the user to choose whether to continue:

  • If the user does not continue, PrivX aborts the new connection attempt.
  • If the user continues, PrivX sets up the new connection normally. Depending on the RDP environment, if the new connection is established, the target RDP environment might terminate the ongoing session.

PrivX does not enforce a single RDP session for the account. PrivX detects established sessions but it does not detect other connections that are still being established. If multiple users choose to continue, PrivX attempts to establish all their connections. The final outcome depends on connection timing and the configuration of the target RDP environment.

This setting applies only to RDP connections and is designed primarily for explicit accounts shared by multiple users. Directory accounts typically map each PrivX user to a personal target account, so the setting is generally not useful for directory accounts.

Limitations of RDP Ongoing-Session Detection​

  • PrivX compares usernames and target addresses exactly as specified. It does not recognize different formats of the same username, such as user@example.com and DOMAIN\user, as the same account.
  • PrivX also does not recognize an FQDN and its corresponding IP address as the same target. For example, PrivX treats connections to example.com and its IP address as connections to different targets.

Web Targets​

You can use PrivX to connect to websites. To allow connections to websites, add a host entry with the following considerations:

  • Add a Service with the type Web, specifying the address of the website.

  • Since connections to web targets are provided through a PrivX Web Proxy, provide the address in proxy format. For example (replace exampleproxy with your Web access gateway name, and https://www.example.com/ with the address of the website): exampleproxy/https://www.example.com/

    Replace the example values as follows:

    • exampleproxy: The Name or the Routing prefix of the web-access gateway(s) used for proxying the connection.
    • https://www.example.com/: The address of the website.

  • If you want PrivX to automatically fill in login credentials for the website, also provide the following Additional settings:

    • Login-request address: The verified address of the login request. For example, in form logins this may be the URL of the webpage plus the URL specified by the action attribute of the form. Recommended for improved security.

    • Password property: The verified id of the password field in the login form. Recommended for improved security.

    • Login-page address: The login-page address. Only needed if the login page is not under the Address of this web service. For example, while you could have an AWS service with the Address:

      exampleproxy/https://example.signin.aws.amazon.com/console

      That website may redirect you to a different address for login:

      https://us-east-1.signin.aws.amazon.com

    • Authentication type: Set to Automatic for most websites, such as websites using forms for authentication. Set to Basic for websites using the Basic HTTP Authentication Scheme (defined in RFC 7617).

    • Username-field name: The name of the username field in the login form. Only required if PrivX is unable to automatically detect this field.

    • Password-field name: The name of the password field in the login form. Only required if PrivX is unable to automatically detect this field.

  • Add Accounts specifying which PrivX roles may access the website. If you want PrivX to automatically fill in login credentials for the website, also provide Usernames and Passwords in the account mappings. The access options of the accounts can be limited under the Allowed Service Options. By default all service options are enabled. The default values can be edited on Administration → Settings → Host Store.

    note

    PrivX automatically fills in the configured login credentials but does not log in to the web service. Users must select Login to complete the login. By default, PrivX allows HTTPS connections that use TLS 1.2 or later. TLS 1.3 Carrier connections require the PrivX Web Proxy host to use a RHEL 8-compatible environment with OpenSSL 1.1.1 or later.

    For HTTPS targets, by default PrivX only allows connections using TLSv1.2 and later. To use TLS 1.3 with Carrier HTTPS connections, your PrivX web proxy host needs to be using RHEL8 compatible environment with OpenSSL 1.1.1 or later.

    To prevent access to websites other than the configured web targets, you can add additional access rules. For instructions, see Access Restrictions for Web Connections.

  • If your web service supports OIDC authentication, you can configure it to use PrivX as an OIDC identity provider. This configuration does not require credentials in the web-target account mapping.

    • For instructions on how to configure PrivX as an OIDC IDP, see OIDC Identity Providers
    • To enable OIDC for a web target, set Account Type to Directory. Make sure that the unix_username attribute is defined in the PrivX user details. Otherwise, the web target is not visible in the PrivX Web UI.
    • To route all OIDC logins through PrivX Carrier for auditing, enable Only allow login attempts through Carrier on the OIDC identity provider configuration page.

VNC Targets​

PrivX tunnels VNC file transfers over SFTP through the specified SSH service.

If the VNC service does not have a corresponding SSH service, users with the connections-manual permission can still establish VNC connections. PrivX prompts these users to accept host key and to enter the SSH password. After successful password authentication, the VNC connection proceeds normally.

To allow connections through VNC, add a host entry with the following considerations:

  1. Add an SSH service to tunnel VNC connections, as described in SSH Targets.

  2. Add a Service of type VNC and specify the address and the port of the VNC server on the host. Make sure that SSH tunnel port under Additional settings matches that of the SSH service.

  3. [Optional] For the plain-text VNC connections, in Administration → Settings → Global → RDP Common, enable Allow access to hosts using plain text VNC.

    caution

    Plain-text VNC connections are not secure. Protect the traffic between PrivX and the target host by other means.

Database Targets​

To allow connections to target databases, add a host entry with the following considerations:

  • Add a Service with the type DB, specifying the address and the port of the database server on the host.
  • Select the database wire protocol or passthrough mode and configure the TLS Certificate Validation mode and database server TLS certificate trust anchor certificates under Additional Settings.
  • If you use either Passthrough or TLS protocol, set Audit Skip (Bytes) to exclude the beginning of the database protocol stream from session recording. This part of the stream typically contains the database credentials. Determine an appropriate value for Skip Bytes for the selected database protocol.
  • Add Accounts and specify which PrivX roles can access the host and which target database accounts they can use. Connection-specific upload and download byte limits can be set under Database Settings.

Connection Justification​

You can require users to provide a justification before connecting to a host service. For example, the justification can contain a ticket number or a short description of the purpose of the connection. Connection justification is supported for SSH, RDP, VNC, and Web services. It applies to browser-based and supported native-client connections.

tip

For SSH services, you can also enable connection justification with the host-deployment-script option --enable-justification. For hosts imported from a host directory, use the privx-justify-conn host tag.

To enable connection justification in PrivX Web UI:

  1. Configure the text displayed to users. In Administration → Settings → Global → Global Settings, select Edit for Connection Common, and enter the prompt in Connection justification prompt. The prompt can contain a maximum of 250 characters and applies to all SSH, RDP, VNC, and Web services.
  2. Require justification for a host service. In Administration → Hosts while adding or editing host, under Services → Additional Settings select the Justification checkbox.

When justification is enabled, service details display Require justification: Yes and PrivX prompts the user before connecting to the target. The user cannot continue without providing a justification. The justification cannot be empty. For connections through the PrivX Web UI, the user has approximately 1 minute to provide a justification. If the user does not respond, PrivX terminates the connection attempt and displays Unable to connect. This timeout does not apply to native-client connections.

caution

Connection justification applies to all SSH connection types, including command execution and SCP and SFTP file transfers. Because justification requires user input, enabling it can prevent automated scripts from connecting.

For an established connection, PrivX displays the user-provided justification in the connection details under Monitoring → Connections. If PrivX terminates the connection before it is established because the user did not provide a valid justification, the connection does not appear on the Connections page. To determine why the connection was rejected, check the Connection-rejected event under Monitoring → Events.

To find connections by their justification, use the Justification search criterion. For example, (Justification=deliver hotfix for TICKET-1234). You can combine the Justification criterion with other criteria. For example, (Type=RDP)(Justification=deliver hotfix for TICKET-1234). Only the Justification criterion searches the justification text.

When defining a justification convention, use distinctive values such as ticket numbers, project codes, or other markers that can be found reliably. Justification searches have the following limitations:

  • Searches match complete words, not parts of words.
  • All specified words must occur in the justification. Adding more words narrows the results.
  • Searches omit punctuation and common words such as a, an, and the.
  • Searches are optimized for English. In some cases, a search can match variants of a word. For example, a search for needs can also match need.

Account Types​

Select an account type to define how PrivX resolves the target account:

  • Explicit: Grants access to a specified target account. Use this account type for web targets.
  • Directory: Allow access to the users' Windows username or Linux username. For PrivX directory users, these values default to their userPrincipalName and sAMAccountName attributes, respectively.
  • User-defined: Prompts the user to enter the target-account username. Unlike manual connections, this account type restricts the connection to the configured host.
note

If the username provided for a User-defined account matches another account entry, PrivX uses the matching entry with the highest-priority authentication method. Otherwise, PrivX prompts the user for a password. For more information about the preference order of authentication methods, see Supported Authentication Methods.

For example:

  • In the following scenario, a host has two account entries:
    • Explicit: Members of Example Role 01 can access alice with certificate authentication.
    • User-defined: Members of any role can enter a target-account username and authenticate with a user-provided passphrase.
  • If a member of Example Role 01 selects the User-defined account and enters alice, PrivX matches the Explicit account and uses certificate authentication as the higher-priority method than user-provided password authentication.

Automatic Account and Home Directory for Directory Users​

To let directory users access target hosts with their personal accounts, configure the hosts to recognize the directory accounts and create home directories when users first log in.

Before you continue, configure personal-account access in one of the following ways:

  • Deploy the host with the host-deployment script and specify the --personal-account-roles option.
  • Add a Directory account to the host in PrivX.

SSH Connections to Unix​

By default, directory users who have been granted access through PrivX still need the following before they can access target hosts successfully:

  • The PrivX-user's Unix account must be recognized on the target host. To accomplish this, configure the target host to support logins from the corresponding user directories.
  • The user's home directory should be created during their initial login.

The following example configures these features on a Debian-based host for AD users:

  1. Install the libnss-ldapd and nslcd LDAP name services.

  2. In /etc/nslcd.conf, specify the AD server address, bind credentials, search base, SSL options, and attribute mappings.

    Example /etc/nslcd.conf:

    # The user and group nslcd should run as.
    uid nslcd
    gid nslcd

    # Replace with the address of your AD service
    uri ldap://ad.example.com

    # Replace with the base DN for querying users
    base CN=Users,DC=example,DC=com

    # Replace with your bind credentials
    binddn Administrator@example.com
    bindpw example_password

    # Replace with your SSL options
    ssl start_tls
    tls_reqcert demand
    tls_cacertfile /etc/ssl/certs/ca-certificates.crt
       
    # The search scope.
    scope sub

    # Filter for finding users
    filter passwd (objectClass=person)

    # Map Unix attributes if they do not exist in your AD
    map    passwd    uid              sAMAccountName
    map    passwd    homeDirectory    "/home/$sAMAccountName"
    map    passwd    gecos            displayName
    map    passwd    uidNumber        unixUID
    map    passwd    gidNumber        unixGID

  3. Allow LDAP authentication in the NSS configuration /etc/nssswitch.conf: add ldap to passwd, group, and shadow.

    passwd:      compat ldap
    group:       compat ldap
    shadow:      compat ldap

  4. Restart the relevant services such as nscd and nslcd to apply your configuration changes. Run the following command to verify that the host recognizes the AD users:

    getent passwd

    If getent passwd dos not return AD users:

    • Run the LDAP name service nslcd in debug mode: 
      systemctl stop nscd nslcd
      nslcd -d
    • Run getent passwd again and check the nslcd output for errors such as bind failures or missing user attributes. After debugging, restart the LDAP name services.

  5. Automatic home-directory creation is handled by the PAM module pam_mkhomedir. To enable PAM authentication on the OpenSSH server, configure the following in /etc/ssh/sshd.conf:

    ChallengeResponseAuthentication yes
    UsePAM yes

  6. Run pam-auth-update and enable Create home directory on login to set up automatic home-directory creation. After that restart OpenSSH server to apply the changes. PrivX-users with personal-account access to the host can now log in to the target host.

RDP Connections to Windows​

To automatically create users and user home folders on Windows hosts, set up RDP-certificate authentication as described in RDP Certificate Authentication.

Page updated on