PrivX allows password authentication by default. This chapter describes how you may allow other authentication methods (such as certificate or public-key) for connecting to target hosts.

Supported Authentication Methods

PrivX users can authenticate to target hosts using the following methods.

Table 7. Supported authentication methods

Method

Supported by

Notes

Certificate (for SSH connections)

SSH

Only for supported OpenSSH versions described in PrivX Administrator Manual > Authentication Methods for Host Connections > Enabling Certificate-Based Authentication for SSH Connections > Requirements for Certificate Authentication Over SSH.

Public key

SSH

 

Stored password

SSH, RDP

 

Certificate (for RDP connections)

RDP

Target hosts must satisfy the prerequisites from PrivX Administrator Manual > Authentication Methods for Host Connections > Enabling Certificate Authentication for RDP Connections > Requirements for Certificate-Based Authentication Over RDP.

User-provided password

SSH, RDP

 


 Certificate 

Users are authenticated using just-in-time certificates. PrivX automatically issues certificates as needed; users do not need to input credentials when connecting.

 Advantages: Automatically expiring credentials that are never exposed to users, making this method the most secure option.
 Disadvantages: Allowed principals must be configured for target users, which is unwieldy in environments without automated configuration management. System times must be synchronized for certificate-based authentication to work correctly.
 Public key 

Users are authenticated using public keys provided by PrivX. Users do not need to input credentials when connecting.

 Advantages: Public-key authentication is largely supported even on older and non-mainstream SSH servers.
 Disadvantages: Public keys must be manually provisioned to target users on target servers. Public keys never expire, so they need to be manually renewed.
 Stored password 

Users are authenticated using passwords stored in PrivX. Users do not need to input credentials when connecting.

 Advantages: Easy to set up.
 Disadvantages: Weak passwords may compromise security.
 User-provided password 

Users are authenticated using passwords stored in PrivX.

 Advantages: No additional target-host configuration required.
 Disadvantages: Users must provide the target-user password when connecting. Weak passwords may compromise security.

Note

If a target host/target user supports multiple methods, the topmost supported method is used. User-provided password is enabled on all target hosts by default.

Enabling Certificate-Based Authentication for SSH Connections

You can enable certificate-based authentication on a target host with one of the following methods:

  • Run the PrivX host-deployment script on the target host (PrivX Administrator Manual > Authentication Methods for Host Connections > Enabling Certificate-Based Authentication for SSH Connections > Script-Based Certificate-Authentication Setup)

  • Manually set up OpenSSH server and allowed principals on the target host (PrivX Administrator Manual > Authentication Methods for Host Connections > Enabling Certificate-Based Authentication for SSH Connections > Manual Certificate-Authentication Setup)

Requirements for Certificate Authentication Over SSH

To use certificate-based authentication for SSH connections, hosts serving as connection endpoints (target hosts) must use an SSH server that supports OpenSSH certificates. The exact required version depend on the chosen authorization method. For additional information about the supported authorization methods, see PrivX Administrator Manual > Authentication Methods for Host Connections > Supported Authentication Methods.

Table 8. SSH version requirements for certificate-based authentication

Authorization method

Required version

Role-based access

OpenSSH 5.6 or later

Login as self

OpenSSH 6.9 or later


Determine the PrivX roles that can access the host, and the target users as whom they are granted login.

Script-Based Certificate-Authentication Setup

PrivX provides a host-deployment script. It is a Python script that can be executed on target hosts to automatically set up certificate authentication.

The host-deployment script has the following system requirements:

  • Supported operating systems: CentOS, Fedora, Debian, Red Hat, Ubuntu.

  • Required Python version: 2.7.9 or later.

  • Required OpenSSH version: 6.9 or later.

  • Network: Connectivity to a PrivX server.

Note

On target hosts that do not support the host-deployment script, and on hosts that cannot connect to PrivX, you can set up certificate-authentication manually as per PrivX Administrator Manual > Authentication Methods for Host Connections > Enabling Certificate-Based Authentication for SSH Connections > Manual Certificate-Authentication Setup.

Note

For hosts that cannot be accessed directly by PrivX, you need to first set up a PrivX Extender for proxying host connections. For more information about PrivX Extender setup, see PrivX Administrator Manual > Establishing and Managing Connections > Setting up Known Targets > Proxying Connections to Hosts.

To use the host-deployment script to set up certificate authentication on a target host, for connections between certain target accounts and PrivX users from certain roles:

  1. To create a host-deployment script, navigate to the Settings→Deployment→Deploy and configure SSH target hosts page, select Configure using a deployment script, then click Add Script. Download the deploy.py script when prompted to.

  2. Execute the deployment script on the target host as root. You will at least need to provide the host type, and the principals (specifying which target accounts can be accessed, and by whom).

    To specify the host type, use one of the following options:

    --aws: The host runs on AWS.
    --google-cloud: The host runs on Google Cloud.
    --openstack: The host runs on OpenStack.
    --standalone: For non-cloud hosts.

    To specify principals, use any of the following options:

    --personal-account-roles: Allow members of certain roles to log in with their personal accounts (to target accounts whose names match their Windows/Unix username).
    --principals: Manually define target accounts and the roles that may access them.

    For example, using --personal-account-roles to allow members of the roles Example Role 01 and Example Role 02 to log in with their personal accounts, add:

    --personal-account-roles "Example Role 01,Example Role 02"

    You may also specify --principals to define target accounts and the roles that may access them. The general format is:

    --principals target_account1=role1,role2,…:target_account2=role3,role4,…:… 

    For example, to allow target account alice to be accessed by PrivX users belonging to the privx-admin role, set this option to:

    --principals alice=privx-admin

    As another example, to additionally allow accounts alice and bob to be accessed by members of Example Role:

    --principals alice=privx-admin,"Example Role":bob="Example Role"

    Full syntax example of running the host-deployment script:

    # /path/to/deploy.py --standalone \
    --personal-account-roles "Example Role 01, Example Role 02" \
    --principals alice="Example Role",privx-admin:bob=privx-admin

    For a full list of options supported by the host-deployment-script, run:

    $ /path/to/deploy.py help

    Note

    If connections to the target host are relayed via a PrivX Extender, use the --api-hostname option to specify the Extender's address and port, similarly to the following:

    # /path/to/deploy.py --standalone \
    --personal-account-roles "Example Role 01" \
    --api-hostname "extender.example.com:8443"

    You may verify the addresses (subject-alternative names) of your PrivX Extender from its TLS certificate:

    # openssl x509 -text -noout -in \
    /opt/privx/extender/extender.crt | grep -A 1 \
    "Subject Alternative Name"

    The PrivX Extender port is 8443 by default. You may verify the port from the Extender's configuration file, where it is specified by the host_deployment_listen_address variable.

  3. Certificates issued by PrivX are very time-sensitive. Even a clock skew of few minutes may prevent certificates from working correctly.

    Verify that the target-host time is correct. Adjust as necessary.

PrivX users belonging to one of the allowed roles should now see the target host on the Connections→New Connection page.

You may also verify that certificate-based authentication is used by checking the OpenSSH-server logs on the target server. Upon successful certificate-based authentication there should be a log message like the following:

Accepted publickey for alice from 192.0.2.26 port 50930 ssh2: RSA-CERT \
ID alice@127.0.0.1:53188 serial 4920619392583124720 \
(serial 4920619392583124720) \
CA RSA 98:16:36:bf:6e:c6:3f:e5:a1:5e:31:61:c1:37:ef:d8
Configuring Access Using Host Tags

For cloud-based hosts, PrivX can be configured to import allowed principals from host tags. This method simplifies host deployment as principals do not need to be provided for the host-deployment script.

Tip

Configuring access with host tags can be used for setting up hosts that mostly lack connection to PrivX: An initial instance must be able to connect to PrivX, but subsequent clones of this instance do not need PrivX connectivity.

To configure allowed principals for a cloud-based host using host tags:

  1. Add host tags to the host via your cloud-host-management interface (such as EC2 for AWS instances). Host tags must specify the access rules and SSH/RDP services related to the host.

    The list of supported host tags is provided later in this section.

  2. Configure PrivX to import host tags. To do this, navigate to Settings→Directories in the PrivX GUI and Edit the directory to which the target host belongs to. Enable the Import host instance tags from the directory setting. Click Save to apply your changes.

  3. Deploy the host using the host-deployment script, or manually.

    Users from PrivX roles are now able to access the host according to the principals defined in the host tags, with certificate-based authentication.

PrivX supports the following host tags:

 privx-ssh-principals=<target>=<roles1>:<target2>=<roles2>:... 

Allow target accounts to be accessed by specified PrivX roles using SSH connections.

Access to each target account is specified with <target>=<roles> syntax, where <target> is the account name and <roles> is the comma-separated names of PrivX roles allowed to access the account. Each such mapping must be separated with a colon (:).

For example, to allow target user alice to be accessed by PrivX roles privx-admin and Role 01, and to allow target user bob to be accessed by Role 02:

privx-ssh-principals=alice=Role 01,privx-admin:bob=Role 02
 privx-rdp-principals=<target1>=<roles1>:<target2>=<roles2>:... 

Allow target accounts to be accessed by specified PrivX roles using RDP connections.

Syntax is the same as with the privx-ssh-principals tag.

 privx-ssh-personal-account-roles=<roles> 

Allow members of certain role(s) to log in with their personal accounts (to target accounts whose names match their Windows/Unix username) using SSH connections. Any comma-separated PrivX-role names in <roles> are allowed login to personal accounts.

For example, to allow members of Role 01 and Role 02 to login to personal accounts:

privx-ssh-personal-account-roles=Role 01,Role 02
 privx-rdp-personal-account-roles=<roles> 

Allow members of certain role(s) to log in with their personal accounts (to target accounts whose names match their Windows/Unix username) using RDP connections. Syntax is similar to the privx-ssh-personal-account-roles tag.

 privx-ssh-service-port=<port> 

Specify the SSH-server port of the target host. By default SSH servers run on port 22.

Example:

privx-ssh-service-port=22
 privx-rdp-service-port=<port> 

Specify the RDP-server port of the target host. By default RDP servers run on port 3389.

Example:

privx-rdp-service-port=3389
 privx-extender=<extender_name> 

If connections to the host are relayed through a PrivX Extender, use this tag to specify the name of the Extender.

Example:

privx-extender=example-extender

For more information about PrivX Extender, see PrivX Administrator Manual > Establishing and Managing Connections > Setting up Known Targets > Proxying Connections to Hosts.

 privx-enable-auditing=<yes|no> 

Toggle auditing for the host. Defaults to no

Example:

privx-enable-auditing=yes

Note

To obtain the tag in key-value format, split the syntax at the first = sign. For example, the previously-provided examples are as follows in key-value format:

Key

Value

privx-ssh-principals

alice=Role 01,privx-admin:bob=Role 02

privx-ssh-personal-account-roles

Role 01,Role 02

privx-ssh-service-port

22

privx-rdp-service-port

3389

privx-extender

example-extender

privx-enable-auditing

yes

Certificate-Authentication Setup via Chef

SSH Communications Security provides a public Chef cookbook privx-chef-cookbook. You can use it to set up nodes to trust PrivX certificates.

To obtain this cookbook, along with more information about its usage, visit:

https://github.com/SSHcom/privx-chef-cookbook

Manual Certificate-Authentication Setup

To manually enable certificate-based authentication, you must configure your target hosts as follows:

  1. Ensure the system clocks are synchronized (for example, using NTP). The certificates issued by PrivX have very short validity periods: clock skew may cause authentication to fail.

  2. The SSH server on the target host must be configured to trust certificates issued by PrivX (PrivX Administrator Manual > Authentication Methods for Host Connections > Enabling Certificate-Based Authentication for SSH Connections > Manual Certificate-Authentication Setup > Trusting PrivX Certificates).

  3. For target user accounts, specify the principals that are allowed to connect. Depending on the target-host OpenSSH version, you can do this in either of the following methods:

    • For OpenSSH 6.9 or later: Set up the principals-command script provided with PrivX. Allows PrivX users of selected roles to login with their personal accounts. Additionally, you can define the target accounts and the roles that may access them (PrivX Administrator Manual > Authentication Methods for Host Connections > Enabling Certificate-Based Authentication for SSH Connections > Manual Certificate-Authentication Setup > Allowing Login as Self and Role-Based Access).

    • For OpenSSH 5.6 or later: Configure allowed principals per target account. You can define the target accounts and the roles that may access them (PrivX Administrator Manual > Authentication Methods for Host Connections > Enabling Certificate-Based Authentication for SSH Connections > Manual Certificate-Authentication Setup > Allowing Role-Based Access).

  4. To display the target hosts and accounts under known targets in PrivX, add the host to PrivX (PrivX Administrator Manual > Establishing and Managing Connections > Setting up Known Targets).

Principals in PrivX-Issued Certificates

This section describes principals in the context of certificate-based authentication.

OpenSSH certificates contain principals indicating who is requesting access. OpenSSH certificates issued by PrivX contain at least the user name as a principal, and may have any number of other principals. For example, assume a PrivX user named alice belongs to roles having the principals:

 bd5eab79-fe35-4f52-839a-05737075b152 
 b8b72199-689d-5a9b-782f-8e1069f7db19 

When PrivX user alice connects to a target host using certificate authentication, PrivX issues them a certificate with the following principals:

 bd5eab79-fe35-4f52-839a-05737075b152 
 b8b72199-689d-5a9b-782f-8e1069f7db19 
 alice 

Authentication succeeds if the target account allows at least one of the principals.

Trusting PrivX Certificates

Target hosts using certificate-based authentication must be configured to trust the certificates issued by PrivX.

  1. In the PrivX GUI, go to the Settings→Deployment→Deploy and Configure SSH target hosts page. Select Configure manually. Acquire the PrivX CA key.

    Figure 3. PrivX CA key

    PrivX CA key

    Copy the PrivX CA key. This key is later required for configuring the target host.

  2. On the target host, create the following file:

    /etc/ssh/privx_ca.pub

    Copy and save the PrivX CA key into this file.

    Ensure that the CA-key file is owned and readable by the user running the SSH server (typically root):

    # chown root:root /etc/ssh/privx_ca.pub
    # chmod 0400 /etc/ssh/privx_ca.pub
  3. In the SSH server configuration file (located at /etc/ssh/sshd_config by default), specify TrustedUserCAKeys to point to the PrivX CA key. To do this, add a line similar to the following into the SSH server configuration:

    TrustedUserCAKeys /etc/ssh/privx_ca.pub

    Restart the SSH server to apply the new settings.

  4. Certificates issued by PrivX are very time-sensitive. Even a clock skew of few minutes may prevent certificates from working correctly.

    Verify that the target-host time is correct. Adjust as necessary.

Allowing Login as Self and Role-Based Access

PrivX provides a principals-command script that enables login with personal accounts: PrivX users can log into the target accounts, the names of which match the PrivX user's Windows/Linux username.

Note

The principals-command script is only supported on target hosts running OpenSSH 6.9 or later.

The provided principals-command script is provided as an example. You may modify the script to suit your own needs.

To set up the principals-command script, enable login with personal accounts, and to configure role-based access:

  1. PrivX users who are to access the target host must belong to at least one PrivX role. If you have not done so already, assign users to roles as described in PrivX Administrator Manual > PrivX Users and Permissions > Granting Permissions for PrivX Users > Managing Roles.

    Also ensure that PrivX users are set with correct Windows username and Linux username. By default, AD users' Windows username and Linux username are set to match their User-Principal Name and sAMAccountName respectively.

  2. For security reasons we recommend creating a user specifically for running the principal-command script on the target host. This AuthorizedPrincipalsCommandUser should be an unprivileged user who only has permissions for performing the following:

    • Running the principals-command script.

    • Reading the principals that are allowed to log in with personal accounts, at /etc/ssh/personal_account_roles

    • Reading any user-specific authorization-principals files located at /etc/ssh/auth_principals/%u (replace %u with the name of the authenticated user).

    Some Unix distributions have a default nobody account, which can be used as the AuthorizedPrincipalsCommandUser.

  3. Obtain the AuthorizedPrincipalsCommand script from your PrivX server, at the following path:

    /opt/privx/authorizer/principals_command.sh

    Copy the script to the target host. In this example, we assume the script is copied to

    /etc/ssh/principals_command.sh

    Both the script and the directory it is in must be owned by root. The script must also be readable and executable by the AuthorizedPrincipalsCommandUser (replace /etc/ssh/principals_command.sh with the path to which you copied the script):

    # chown root:root/etc/ssh
    # chown root:root/etc/ssh/principals_command.sh
    # chmod 0755 /etc/ssh/principals_command.sh
  4. Configure SSH server to run the principals-command script as the AuthorizedPrincipalsCommandUser. This is done by adding lines similar to the following into the SSH configuration (by default at /etc/ssh/sshd_config, replace authprincipalsuser with the name of your designated AuthorizedPrincipalsCommandUser, replace /etc/ssh/principals_command.sh with the path where you copied the script ):

    AuthorizedPrincipalsCommand /etc/ssh/principals_command.sh %u
    AuthorizedPrincipalsCommandUser authprincipalsuser

    Save your changes to the SSH server configuration file. Restart the SSH server to apply the changes.

  5. Next, specify who is allowed to access target accounts. Note that all access must be specified in a role-based fashion.

    1. To allow login with personal accounts for members of certain roles: On the target host, specify in /etc/ssh/personal_account_roles which PrivX-role members are allowed to log in with personal accounts. The file should specify one UUID per line, similar to the following:

      269eaef2-482e-5b44-5d0f-2ee4c37e2877 # Example Admins
      31f070c6-33ff-523f-4cea-d586ab25071a # Example Role
      8a0c0cbb-1417-4de2-8532-3eac1fb4c30b # Example Users
      ...

      To determine the UUIDs of PrivX roles. Go to Settings→Deployment→Deploy and Configure SSH target hosts page, then select Configure manually.

      Figure 4. Role principals in the PrivX GUI

      Role principals in the PrivX GUI

      Also ensure the file is readable by root and the AuthorizedPrincipalsCommandUser:

      # chown root:root /etc/ssh/personal_account_roles
      # chmod 0604 /etc/ssh/personal_account_roles

      PrivX users belonging to the specified roles may now log into the host as themselves. For example, a PrivX user belonging to the Example Admins role (with role UUID 269eaef2-482e-5b44-5d0f-2ee4c37e2877) with the Linux usernamealice may now log in to the target-account named alice (assuming the host is Unix/Linux-based).

    2. To grant custom role-based access to certain target accounts: Create the directory /etc/ssh/auth_principals/ for holding target-account-specific principals files (if not already done):

      # mkdir /etc/ssh/auth_principals
      # chown root:root /etc/ssh/auth_principals/
      # chmod 0755 /etc/ssh/auth_principals/

      For each target account requiring custom role-based access, create a principals file under /etc/ssh/auth_principals/. The principals file must have the same name as the target account. For example, when setting up custom role-based access for a target account named alice, the principals file is /etc/ssh/auth_principals/alice

      In the principals file, specify the roles that may access the account. The file should specify one UUID per line, similar to the following:

      269eaef2-482e-5b44-5d0f-2ee4c37e2877 # Example Admins
      31f070c6-33ff-523f-4cea-d586ab25071a # Example Role
      8a0c0cbb-1417-4de2-8532-3eac1fb4c30b # Example Users
      ...

      After saving your changes to the file, ensure it is readable and executable by both root and the AuthorizedPrincipalsCommandUser (replace /etc/ssh/auth_principals/alice with the path to the user's principals file):

      # chown root:root /etc/ssh/auth_principals/alice
      # chmod 0705 /etc/ssh/auth_principals/alice
  6. Certificates issued by PrivX are very time-sensitive. Even a clock skew of few minutes may prevent certificates from working correctly.

    Verify that the target-host time is correct. Adjust as necessary.

You may verify that certificate-authentication is used by checking the OpenSSH-server logs on the target server. Upon successful certificate authentication there should be a log message like the following:

Accepted publickey for alice from 192.0.2.26 port 50930 ssh2: RSA-CERT \
ID alice@127.0.0.1:53188 serial 4920619392583124720 \
(serial 4920619392583124720) \
CA RSA 98:16:36:bf:6e:c6:3f:e5:a1:5e:31:61:c1:37:ef:d8
Allowing Role-Based Access

PrivX roles have unique principals. When a target user allows a role principal, members of corresponding roles can connect to the target user.

To allow the members of a PrivX role to access a target user:

  1. On the target host, create a directory for storing principals files (if not already done).

    # mkdir /etc/ssh/auth_principals

    The permissions of the directory must be set so that individual target users are able to read their authorization-principals files, for example:

    # chown root:root /etc/ssh/auth_principals
    # chmod 0755 /etc/ssh/auth_principals
  2. On the target host, create a file for storing the user-specific allowed principals (replace %u with the account name of the target user on the target host):

    /etc/ssh/auth_principals/%u

    For example, if the target-user name is alice, their principals file is:

    /etc/ssh/auth_principals/alice

    Within the file, specify the UUIDs of the roles that are allowed access to the target-user account. Specify each UUID on its own line, similar to the following:

    269eaef2-482e-5b44-5d0f-2ee4c37e2877 # Example Admins
    31f070c6-33ff-523f-4cea-d586ab25071a # Example Role
    8a0c0cbb-1417-4de2-8532-3eac1fb4c30b # Example Users
    ...

    To determine the UUIDs of PrivX roles. Go to Settings→Deployment→Deploy and Configure SSH target hosts page, then select Configure manually.

    Figure 5. Role principals in the PrivX GUI

    Role principals in the PrivX GUI

  3. Ensure that the authorization-principals file is owned and readable by the target-user account (replace %u with the name of the target-user account):

    # chown %u:%u /etc/ssh/auth_principals/%u
    # chmod 0400 /etc/ssh/auth_principals/%u

    For example, if the target-user name is alice:

    # chown alice:alice /etc/ssh/auth_principals/alice
    # chmod 0400 /etc/ssh/auth_principals/alice
  4. If not already done, instruct the SSH server about where the authorization-principals files can be found from. This can be done by specifying the AuthorizedPrincipalsFile setting in the OpenSSH server configuration (by default at /etc/ssh/sshd_config):

    AuthorizedPrincipalsFile /etc/ssh/auth_principals/%u

    Save your changes to the OpenSSH server configuration. Restart the OpenSSH server to apply the changes. PrivX users belonging to one or more allowed principals (roles) are now authenticated to the target-user account using certificates.

  5. Certificates issued by PrivX are very time-sensitive. Even a clock skew of few minutes may prevent certificates from working correctly.

    Verify that the target-host time is correct. Adjust as necessary.

You may verify that certificate-authentication is used by checking the OpenSSH-server logs on the target server. Upon successful certificate authentication there should be a log message like the following:

Accepted publickey for alice from 192.0.2.26 port 50930 ssh2: RSA-CERT \
ID alice@127.0.0.1:53188 serial 4920619392583124720 \
(serial 4920619392583124720) \
CA RSA 98:16:36:bf:6e:c6:3f:e5:a1:5e:31:61:c1:37:ef:d8

Enabling Certificate Authentication for RDP Connections

This section describes the procedures for enabling certificate authentication for RDP connections.

Before setting up certificate authentication for RDP connections, ensure the prerequisites described in PrivX Administrator Manual > Authentication Methods for Host Connections > Enabling Certificate Authentication for RDP Connections > Requirements for Certificate-Based Authentication Over RDP.

Requirements for Certificate-Based Authentication Over RDP

Before enabling certificate authentication for RDP, check and execute the following:

  • Target hosts must belong to a Windows domain. The domain must include:

    • A domain controller with the server role Active Directory Domain Services, for handling authentication requests.

    • A Certificate Authority Server (CA server), with the server role Active Directory Certificate Services, including the role service Certificate authority.

      The CA server must also have a service for certificate-revocation-status checks, for example, HTTP CRL with Certificate Enrollment Web Service or Web Server IIS role, or alternatively OCSP with the Online Responder role service.

    • Ensure that users' group policy allows RDP login. When enabling login with personal accounts, also ensure target-host local policy allows users to log on locally.

  • Both the domain controller and the CA server must run on one of these supported platforms:

    • Windows Server 2008 R2 (with the latest service pack and updates)

    • Windows Server 2012 R2 (with the latest service pack and updates)

    • Windows Server 2016 (with the latest service pack and updates)

  • The domain policy must enable server certificate auto-enrollment. For instructions about enabling this, please refer to Microsoft documentation at https://docs.microsoft.com (search title: configure server certificate autoenrollment).

  • Firewalls for the domain must allow HTTP access to PrivX server port 80, for obtaining the Certificate Revocation List.

  • PrivX server's IPs and FQDNs should be recorded in the shared-config.toml file. All listed IPs and FQDNs will be used as Certificate Revocation List Distribution Points.

  • Hosts in the target domain must be able to resolve PrivX server FQDNs.

Note

Steps for RDP Certificate-Authentication-Setup

After ensuring the prerequisites, enable certificate authentication for RDP by performing the following:

  1. For target hosts to trust PrivX certificates, you must publish the PrivX CA certificate in the Windows domain.

    To obtain the PrivX CA certificate, go to the PrivX GUI. On the Settings→Deployment→Configure a Windows Domain for RDP Access page, click Download Certificate.

  2. Add the PrivX CA certificate to the Trusted Root Certification Authorities for the domain.

    For improved security, also restrict the purposes of the PrivX CA: In the general properties of the PrivX CA certificate, select Enable only the following purposes, then select the following purposes:

    • Smart Card Logon

    • Client Authentication

    Save your changes to the certificate.

    For more information, please refer to Microsoft documentation at https://docs.microsoft.com (search title: distribute certificates to client computers by using group policy).

  3. Publish the PrivX CA certificate to the domain (replace privx_ca.crt with the path of the PrivX CA-certificate file):

    $ certutil -dspublish -f privx_ca.pem NTAuthCA

    Also ensure that the registry is updated by running:

    certutil -addstore -enterprise NTAuth privx_ca.pem
  4. On all target hosts, ensure that the host allows remote connections without Network Level Authentication.

  5. Define which roles are allowed to access the target hosts, and as which target accounts. For more information about mapping roles to target accounts, see PrivX Administrator Manual > Establishing and Managing Connections > Setting up Known Targets.

  6. Certificates issued by PrivX are very time-sensitive. Even a clock skew of few minutes may prevent certificates from working correctly.

    Verify that the system times on the target hosts is correct. Adjust as necessary.

RDP connections to target hosts are now be authenticated by just-in-time certificates provided by PrivX, without needing to provide target-user passwords.

Enabling Role-Based Public-Key Authentication

  1. Obtain the public key of the role you want to authorize. You can do this on the Settings→Deployment→Deploy and Configure SSH target hosts page.

    publickey.png
  2. Authorize the public key to the target user on the target host. In OpenSSH for example, this is done by appending the public key to the authorized_keys file, typically located at:

    ~/.ssh/authorized_keys

    All the members of the role should now be able to connect to the target user with public-key authentication.

Enabling Authentication with Stored Passwords

You can store target-user passwords in PrivX, so PrivX users can connect to those target users without having to provide the password. The steps for enabling this authentication method are:

  1. For SSH only: Configure the target-host SSH server to allow password authentication. Note that allowing keyboard-interactive authentication does not enable using stored passwords in PrivX.

  2. Store the target-user passwords in PrivX:

    1. On the Settings→Hosts page, Edit the target host on which the target user is.

    2. Under the Accounts section, provide the Password for the target user(s). If not done already, also specify the Roles that may access the target user(s)

    3. Click Save to apply the changes.

    Connections to the target user should no longer prompt for password.

Trusting Target-Host Identities

This section describes target-host authentication.

SSH Target-Host Authentication

For SSH connections, PrivX authenticates target hosts by their SSH host keys.

You can store SSH host keys when creating or editing a host entry via Settings→Hosts.

When connecting to a host, the key/certificate of which is not yet trusted by PrivX, the connection starts as follows:

  • If no other keys are stored for the host: PrivX administrators may accept the new host key for all subsequent connections. Regular PrivX user can accept a new host key if the Trust On First Use is enabled for the host.

  • If another key has been stored for the host: Regular PrivX users are prevented from connecting to the host. A PrivX administrator must explicitly accept the key for all subsequent connections.

You can store SSH host keys and set Trust on First Use behavior by editing host entries on the Settings→Hosts page.

RDP Target-Host Authentication

For RDP connections, PrivX authenticates target hosts by their RDP-server certificate.

By default, PrivX automatically accepts the certificate encountered upon the first RDP connection. Connections will fail if the RDP-server certificate changes, or is renewed prior to the start of the renewal period. The renewal period starts one month prior to the expiry date. Connection will automatically accept the new certificate during the renewal period.

If connections fails due to the RDP-server certificate changing, you can re-enable by deleting the stored RDP certificate:

  1. On the Settings→Hosts page, Edit the target RDP server.

  2. Under the RDP host certificate section, click bin.png

    Upon next RDP connection, PrivX automatically accepts the new RDP-server certificate for subsequent RDP connections.

You can adjust the time window during which the RDP-server certificate may be automatically renewed. To do this:

  1. Modify the RDP proxy settings, located at the following path on your PrivX servers:

    /opt/privx/etc/rdp-proxy.toml

    Locate and modify the following settings:

    • renewal_period_months: Allow RDP-server certificate to be renewed from this many months before the NotAfter field marked in the current RDP-server certificate.

    • renewal_period_days: Allow RDP-server certificate to be renewed from this many days before the NotAfter field marked in the current RDP-server certificate.

    These two settings are cumulative. For example, to allow the RDP-server certificate to be renewed from two months and 15 days before the current one expires:

    [certificates]
    update_automatically = true
    renewal_period_months = 2
    renewal_period_days = 15
  2. Save your changes to the RDP-proxy configuration.

    Restart the PrivX services to apply the new settings:

    # systemctl restart privx

Authentication to AWS Services

You can use PrivX to authenticate and authorize users of the AWS Command Line Interface (AWS CLI). PrivX issues short-term credentials to allow users to perform their tasks, which removes the need for manually provisioning public keys or other persistent credentials.

Prerequisites

  • PrivX grants access to AWS services via the AWS Command Line Interface (CLI account). The person receiving access must have a Unix or Mac account with AWS CLI set up.

  • The CLI account must be set up with PrivX agents. For instructions about setting up and using PrivX agents, see PrivX Administrator Manual > Establishing and Managing Connections > SSH Connections with Native Clients.

  • Verify the system time on the host with the CLI account. Short-term credentials issued by PrivX are very time-sensitive. Even a clock skew of few minutes may prevent successful authentication.

PrivX Authentication to AWS Services

Set up AWS users and roles for delegating AWS-service permissions, then grant these roles to PrivX users:

  1. In your AWS management interface, create an IAM user for obtaining AWS roles. To do this, provide the AWS user with the following permission policies:

    {
        "Version": "2012-10-17",
        "Statement": [
            {
                "Effect": "Allow",
                "Action": "sts:GetFederationToken",
                "Resource": [ "*" ]
            },
            {
                "Effect": "Allow",
                "Action": "sts:AssumeRole",
                "Resource": [ "*" ]
            },
            {
                "Effect": "Allow",
                "Action": [
                    "iam:ListRoles",
                    "iam:ListAttachedRolePolicies",
                    "iam:GetPolicy",
                    "iam:GetPolicyVersion",
                    "iam:ListPolicies",
                    "iam:ListPolicyVersions",
                    "ec2:DescribeInstances",
                    "ec2:DescribeRegions"
                ],
                "Resource": [ "*" ]
            }
        ]
    }

    Note

    The ec2:Describe* permissions are only required for scanning AWS hosts, which is functionality associated to all AWS directories in PrivX. The ec2:Describe* permissions may be omitted if you only want to import AWS roles, however note that doing so results in the AWS directory in PrivX having a constant error status.

    PrivX uses this AWS user to import and delegate AWS roles. For this reason you must also create a Secret Access Key for the user. Copy the Access Key ID and the Secret Access Key of the user, which are required later for configuring PrivX.

  2. In your AWS management interface, create AWS role(s) that grant access to AWS services. The AWS role(s) should have permissions like the following (replace the example Actions with services and actions this role should allow access to):

    {
        "Version": "2012-10-17",
        "Statement": [
           {
                "Effect": "Allow",
                "Action": [
                    "s3:Get*","s3:List*"
                ],
                "Resource": [ "*" ]
            }
        ]
    }

    Also set the trust relationships of the AWS role similar to the following (replace <iam_user_arn> with the ARN of the previously-created IAM user):

    {
        "Version": "2012-10-17",
        "Statement": [
            {
                "Effect": "Allow",
                "Principal": {
                    "AWS": "<iam_user_arn>"
                },
                "Action": "sts:AssumeRole",
                "Condition": {}
            }
        ]
    }

    Note

    To allow CLI users to assume the role via PrivX, the AWS role must have a unique Name tag.

    Tip

    Place PrivX-specific roles under a unique path (such as /privx/). PrivX can be configured to import roles from this path, ignoring irrelevant roles in your AWS environment.

  3. On the Settings→Directories page of the PrivX GUI, add a directory of the type Amazon Web Services. Provide the Access key ID and Secret Access Key of the previously-created IAM user.

    Also under Advanced AWS settings, select Enable AWS role federation. If you only want to import roles under a certain path, set this path to AWS role prefix for federated roles

    Save the directory configuration. To verify that roles were imported successfully, ensure that the previously-configured AWS roles are visible on the page Settings→Deployment→Configure Amazon Web Service role grants.

  4. Grant AWS roles to PrivX roles. To do this, go to the page Settings→Deployment→Configure Amazon Web Service role grants, and Edit the AWS roles. PrivX users belonging to specified roles can now gain access according to any AWS roles granted to them.

Using AWS Services

After you have set up access to AWS services (as per PrivX Administrator Manual > Authentication Methods for Host Connections > Authentication to AWS Services > PrivX Authentication to AWS Services), you can use the services authorized to you as follows:

  1. Log into the CLI account on your workstation, activate the PrivX agent if necessary.

  2. Use the PrivX agent to log into PrivX (replace username with your PrivX-user name):

    $ privx-agent-ctl login username
  3. Determine and assume an AWS role available for your account (replace example_aws_role with the name of the role you want to assume):

    $ privx-agent-ctl aws-role list
    $ privx-agent-ctl aws-role set example_aws_role

    You may verify that you have successfully assumed the role by listing the AWS roles. It should be marked with an asterisk (*). For example:

    $ privx-agent-ctl aws-role list
    Available AWS roles:
      example_aws_role_0
     *example_aws_role
      example_ws_role_2
      ...

    You are now permitted to run any AWS services permitted by the AWS role. For example, if the AWS role gives you read access to the s3 service, you can now run:

    $ aws s3 ls s3://bucket.example.com/