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.

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:

To specify principals, use any of the following options:

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

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

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

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.

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.

The SSH server on the target host must be configured to trust certificates issued by PrivX (the section called “Trusting PrivX Certificates”).

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:

To display the target hosts and accounts under known targets in PrivX, add the host to PrivX (the section called “Setting up Known Targets”).

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.

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:

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).

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

On all target hosts, ensure that the host allows remote connections without Network Level Authentication.

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 the section called “Setting up Known Targets”.

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.

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

Under the RDP host certificate section, click

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

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:

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

Save your changes to the RDP-proxy configuration.

Restart the PrivX services to apply the new settings:

# systemctl restart privx

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": [ "*" ]
}
]
}

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.

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": {}
}
]
}

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.

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.

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

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

$ privx-agent-ctl login username

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/