AWS CA Integration for RDP

This guide provides general information on how to add an existing AWS certificate authority (CA) as a third-party CA to StrongDM. AWS CA integration allows certificate-based RDP resources to authenticate with certificates issued by AWS, instead of the default Strong CA managed by StrongDM.

Prerequisites #

Before you begin, ensure that you have the following.

• Administrator permission level in StrongDM
• Running AWS Private CA instance that is accessible by a StrongDM gateway or relay
• Familiarity using AWS Private CA
• Certificate Revocation List (CRL) distribution activated and accessible by the Active Directory domain controller for the target AD deployment

AWS Configuration Considerations #

StrongDM doesn’t manage or configure third-party CAs. It is up to you to configure AWS appropriately for your organization, as well as to ensure that the appropriate CA is trusted by the target resources. This section briefly describes the most important parts of AWS setup to consider when integrating an AWS CA with StrongDM.

CA setup #

• AWS Private CA can host multiple certificate authorities.
• Either General-purpose or Short-lived CAs can be used.
• Root or subordinate CAs may be used, as long as the public certificate for any CAs that are to be used are installed on AD.
• RDP only works with RSA 2048 key pairs for the client certificate, but the CA can use any RSA- or ECDSA-based key type and signing algorithm.
• A CRL must be activated.
• Select Activate CRL distribution. CRL distribution must be activated for certificate authentication with Active Directory.

IAM role #

The IAM role used for making certificate requests to AWS Private CA must have the following permissions:

{
  "Effect": "Allow",
  "Action": [
    "acm-pca:IssueCertificate"
  ],
  "Resource": "arn:aws:acm-pca:*:*:certificate-authority/*",
  "Condition": {
    "StringLike": {
      "acm-pca:TemplateArn": [
        "arn:aws:acm-pca:::template/BlankEndEntityCertificate_CSRPassthrough/V*"
      ]
    }
  }
}

The template does not have to be the same one in the example, but it must allow Certificate Signing Request (CSR) passthrough for the alternative name, key usage, and extended key usage fields. AWS requires that you select from a predefined list of templates. The ARN of each template may be found in AWS documentation.

Examples of allowed templates include:

• BlankEndEntityCertificate_CSRPassthrough/V1
• BlankEndEntityCertificate_CriticalBasicConstraints_CSRPassthrough/V1

Certificate signing requests #

How does certificate signing work? StrongDM generates a key pair on the gateway or relay and generates a CSR signed by the private key. The CSR is submitted to AWS Private CA for signing. The resulting signed certificate is then used, along with the private key, to authenticate to the target resource. The private key never leaves the gateway or relay where it was created.

Configure the Gateway or Relay With Credentials to Access AWS Private CA #

This section provides several options to authenticate your StrongDM gateway or relay server with AWS. The gateway or relay needs to be configured with the proper credentials to access the AWS Private CA.

Option 1: Access keys via environment variables #

1. Get an access key for AWS and set the necessary environment variables on your gateway or relay server (AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY).

2. Edit the file /etc/sysconfig/sdm-proxy (unless you have moved or renamed your sdm-proxy file) and add the following lines, substituting your ID and key:

   AWS_ACCESS_KEY_ID=aswf234rt4rsag4t3g
   AWS_SECRET_ACCESS_KEY=23452321h2893hf2ioufh2938229fh2oufgh23890fh29fh23bif2f0928hf02f3n2bf290fn9230f
   

3. Restart the sdm-proxy service (with something like sudo systemctl restart sdm-proxy, depending on your distribution).

Option 2: IAM via EC2 role #

1. In your AWS Management Console, navigate to IAM, click on Role, and click on Create Role.
2. Select EC2 for Service.
3. In the policy, select SecretsManagerReadWrite, and click Next.
4. Add the role name and description, and then go to EC2 and click on Instances.
5. Select the instance that houses the gateway, and click on Actions > Security > Modify IAM Role.
6. Choose the name of the IAM role created earlier.

Option 3: ECS authentication #

In the task definition for the ECS cluster, the Task Role must have a policy allowing access to Secrets Manager attached to it, as in the following example:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "secretsmanager:GetSecretValue"
            ],
            "Resource": [
                "arn:aws:secretsmanager:us-east-1:12345678910:secret:*"
            ]
        }
    ]
}

If Resource Permissions is configured for Secrets Manager, the policy statement also needs to allow the Task Role to access that particular Secrets Manager.

Credential reading order #

During authentication with Secrets Manager, the system looks for credentials in the following places in this order:

1. Environment variables
2. EC2 role
3. ECS authentication or other remote authentication methods (set via AWS_CONTAINER_CREDENTIALS_FULL_URI or AWS_CONTAINER_CREDENTIALS_RELATIVE_URI)
4. Shared credentials file

As soon as the relay or gateway finds credentials, it stops searching and uses them. Due to this behavior, we recommend that all similar AWS resources with these authentication options use the same method when added to StrongDM.

For example, if you are using environment variables for AWS Management Console and using EC2 role authentication for an EKS cluster, when users attempt to connect to the EKS cluster through the gateway or relay, the environment variables are found and used in an attempt to authenticate with the EKS cluster, which then fails. We recommend using the same type for all such resources to avoid this problem at the gateway or relay level. Alternatively, you can segment your network by creating subnets with their own relays and sets of resources, so that the relays can be configured to work correctly with just those resources.

This behavior was changed in CLI version 39.51.0. If you experience unexpected errors when upgrading to this version or above, you can set the environment variable SDM_AWS_LEGACY_PRIORITY to a truthy value such as 1 or true, to temporarily revert to the old behavior. In a future release, this option will go away.

Add AWS CA in the Admin UI #

To add an AWS RDP CA in the Admin UI, follow these steps.

1. From the Settings > Credentials Managemen page in the Certificate Authorities tab, click Add certificate authority.
2. Enter the Name for the CA (any name).
3. For Type, select AWS Private CA RDP.
4. The form updates with other CA properties. Complete all required properties.
5. Click Create certificate authority.

AWS Private CA RDP properties #

Add the AWS CA to a Certificate-Based RDP Server #

1. If you have not already done so, follow the instructions to add an RDP server with certificate authentication.
2. On the resource form, pay particular attention to Certificate Authority. For this field, select the newly added AWS CA.
3. Complete all required fields and save.
4. Test the connection to the resource (for example, use Remote Desktop to connect).

Manage the CA #

After you have added the AWS CA and set a certificate-based server to use it, you may manage the CA and review its settings on the Certificate Authorities tab of the Settings > Credentials Management page in the Admin UI. You may select the CA from the list or click its Details button to view diagnostics, update its settings, or delete the CA configuration.

The Diagnostics tab shows all the nodes (gateways and relays) that are configured to access the CA, as well as health information for the nodes.

If the CA is unable to be accessed by any gateway or relay, please review the CA’s Settings tab and make sure the CA credentials are correct.

Additional Information #

Third-party CAs also may be added and managed in the CLI, SDKs, and Terraform. Note that third-party CAs are treated like secret stores in the CLI, SDKs, and Terraform. As such, they use secret store commands, domain objects, and resources.

Add AWS CA in the CLI #

To add an AWS CA in the CLI instead of the Admin UI, use the sdm admin secretstores create CLI command. Create your “secret store” by choosing awsCertX509 as the secret store type.

sdm admin secretstores create awsCertX509

In the CLI, the options are the same as the AWS CA properties set in the Admin UI.

CLI example #

# Create AWS Private CA RDP
sdm admin secretstores create awsCertX509
--ca-arn="arn:aws:acm-pca:us-east-1:12345678:certificate-authority/abcd-1234-defg-5678"                   
--certificate-template-arn="arn:aws:acm-pca:::template/BlankEndEntityCertificate_CSRPassthrough/V1"                    
--issued-cert-ttl-minutes="480"   
--name="AWS CA"                      
--region="us-east-1"                   
--signing-algo="SHA256WITHRSA"   

# Create RDP (Certificate Based) server
sdm admin servers create rdp-cert
--name="Example RDP AWS"
--hostname="https://host.example.com:1234"
--secret-store-id="se-e1b2"
--username="username"

# Run secret store healthcheck
sdm admin secretstores healthcheck se-e1b2

# Check that the secret store is reachable
sdm admin secretstores status

# Check the connection to the resource
sdm connect "Example AWS CA"

Add AWS CA in Terraform #

In addition to using the Admin UI and CLI, you may use Terraform to add an AWS CA for use with certificate-based RDP servers. This section includes a Terraform example.

For additional information, see our Terraform provider documentation.

Terraform example #

# Install StrongDM provider
terraform {
  required_providers {
    sdm = {
      source  = "strongdm/sdm"
      version = "7.1.1"
    }
  }
}

# Configure StrongDM provider
provider "sdm" {
    # Add API access key and secret key from Admin UI
    api_access_key = "njjSn...5hM"
    api_secret_key = "ziG...="
}

variable "prefix" {
  type = string
  default = "example-tf-"
}

# Create AWS Private CA RDP
resource "sdm_secret_store" "example-tf-rdp-ca" {
  aws_token_cert_x509 {
    name = "${var.prefix}rdp-ca"
    ca_arn = "arn:aws:acm-pca:us-east-1:12345678:certificate-authority/abcd-1234-defg-5678"
    certificate_template_arn = "arn:aws:acm-pca:::template/BlankEndEntityCertificate_CSRPassthrough/V1"
    issued_cert_ttl_minutes = "480"
    name = "example-ca-name"
    region = "us-east-1"
    signing-algo ="SHA256WITHRSA"
  }
}

# Create RDP (Certificate Based) server
resource "sdm_resource" "example-rdp-cert-based" {
  rdp {
    name = "${var.prefix}rdp-aws-ca"
    hostname = "https://aws.example.com:1234"
    secret_store_id = sdm_secret_store.example-tf-rdp-ca.id
    username = "username"
  }
}

Add AWS CA with the SDKs #

To add an AWS CA with the StrongDM SDKs, please see the SDKs on GitHub:

• Go
• Java
• Python
• Ruby