Boundary Enterprise RDP Session Recording Lab

30min
|
Terraform
Boundary
Vault

This HashiCorp sandbox is designed to accompany the HashiConf at TechXchange hands-on lab. The sandbox is an interactive environments where you can experiment with HashiCorp products without installation or setup.

You can use the sandboxes to:

Learn how products work in a real environment.
Test configurations and commands without affecting your systems.
Explore product features in a safe sandbox.
Follow along with tutorials and documentation.

Launch the Boundary Enterprise Sandbox

Lab overview

This lab walks you through enabling RDP session recording for a Windows Server target using Boundary Enterprise.

The sandbox ships with a working SSH session recording configuration you can use as a reference. Your job is to build the equivalent for RDP:

Create a static credential for the Windows domain account.
Create an RDP target that injects that credential and records the session.
Connect to the target and play the recording back.
Create a storage policy so the recording can be deleted.

A bonus exercise replaces the static credential with dynamic Active Directory credentials generated by Vault's LDAP secrets engine.

These exercises are also available in the sandbox's /home/learner/get-started/exercises/ directory.

Select an exercise tab to view each exercise.

Connect to a Boundary target

What is a Boundary target?

Targets are a Boundary resource that represent a networked service or host that a user can connect to. Targets provide an endpoint with an associated set of permissions for establishing a session. Targets need to be associated with a host to establish a connection.

For example, in the sandbox the following hosts exist:

ubuntu-host, at address ubuntu-host
windows, at address windows-dc

Functionally, a host provides the address where a session should be attempted.

Targets provide further connection details, such as the protocol and port the connection should use. In this sandbox, two examples of targets are ubuntu-target-tcp and northwind-db. Both these targets are for services running on the ubuntu-host machine.

The database target connects on port 5432, while ubuntu-target-tcp sets port 22 as the default port to enable SSH connections.

Boundary Enterprise adds two more target types that support credential injection and session recording: ssh and rdp. The ssh-recording-target-priya target is a preconfigured example of the first. You will build an rdp target yourself in exercise 3.

The following Boundary users are preconfigured for SSH access on the ubuntu-host host:

Priya:
- username: priya
- password: priya_password
Oliver:
- username: oliver
- password: oliver_password
Khalid:
- username: khalid
- The password for this user is contained in a Vault credential

A postgres database is also configured on the ubuntu-host host and is available on port 5432:

Database:
- name: northwind
- username: postgres
- password: postgres

The windows-dc host is a Windows Server instance configured as an Active Directory domain controller for the instruqt.local domain. RDP is configured to allow password access for a static domain account:

DomainUser:
- username: DomainUser
- password: DomainP@ssw0rd!!!
- domain: instruqt.local

The domain controller also hosts a vault-users group that Vault's LDAP secrets engine uses to create and destroy short-lived domain accounts. You can review the domain configuration in the C:\ldif_examples directory on the Windows server.

Access the Boundary Admin UI

You can log in to the Boundary Admin UI in the Boundary Admin UI tab.

To log into the Boundary Admin UI, use the following credentials for the admin user:

Username: admin
Password: password

Or log in as the unprivileged user:

Username: user
Password: password

Within Boundary the following resources are configured:

Org: sandbox org
Project: sandbox project
Host Catalogs:
Host Sets:
Credential Stores:
- ubuntu-host-creds (static)
- vault-credentials (Vault)
Targets:
- boundary-db (Boundary's local database)
- northwind-db (on the ubuntu-host host)
- ubuntu-target-tcp (on the ubuntu-host host)
- ssh-recording-target-priya (on the ubuntu-host host)
Aliases:
Storage bucket:
- recording-test-bucket, backed by the MinIO server

Notice that the windows-host-catalog and windows-host-set exist, but no RDP target uses them yet. That is the gap you will close in this lab.

You can access these targets from the Boundary workstation by configuring the CLI. Targets can also be accessed using the Boundary Desktop Client, which is installed on the workstation desktop.

CLI Access

The shell in the Workstation tab has the Boundary, Vault, and Terraform CLI tools installed.

The following environment variables have been set:

You can log into Boundary from the CLI using the admin credentials:

Username: admin
Password: password

$ boundary authenticate
Please enter the login name (it will be hidden):
Please enter the password (it will be hidden):

Authentication information:
  Account ID:      acctpw_sC5a4GP9JA
  Auth Method ID:  ampw_CzkwJb5RRR
  Expiration Time: Thu, 03 Apr 2025 01:36:55 UTC
  User ID:         u_UURrzGLCik

The token name "default" was successfully stored in the chosen keyring and is not displayed here.

Exercise:

Connect to a target using the CLI

After authentication, you can connect to targets using the boundary connect command.

Connect to the northwind database on the ubuntu-host host:

$ boundary connect postgres northwind
Credentials are being brokered but no -dbname parameter provided. psql may misinterpret another parameter as the database name.
psql (16.8 (Ubuntu 16.8-0ubuntu0.24.04.1))
SSL connection (protocol: TLSv1.3, cipher: TLS_AES_256_GCM_SHA384, compression: off)
Type "help" for help.

postgres=#

When you connect to the ubuntu-target alias it will display the available brokered credentials for the oliver and priya users, and automatically select one of them to log you in as. Copy and paste or type the user's password to connect:

$ boundary connect ssh ubuntu-target
Credentials:
  Credential Source Description: Credentials for oliver user on ubuntu-host host
  Credential Source ID:          credup_XuqoTfBGrj
  Credential Source Name:        oliver-creds
  Credential Store ID:           csst_iHuwhwzstA
  Credential Store Type:         static
  Credential Type:               username_password
  Secret:
        password:   oliver_password
        username:   oliver

  Credential Source Description: Credentials for priya user on ubuntu-host host
  Credential Source ID:          credup_po69wMQRNN
  Credential Source Name:        priya-creds
  Credential Store ID:           csst_iHuwhwzstA
  Credential Store Type:         static
  Credential Type:               username_password
  Secret:
        password:   priya_password
        username:   priya

The authenticity of host 'hst_hi2n8ghvx8 ([127.0.0.1]:45223)' can't be established.
ED25519 key fingerprint is SHA256:kCPyzCG/O2ckQ5zvoxT1O9NTgNz+KNnTf+fDildd0QI.
This key is not known by any other names.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added 'hst_hi2n8ghvx8' (ED25519) to the list of known hosts.
oliver@hst_hi2n8ghvx8's password:
oliver@ubuntu-host$

Select a user to authenticate as by passing additional login parameters to boundary connect ssh:

$ boundary connect ssh ubuntu-target -username priya
priya@hst_hi2n8ghvx8's password:
priya@ubuntu-host$

Connect using the Boundary Desktop Client

The Boundary Desktop Client is installed on the workstation's desktop. You will use it later to open sessions to the RDP target you build, so it is worth getting familiar with it now.

Open the Workstation desktop tab. This tab serves an XFCE desktop running on the Boundary workstation, and hosts both the Boundary Desktop Client and the Remmina RDP client.

Launch the Boundary Desktop Client from the desktop.

Find your controller's public URL in the /home/learner/get-started/public-controller-address file on the workstation, then paste it into the Desktop Client when prompted.

Authenticate to Boundary using the admin user credentials:

Username: admin
Password: password

Click the Connect button next to a target, such as ssh-recording-target-priya.

From the sessions page, click the Shell tab. This will automatically launch the built-in terminal and attempt to open a session.

You should find a running session on the Sessions page. Try terminating the session from here. Because session recording is enabled for ssh-recording-target-priya, verify that a recording was created on the Session Recordings page of the Admin UI.

Note

The Desktop Client's built-in Shell tab only handles SSH. For RDP targets it displays a proxy address and expects you to open the session in a separate RDP client. You will use Remmina, which is also installed on the workstation desktop, for that.

Compare user permissions

Log out of the Boundary Desktop Client by clicking on the admin user dropdown and clicking Sign Out.

On the Sign In page, click the Choose a different scope dropdown and select sandbox org.

Log back in as the unprivileged user:

Org: sandbox org
Username: user
Password: password

What do you notice about this user's permissions? Do you have access to the same set of targets and hosts?

You can learn more about grants and permissions in Boundary in the Permissions in Boundary docs.

Add RDP target credentials

Introduction to credential handling

Two types of credential handling are available in Boundary Enterprise:

Credential brokering
Credential injection

Credential brokering occurs when target credentials are sent directly back to the client for use in their shell. The ubuntu-target-tcp target is configured using credential brokering.

If you request a session using boundary connect:

$ boundary connect -target-name ubuntu-target-tcp -target-scope-name "sandbox project"
Proxy listening information:
  Address:             127.0.0.1
  Connection Limit:    -1
  Expiration:          Thu, 11 Sep 2025 05:50:32 MDT
  Port:                50708
  Protocol:            tcp
  Session ID:          s_V1VU9SRtpS

  Credentials:
    Credential Source Description: Credentials for oliver user on ubuntu-host host
    Credential Source ID:          credup_3GaWPZ3mEj
    Credential Source Name:        oliver-creds
    Credential Store ID:           csst_0CQp4Oo4kx
    Credential Store Type:         static
    Credential Type:               username_password
    Secret:
          password:   oliver_password
          username:   oliver

Then a proxy is opened on the specified port, 50708 in this example. The proxy runs until the connection is manually closed using ctrl+c. The user is then able to connect to the target using their client of choice and the brokered credentials:

$ ssh 127.0.0.1 -p 50708 -l oliver
oliver@127.0.0.1's password:
oliver@ubuntu-host$

Credential brokering is very different from credential injection, which is available for Enterprise or HCP deployments. Credential injection requires an ssh or rdp target type. Compare the target types for ubuntu-target-tcp and ssh-recording-target-priya:

$ boundary search -resource targets -query "name='ubuntu-target-tcp' OR name='ssh-recording-target-priya'"

Target information:
  ID:                    tssh_vE4VcjEMs6
    Scope ID:            p_RwEjU2ZTlT
    Version:             2
    Type:                ssh
    Name:                ssh-recording-target-priya
    Description:         SSH target
    Address:             ubuntu-host

  ID:                    ttcp_RVWygmdtmr
    Scope ID:            p_RwEjU2ZTlT
    Version:             3
    Type:                tcp
    Name:                ubuntu-target-tcp
    Description:         SSH target for ubuntu-host

Note that ubuntu-target-tcp is type tcp, while ssh-recording-target-priya is type ssh. For credential injection to work, the target must be assigned injected application credentials:

$ boundary targets read -id tssh_vE4VcjEMs6

Target information:
  Address:                    ubuntu-host
  Description:                SSH target
  Egress Worker Filter:       "egress" in "/tags/type"
  ID:                         tssh_vE4VcjEMs6
  Name:                       ssh-recording-target-priya
  Type:                       ssh

  Injected Application Credential Sources:
    Credential Store ID:      csvlt_gfwRVvu1S7
    ID:                       clvlt_sD2MoO0sCd

  Attributes:
    Default Port:             22
    Enable Session Recording: true
    Storage Bucket ID:        sb_5PyYvthvUt

When a session is started, the attached credential is injected directly into the session, and never passed to the end user's shell:

$ boundary connect ssh priya
priya@ubuntu-host$

Brokered credentials are always passed back to the client's shell, even when Boundary passes them on your behalf to start a session. Injected credentials are never sent back to the user. They are used by Boundary to initiate the session, and then the client is connected.

Session recording depends on credential injection. Boundary can only record a session it establishes itself, which is why ssh and rdp targets are the only types that support it.

RDP credentials require a domain

RDP credential injection has one requirement that SSH does not: the credential must include a domain alongside the username and password. Boundary uses the domain value to decide how to authenticate to the Windows host.

Use the Active Directory domain name, such as instruqt.local, for a domain-joined account. Boundary authenticates using Kerberos.
Use a single period (.) for a local Windows account that is not joined to a domain. This tells Boundary to authenticate using NTLMv2 against the target's local account database.

The DomainUser account on windows-dc is a domain account in instruqt.local, so this lab uses the domain name.

This means a plain username_password credential will not work for an RDP target. You need the username_password_domain credential type.

Exercise

Create a static credential store in the sandbox project scope, then add a username, password, and domain credential for the DomainUser account.

Use these values:

Credential store name: windows-host-creds
Credential name: windows-creds
Username: DomainUser
Password: DomainP@ssw0rd!!!
Domain: instruqt.local

Select the sandbox org scope, then the sandbox project project.
Select Credential Stores from the left navigation panel, then click New Credential Store.
Enter the following details and click Save.
- Name: windows-host-creds
- Description: Credentials for windows target
- Type: Static
From the windows-host-creds page, select the Credentials tab and click New.
Enter the following details for the credential.
- Name: windows-creds
- Description: Credentials for the static DomainUser account on the windows-dc host
- Type: Username, Password & Domain
- Username: DomainUser
- Password: DomainP@ssw0rd!!!
- Domain: instruqt.local
Click Save.

Authenticate to Boundary and export the project scope ID.

$ export PROJECT_ID=$(boundary scopes list -scope-id $(boundary scopes list -format json | jq -r '.items[] | select(.name=="sandbox org") | .id') -format json | jq -r '.items[] | select(.name=="sandbox project") | .id') && echo $PROJECT_ID

Create the static credential store.

$ export CRED_STORE_ID=$(boundary credential-stores create static \
  -scope-id $PROJECT_ID \
  -name "windows-host-creds" \
  -description "Credentials for windows target" \
  -format json | jq -r '.item.id') && echo $CRED_STORE_ID

Export the password rather than passing it on the command line.

$ export RDP_PASSWORD='DomainP@ssw0rd!!!'

Create the credential. Note the username-password-domain subcommand and the -domain flag.

$ export RDP_CREDENTIAL_ID=$(boundary credentials create username-password-domain \
  -credential-store-id $CRED_STORE_ID \
  -name "windows-creds" \
  -description "Credentials for the static DomainUser account on the windows-dc host" \
  -username DomainUser \
  -password env://RDP_PASSWORD \
  -domain "instruqt.local" \
  -format json | jq -r '.item.id') && echo $RDP_CREDENTIAL_ID

Verify the credential type.

$ boundary credentials read -id $RDP_CREDENTIAL_ID
Credential information:
  Created Time:          Thu, 11 Sep 2025 03:57:11 UTC
  Credential Store ID:   csst_0CQp4Oo4kx
  Description:           Credentials for the static DomainUser account on the windows-dc host
  ID:                    credupd_Dfg7Sc94It
  Name:                  windows-creds
  Type:                  username_password_domain

  Attributes:
    Domain:              instruqt.local
    Username:            DomainUser

Keep the $PROJECT_ID and $RDP_CREDENTIAL_ID variables. You will use them in the next exercise.

The sandbox was configured using the Boundary Terraform provider. Open the Controller editor tab and view the files in /home/boundary-admin/boundary/terraform to see how the existing resources are defined.

Add the following resources to credentials.tf.

resource "boundary_credential_store_static" "windows_target_creds" {
  name        = "windows-host-creds"
  description = "Credentials for windows target"
  scope_id    = boundary_scope.project.id
}

resource "boundary_credential_username_password_domain" "windows_rdp_creds" {
  name                = "windows-creds"
  description         = "Credentials for the static DomainUser account on the windows-dc host"
  credential_store_id = boundary_credential_store_static.windows_target_creds.id
  username            = "DomainUser"
  password            = "DomainP@ssw0rd!!!"
  domain              = "instruqt.local"
}

Note

Use boundary_credential_username_password_domain, not boundary_credential_username_password. RDP credential injection requires the domain attribute, and a target rejects an injected credential that does not supply one.

Apply the change from the Controller tab's terminal.

Change into the terraform configuration folder.

$ cd /home/boundary-admin/boundary/terraform/

Apply the changes, passing the .tfvars file.

$ terraform apply -var-file=boundary.tfvars --auto-approve

Tip

If you want to experiment with Vault, you can access it from the workstation terminal using the root token in the /home/learner/vault directory, which is also available as an environment variable in /home/learner/.bashrc.

```shell-session
$ source .bashrc
$ vault login $VAULT_ROOT_TOKEN
```

After you create the credential, move on to exercise 3.

Create an RDP target with session recording

This is the main exercise. RDP targets in Boundary Enterprise enable the following features:

Credential injection
RDP session recording

Recording an RDP session requires more moving parts than a TCP proxy, so it is worth understanding what each one does before you build the target.

An rdp target type. Only ssh and rdp targets support credential injection and session recording.
An injected credential. Boundary establishes the session itself, using the windows-creds credential you created in exercise 2.
An egress worker filter. The egress worker sits in the same network as the target. It buffers the recording to recording_storage_path on local disk and uploads it to the storage bucket. Session recording does not work without one.
An ingress worker filter. The ingress worker terminates the client's connection and proxies it to the egress worker. This lab uses multi-hop sessions, so the RDP target specifies both filters.
A storage bucket. The recording-test-bucket bucket, backed by the MinIO server, is already configured in the sandbox org scope.
ffmpeg on the worker. RDP recordings are video, so the worker needs ffmpeg to process them. Both workers in this sandbox already have it installed.

The workers in this sandbox carry these tags:

egress-worker:  type = ["worker", "egress", "minio", "vault"]
ingress-worker: type = ["worker", "ingress"]

So the filter expressions you need are:

"egress" in "/tags/type"
"ingress" in "/tags/type"

Exercise

Create an RDP target with the following configuration:

Name: windows-rdp
Type: rdp
Default port: 3389
Host source: windows-host-set
Egress worker filter: "egress" in "/tags/type"
Ingress worker filter: "ingress" in "/tags/type"
Injected application credential: windows-creds
Session recording: enabled, using the recording-test-bucket storage bucket
Alias: sandbox.windows

Navigate to the sandbox org scope, and select the sandbox project project.
Select the Targets page and click New Target.
Fill out the New Target form.
- Name: windows-rdp
- Description: Windows AD RDP target
- Type: RDP
- Default Port: 3389
- Maximum Connections: -1
- Aliases: sandbox.windows
Click Save.
Click the Host Sources tab, then click Add Host Sources.
Check the box next to windows-host-set, then click Add Host Sources.
Click the Workers tab.
Click Edit worker filter for Egress workers and enter:
```
"egress" in "/tags/type"
```
Click Save.
Click Edit worker filter for Ingress workers and enter:
```
"ingress" in "/tags/type"
```
Click Save.
Select the Injected Application Credentials tab.
Click +Add Injected Application Credentials, check the box next to windows-creds, then click Add Injected Application Credentials.
Navigate back to the windows-rdp Details page.
Under Session Recording, click Enable recording.
On the Enable Session Recording for Target page, toggle the switch next to Record sessions for this target.
For Storage buckets, select recording-test-bucket.
Click Save.

Under the windows-rdp Details page, recording-test-bucket should now be listed under Session Recording.

Export the ID of the windows-host-set host set.

$ export WINDOWS_HOST_SET_ID=$(boundary host-sets list -host-catalog-id $(boundary host-catalogs list -scope-id $PROJECT_ID -format json | jq -r '.items[] | select(.name=="windows-host-catalog") | .id') -format json | jq -r '.items[] | select(.name=="windows-host-set") | .id') && echo $WINDOWS_HOST_SET_ID

Export the ID of the storage bucket.

$ export STORAGE_BUCKET_ID=$(boundary storage-buckets list -scope-id global -recursive -format json | jq -r '.items[] | select(.name=="recording-test-bucket") | .id') && echo $STORAGE_BUCKET_ID

Create the target. Note the rdp subcommand, the two worker filters, and the session recording attributes.

$ export RDP_TARGET_ID=$(boundary targets create rdp -scope-id $PROJECT_ID \
  -name "windows-rdp" \
  -description "Windows AD RDP target" \
  -default-port 3389 \
  -session-connection-limit -1 \
  -egress-worker-filter '"egress" in "/tags/type"' \
  -ingress-worker-filter '"ingress" in "/tags/type"' \
  -storage-bucket-id $STORAGE_BUCKET_ID \
  -enable-session-recording true \
  -with-alias-value "sandbox.windows" \
  -format json | jq -r '.item.id') && echo $RDP_TARGET_ID

Add the host set as a host source.

$ boundary targets add-host-sources -id $RDP_TARGET_ID -host-source $WINDOWS_HOST_SET_ID

Add the credential you created in exercise 2 as an injected application credential.

$ boundary targets add-credential-sources -id $RDP_TARGET_ID \
  -injected-application-credential-source $RDP_CREDENTIAL_ID

Verify the finished target.

$ boundary targets read -id $RDP_TARGET_ID
Target information:
  Description:                Windows AD RDP target
  Egress Worker Filter:       "egress" in "/tags/type"
  ID:                         trdp_Ehe8AQxTcp
  Ingress Worker Filter:      "ingress" in "/tags/type"
  Name:                       windows-rdp
  Session Connection Limit:   -1
  Type:                       rdp

  Aliases:
    ID:                       alt_KVDgkMbVzE
    Value:                    sandbox.windows

  Host Sources:
    Host Catalog ID:          hcst_pMYJm0eqzu
    ID:                       hsst_ivm9C0lPfg

  Injected Application Credential Sources:
    Credential Store ID:      csst_0CQp4Oo4kx
    ID:                       credupd_Dfg7Sc94It

  Attributes:
    Default Port:             3389
    Enable Session Recording: true
    Storage Bucket ID:        sb_5PyYvthvUt

Add the following resources to targets.tf in /home/boundary-admin/boundary/terraform.

Worker filter expressions must be written using escape syntax in HCL.

resource "boundary_target" "windows_rdp" {
  name         = "windows-rdp"
  description  = "Windows AD RDP target"
  type         = "rdp"
  default_port = "3389"
  scope_id     = boundary_scope.project.id

  host_source_ids = [
    boundary_host_set_static.windows_host_set.id
  ]

  egress_worker_filter  = "\"egress\" in \"/tags/type\""
  ingress_worker_filter = "\"ingress\" in \"/tags/type\""

  injected_application_credential_source_ids = [
    boundary_credential_username_password_domain.windows_rdp_creds.id
  ]

  enable_session_recording = true
  storage_bucket_id        = boundary_storage_bucket.minio_bucket.id
}

Create an alias so users can connect with boundary connect rdp sandbox.windows instead of the target's generated ID. Because this target uses a host source rather than a direct address, set authorize_session_host_id so the alias resolves to a specific host.

resource "boundary_alias_target" "windows_target_alias" {
  name                      = "windows-target-alias"
  description               = "Target alias to windows_rdp target"
  scope_id                  = "global"
  value                     = "sandbox.windows"
  destination_id            = boundary_target.windows_rdp.id
  authorize_session_host_id = boundary_host_static.windows_host.id
}

Apply the change from the Controller tab's terminal.

Change into the terraform configuration folder.

$ cd /home/boundary-admin/boundary/terraform/

Apply the changes, passing the .tfvars file.

$ terraform apply -var-file=boundary.tfvars --auto-approve

Connect to the RDP target

Open the Workstation desktop tab and launch the Boundary Desktop Client.

Authenticate using the admin credentials, then find windows-rdp on the Targets page and click Connect.

The Desktop Client displays a proxy address, such as 127.0.0.1:45223. Copy it.

The Desktop Client cannot open an RDP session on its own, so launch Remmina from the same desktop:

Select the RDP protocol.
Enter the proxy address that Boundary assigned, for example 127.0.0.1:45223.
Leave the username and password blank. Boundary injects them into the session.
Accept the certificate warning if prompted.

You can do the same thing from the Workstation terminal tab using the alias:

$ boundary connect rdp sandbox.windows
Proxy listening information:
  Address:             127.0.0.1
  Connection Limit:    -1
  Expiration:          Thu, 03 Apr 2025 01:36:55 UTC
  Port:                45223
  Protocol:            tcp
  Session ID:          s_1kwvcM4iOU

Then connect Remmina to the proxy address the command prints.

Once the Windows desktop loads, perform a few actions you will recognize during playback, such as opening File Explorer or a PowerShell prompt. Then close the RDP client and cancel the session from the Desktop Client's Sessions page.

Note

You are running an RDP client inside an RDP session, since the Workstation desktop tab is itself served over RDP through Guacamole. Performance is noticeably slower than a native client. If you prefer, install the Boundary Desktop Client on your local machine, point it at the URL in /home/learner/get-started/public-controller-address, and use your own RDP client instead.

Play back the recording

Open the Boundary Admin UI and authenticate as the admin user.

From the global scope, navigate to the Session Recordings page.

Each recording lists the following details:

Time
Status
User
Target
Duration

Click View next to your recording, then click Play for Channel 1.

After the recording loads, hover over the video player and click the play button to start playback. You should see the actions you performed in the Windows session.

Note the Channel details on the right, which display the duration and bytes up / bytes down.

Note

A recording's status stays started until the session ends and the egress worker finishes uploading it to MinIO. If the recording is not available immediately, cancel the session and wait a few moments before refreshing.

Enforce compliance standards with storage policies

Session recordings are used to enforce compliance standards for your organization. If you must comply with HIPAA or SOC standards, storage policies ensure records of sessions are retained for the required amount of time.

By default, session recordings are set with a retention policy of Forever, and cannot be deleted. Try deleting the recording you created in exercise 3 and you will find the option unavailable.

To delete session recordings, you must define a storage policy that allows for zero retention and attach it to the org scope. In a real-world scenario, you would retain your recordings for an amount of time defined by your organization.

Exercise

Create a retention policy that allows you to delete session recordings, attach it to the sandbox org scope, then delete your RDP recording.

Navigate to the Storage Policies page.
- Select the sandbox org org from the top navigation bar.
- Select Storage Policies from the left navigation panel.
Click New Storage Policy and fill in the form details:
- Name: do-not-retain
- Description: delete after 1 day
- Retention Policy: Do not protect, allow deletion at any time
- Deletion Policy: Custom
- Delete after: 1 days
Click Save.
Add the storage policy to the org.
- From the left navigation panel, select Org Settings.
- Click Add Storage Policy.
- From the Add Storage Policy page, select the do-not-retain policy.
Click Save.
Re-apply the storage policy to the session recording.
- Navigate back to the Global scope and select Session Recordings from the left navigation panel.
- Open a recording by clicking View next to the recording. Under the Manage dropdown, select Re-apply storage policy.
Delete the session recording.
- Click the Manage dropdown again, then select Delete recording and confirm the operation by clicking OK.

Repeat this process for any remaining recordings.

Export the sandbox org scope ID.

$ export ORG_ID=$(boundary scopes list -format json | jq -r '.items[] | select(.name=="sandbox org") | .id') && echo $ORG_ID

Create a storage policy that allows deletion after one day.

$ export STORAGE_POLICY_ID=$(boundary policies create storage \
  -scope-id $ORG_ID \
  -name "do-not-retain" \
  -description "delete after 1 day" \
  -delete-after-days 1 \
  -format json | jq -r '.item.id') && echo $STORAGE_POLICY_ID

Attach the policy to the sandbox org scope.

$ boundary scopes attach-storage-policy \
  -id $ORG_ID \
  -storage-policy-id $STORAGE_POLICY_ID

List your session recordings and select its ID.

$ boundary session-recordings list -scope-id global -recursive -format json | jq -r '.items[] | .id'

Re-apply the policy to one of them. A recording created before the policy was attached keeps its original retention setting until you re-apply.

$ boundary session-recordings reapply-storage-policy -id sr_MvGDLGZXOm

Delete the recording.

$ boundary session-recordings delete -id sr_MvGDLGZXOm
The delete operation completed successfully.

Add the following resources to storage.tf in /home/boundary-admin/boundary/terraform.

resource "boundary_policy_storage" "delete_policy" {
  name              = "do-not-retain"
  description       = "delete after 1 day"
  scope_id          = boundary_scope.org.id
  delete_after_days = 1
}

resource "boundary_scope_policy_attachment" "attach_delete_policy" {
  scope_id  = boundary_scope.org.id
  policy_id = boundary_policy_storage.delete_policy.id
}

Apply the change from the Controller tab's terminal.

Change into the terraform configuration folder.

$ cd /home/boundary-admin/boundary/terraform/

Apply the changes, passing the .tfvars file.

$ terraform apply -var-file=boundary.tfvars --auto-approve

Terraform manages the policy and its attachment, but re-applying a policy to an existing recording and deleting that recording are runtime operations. Use the Admin UI or the CLI for those steps.

Tip

Attaching a storage policy to the org before any recordings exist makes every recording eligible for deletion from the moment it is created, which avoids the re-apply step entirely.

Bonus exercise

Implement a storage policy that conforms to SOC 2 retention requirements (7 years):

Retention Policy: SOC 2 (7 years)
Deletion Policy: Custom, delete after 2657 days
Toggle the switch beside Allow orgs to override

Review the sandbox architecture

The /home/learner/get-started/ARCHITECTURE.md file describes the architecture of this sandbox environment.

This includes the following components:

Boundary controller (self-hosted postgres)
Ingress Boundary worker
Egress Boundary worker
Vault server
MinIO storage backend
Ubuntu target
Windows Server Active Directory domain controller
Guacamole workstation, which serves the workstation desktop over RDP

What are the requirements of these components? How must they be configured to create a functional and secure Boundary deployment? How do the ingress and egress workers function in a multi-hop sessions deployment, and how can this provide enhanced security for your network?

Consider the RDP target you built in exercise 3. Which worker actually recorded the session, and why does that worker need ffmpeg installed? What would happen if you removed the egress worker filter from the target?

You can check the controller or worker configurations by examining the /etc/boundary.d/boundary.hcl file on those hosts. Note the recording_storage_path setting in the egress worker's configuration.

Use the following documentation to deepen your understanding:

Create an RDP target with dynamic LDAP credentials

The windows-rdp target you built in exercise 3 injects a static credential. Every session runs as the same DomainUser account, and that account's password lives in Boundary indefinitely.

Vault's LDAP secrets engine removes both problems. Vault creates a new Active Directory user for each session, hands the credential to Boundary, and deletes the account when the lease expires. No long-lived password is stored anywhere, and every session is attributable to a distinct account in the domain's audit log.

What is already configured

The Vault server in this sandbox has the LDAP secrets engine enabled and configured against the windows-dc domain controller during track setup:

Secrets engine mounted at ldap/
Schema ad, bound as cn=Administrator,cn=Users,dc=instruqt,dc=local over LDAPS
A role named ldap-dynamic at ldap/creds/ldap-dynamic, which creates a user named v_user_<unix_timestamp> and adds it to the vault-users group
The bind password rotated with vault write -f ldap/rotate-root

Boundary's Vault credential store, vault-credentials, is also already configured in the sandbox project scope. Its token carries the ldap-rw policy, which grants access to ldap/creds/*.

You can confirm the role works from the workstation terminal:

$ source .bashrc
$ vault login $VAULT_ROOT_TOKEN
$ vault read ldap/creds/ldap-dynamic

Key                    Value
---                    -----
lease_id               ldap/creds/ldap-dynamic/nRHFqLKGCLdjEWZmJ8mGWvBd
lease_duration         1h
lease_renewable        true
distinguished_names    [CN=v_user_1756400000,CN=Users,DC=instruqt,DC=local]
password               kRLYm2rzTPWWDrTgUyBAoK9AWJUx1YrErHfDrFvpU8Rl5xNMhTx2
username               v_user_1756400000

Exercise

Create a Vault credential library that reads from the ldap-dynamic role, then build a second RDP target that injects it. Keeping your static target from exercise 3 lets you connect to both and compare the account each session runs as.

Use these values:

Credential library name: ldap-dynamic
Credential store: vault-credentials
Vault path: ldap/creds/ldap-dynamic
HTTP method: GET
Credential type: username_password
Target name: windows-rdp-dynamic
Alias: sandbox.windows-dynamic

Navigate to the sandbox project scope and select Credential Stores.
Select vault-credentials, then select the Credential Libraries tab. Click the Manage dropdown and select New Credential Library.
Enter the following details and click Save.
- Name: ldap-dynamic
- Description: Dynamic Active Directory credentials from the Vault LDAP secrets engine
- Type: Generic
- Vault Path: ldap/creds/ldap-dynamic
- HTTP Method: GET
- Credential Type: Username & Password
- Username attribute: username
- Password attribute: password
Create a second RDP target following the same steps as exercise 3, but name it windows-rdp-dynamic with the alias sandbox.windows-dynamic.
On the Injected Application Credentials tab for windows-rdp-dynamic, add the ldap-dynamic credential library instead of the windows-creds credential.

Export the Vault credential store ID.

$ export VAULT_CRED_STORE_ID=$(boundary credential-stores list -scope-id $PROJECT_ID -format json | jq -r '.items[] | select(.name=="vault-credentials") | .id') && echo $VAULT_CRED_STORE_ID

Create the credential library.

$ export LDAP_CRED_LIBRARY_ID=$(boundary credential-libraries create vault-generic \
  -credential-store-id $VAULT_CRED_STORE_ID \
  -name "ldap-dynamic" \
  -description "Dynamic Active Directory credentials from the Vault LDAP secrets engine" \
  -vault-path "ldap/creds/ldap-dynamic" \
  -vault-http-method GET \
  -credential-type username_password \
  -format json | jq -r '.item.id') && echo $LDAP_CRED_LIBRARY_ID

Create the second RDP target.

$ export DYNAMIC_RDP_TARGET_ID=$(boundary targets create rdp -scope-id $PROJECT_ID \
  -name "windows-rdp-dynamic" \
  -description "Windows AD RDP target with dynamic Vault credentials" \
  -default-port 3389 \
  -session-connection-limit -1 \
  -egress-worker-filter '"egress" in "/tags/type"' \
  -ingress-worker-filter '"ingress" in "/tags/type"' \
  -storage-bucket-id $STORAGE_BUCKET_ID \
  -enable-session-recording true \
  -with-alias-value "sandbox.windows-dynamic" \
  -format json | jq -r '.item.id') && echo $DYNAMIC_RDP_TARGET_ID

Attach the host set to the target.

$ boundary targets add-host-sources -id $DYNAMIC_RDP_TARGET_ID -host-source $WINDOWS_HOST_SET_ID

Attach the credential library to the target.

$ boundary targets add-credential-sources -id $DYNAMIC_RDP_TARGET_ID \
  -injected-application-credential-source $LDAP_CRED_LIBRARY_ID

Add the credential library to credentials.tf.

Vault LDAP credentials use the generic boundary_credential_library_vault resource pointed at an ldap/creds/<role> path. There is no LDAP-specific credential library resource in the Boundary provider.

resource "boundary_credential_library_vault" "vault_ldap_cred_library" {
  name                = "ldap-dynamic"
  description         = "Dynamic Active Directory credentials from the Vault LDAP secrets engine"
  credential_store_id = boundary_credential_store_vault.vault_host_cred_store.id
  path                = "ldap/creds/ldap-dynamic"
  http_method         = "GET"
  credential_type     = "username_password"

  credential_mapping_overrides = {
    username_attribute = "username"
    password_attribute = "password"
  }
}

Add the second target to targets.tf.

resource "boundary_target" "windows_rdp_dynamic" {
  name         = "windows-rdp-dynamic"
  description  = "Windows AD RDP target with dynamic Vault credentials"
  type         = "rdp"
  default_port = "3389"
  scope_id     = boundary_scope.project.id

  host_source_ids = [
    boundary_host_set_static.windows_host_set.id
  ]

  egress_worker_filter  = "\"egress\" in \"/tags/type\""
  ingress_worker_filter = "\"ingress\" in \"/tags/type\""

  injected_application_credential_source_ids = [
    boundary_credential_library_vault.vault_ldap_cred_library.id
  ]

  enable_session_recording = true
  storage_bucket_id        = boundary_storage_bucket.minio_bucket.id
}

resource "boundary_alias_target" "windows_dynamic_target_alias" {
  name                      = "windows-dynamic-target-alias"
  description               = "Target alias to windows_rdp_dynamic target"
  scope_id                  = "global"
  value                     = "sandbox.windows-dynamic"
  destination_id            = boundary_target.windows_rdp_dynamic.id
  authorize_session_host_id = boundary_host_static.windows_host.id
}

Apply the change from the Controller tab's terminal.

Change into the terraform configuration folder.

$ cd /home/boundary-admin/boundary/terraform/

Apply the changes, passing the .tfvars file.

$ terraform apply -var-file=boundary.tfvars --auto-approve

Compare the two targets

Connect to sandbox.windows-dynamic the same way you connected in exercise 3, using the Boundary Desktop Client and Remmina.

$ boundary connect rdp sandbox.windows-dynamic

Once the desktop loads, open a PowerShell prompt and check which account you are running as:

PS C:\Users\v_user_1756400000> whoami
instruqt\v_user_1756400000

Compare that to a session opened against sandbox.windows, which always reports instruqt\domainuser.

You can watch Vault create and destroy the account. On the Windows server, open Active Directory Users and Computers and look at the vault-users group in the Users container while a dynamic session is open, then look again after the lease expires.

Both targets record to the same storage bucket, so you can play back sessions from either one on the Session Recordings page and see the different accounts in the recorded desktop.

Why this matters

No stored secret. Boundary never holds a Windows password. It requests one from Vault at session authorization time.
Attribution. Every session maps to a unique domain account, so the Windows event log and your session recordings agree on who did what.
Automatic revocation. When the Vault lease expires, the account is deleted from Active Directory. A leaked credential stops working on its own.

Resources

You can experiment with the Boundary Enterprise sandbox to learn in a practical way by following examples from tutorials and documentation.

Here are some suggestions for tutorials and documentation content you can explore with the Boundary Enterprise sandbox.

Learn how to enable session recording with S3-compatible storage
Learn how to enable session recording with AWS and Vault
Review the session recording domain model
Learn how to manage recorded sessions
Discover how to integrate Vault with Boundary
Learn about the Vault LDAP secrets engine
Learn how to manage Self-managed Boundary resources
Learn how to use Dynamic host catalogs on AWS
Learn how to set up OIDC authentication with Auth0
Learn how to manage workers
Become familiar with the Boundary CLI commands
Discover how to Troubleshoot Boundary: Common error messages

Collection Overview

TechXchange

Explore tutorial library