diff --git a/website/content/docs/commands/credentials/create.mdx b/website/content/docs/commands/credentials/create.mdx
index c06bb3bced..06a9d2e783 100644
--- a/website/content/docs/commands/credentials/create.mdx
+++ b/website/content/docs/commands/credentials/create.mdx
@@ -2,7 +2,7 @@
layout: docs
page_title: credentials create - Command
description: >-
- The "credentials create" command creates new credential resources. You can create JSON, SSH private key, and username-password credentials.
+ The "credentials create" command creates new credential resources. Available types are json, ssh-private-key, username-password, and username-password-domain.
---
# credentials create
@@ -76,7 +76,7 @@ You can also specify the credential store using the **BOUNDARY_CREDENTIAL_STORE_
#### Usages by type
-The available types are `json`, `ssh-private-key`, and `username-password`.
+The available types are `json`, `ssh-private-key`, `username-password`, and `username-password-domain`.
@@ -199,6 +199,48 @@ The following options are specific to username password credentials in addition
This value can be a reference to a file on disk (`file://`) or an environment variable (`env://`) from which Boundary reads the value.
- `-username` `(string: "")` - The username associated with the credential.
+
+
+
+The `credentials create username-password-domain` command lets you create a username password domain credential type for Active Directory authentication.
+
+Username password domain credentials are primarily used with RDP targets for credential injection.
+
+#### Example
+
+The following example creates a username password domain credential in a credential store with the ID `csst_1234567890`:
+
+```shell-session
+boundary credentials create username-password-domain \
+ -credential-store-id csst_1234567890 \
+ -username administrator \
+ -password env://ADMIN_PASSWORD \
+ -domain company.com
+```
+
+#### Usage
+
+
+
+```shell-session
+boundary credentials create username-password-domain [options] [args]
+```
+
+
+
+#### Username password domain credential options
+
+The following options are specific to username password domain credentials in addition to the command options:
+
+- `domain` `(string: "")` - The Active Directory domain name. If you include the domain in the `username` field, Boundary automatically fills in the domain information.
+
+ For example, if you enter `admin@mydomain` or `mydomain\admin` in the `username` field, Boundary automatically completes the `domain` field with `mydomain`.
+
+- `password` `(string: "")` - The password associated with the credential. This value can be a reference to a file on disk (file://) or an environment variable (env://) from which Boundary reads the value.
+
+- `username` `(string: "")` - The username associated with the credential. This value can include domain information in `username@domain` or `domain\username` format.
+
+
diff --git a/website/content/docs/commands/credentials/update.mdx b/website/content/docs/commands/credentials/update.mdx
index 39de707547..9f59cc1dc0 100644
--- a/website/content/docs/commands/credentials/update.mdx
+++ b/website/content/docs/commands/credentials/update.mdx
@@ -77,7 +77,7 @@ If you don't specify a version, the command performs a check-and-set automatical
#### Usages by type
-The available types are `json`, `ssh-private-key`, and `username-password`.
+The available types are `json`, `ssh-private-key`, `username-password`, and `username-password-domain`.
@@ -202,6 +202,45 @@ The following options are specific to username password credentials in addition
This value can be a reference to a file on disk (`file://`) or an environment variable (`env://`) from which Boundary reads the value.
- `-username` `(string: "")` - The username associated with the credential.
+
+
+
+The `credentials update username-password-domain` command lets you update an existing username password domain credential type.
+
+Username password domain credentials are primarily used with RDP targets for credential injection.
+
+#### Example
+
+The following example updates a username password domain credential with the ID `csst_1234567890`:
+
+```shell-session
+boundary credentials update username-password-domain \
+ -id csst_1234567890 \
+ -name devops \
+ -description "For DevOps usage" \
+```
+
+#### Usage
+
+
+
+```shell-session
+boundary credentials update username-password-domain [options] [args]
+```
+
+
+#### Username password domain credential options
+
+The following options are specific to username password domain credentials in addition to the command options:
+
+- `domain` `(string: "")` - The Active Directory domain name. If you include the domain in the `username` field, Boundary automatically fills in the domain information.
+
+ For example, if you enter `admin@mydomain` or `mydomain\admin` in the `username` field, Boundary automatically completes the `domain` field with `mydomain`.
+
+- `password` `(string: "")` - The password associated with the credential. This value can be a reference to a file on disk (file://) or an environment variable (env://) from which Boundary reads the value.
+
+- `username` `(string: "")` - The username associated with the credential. This value can include domain information in `username@domain` or `domain\username` format.
+
diff --git a/website/content/docs/commands/targets/create.mdx b/website/content/docs/commands/targets/create.mdx
index 79bd77b417..c5b8ffe45a 100644
--- a/website/content/docs/commands/targets/create.mdx
+++ b/website/content/docs/commands/targets/create.mdx
@@ -29,7 +29,8 @@ $ boundary targets create [type] [sub command] [options] [args]
Please see the typed subcommand help for detailed usage information.
Subcommands:
- ssh Create a ssh-type target (HCP only)
+ rdp Create an rdp-type target (HCP & Boundary Enterprise only)
+ ssh Create a ssh-type target (HCP & Boundary Enterprise only)
tcp Create a tcp-type target
```
@@ -37,9 +38,59 @@ Subcommands:
### Usages by type
-You can create SSH or TCP targets.
+You can create RDP, SSH, or TCP targets.
+
+
+The `targets create rdp` command lets you create RDP targets.
+
+#### Example
+
+This example creates an RDP target with the name `admindc` and the description `RDP target for Admin Domain Controller`:
+
+```shell-session
+$ boundary targets create rdp -name admindc -description "RDP target for Admin Domain Controller"
+```
+
+#### Usage
+
+
+
+```shell-session
+$ boundary targets create rdp [options] [args]
+```
+
+
+
+#### RDP target options
+
+- `-address=` - An optional valid network address for the target to connect to.
+You cannot use an address alongside host sources.
+
+ If you set a target address for RDP targets that use Kerberos authentication, use the target's hostname and append the domain to it, for example `target-hostname.mydomain.com`. For RDP targets that use NTLM authentication, set the target address to the target's IP address.
+- `-default-client-port=` - The default client port on the target.
+- `-default-port=` - The default port on the target.
+Due to a port conflict on modern Windows operating systems (Windows 11+, Windows Server 2025), transparent sessions cannot use the default RDP port `3389`.
+You must configure a custom port to use transparent sessions with RDP targets.
+
+ Refer to [Using transparent sessions with RDP on Windows](/boundary/docs/credentials/rdp-testing-and-compatibility-matrix#using-transparent-sessions-with-rdp-on-windows) for more information about configuring a custom port for transparent sessions.
+- `-egress-worker-filter=` - A Boolean expression that filters which egress workers can process sessions for the target.
+- `-ingress-worker-filter=` - A Boolean expression that filters which ingress workers can process sessions for the target.
+- `-session-connection-limit=` - The maximum number of connections allowed for a session.
+A value of `-1` means the connections are unlimited.
+- `-session-max-seconds=` - The maximum lifetime of the session, including all connections.
+You can specify an integer number of seconds or a duration string.
+If you do not specfiy a maximum duration, Boundary uses the default value of 8 hours (28800 seconds).
+- `-with-alias-authorize-session-host-id=` - The host ID that an alias uses to authorize sessions for the target.
+- `-with-alias-scope-id=` - The scope ID that you want to create the target and alias in.
+The default is `global`.
+At this time, aliases are only supported for the global scope.
+- `-with-alias-value=` - The value of the alias that you want to use to represent the target.
+Use this parameter to create the alias and target, and associate them with each other, at the same time.
+
+
+
The `targets create ssh` command lets you create SSH targets.
@@ -133,4 +184,4 @@ Use this parameter to create the alias and target, and associate them with each
-@include 'cmd-option-note.mdx'
\ No newline at end of file
+@include 'cmd-option-note.mdx'
diff --git a/website/content/docs/commands/targets/update.mdx b/website/content/docs/commands/targets/update.mdx
index f2a118d911..4219274495 100644
--- a/website/content/docs/commands/targets/update.mdx
+++ b/website/content/docs/commands/targets/update.mdx
@@ -29,7 +29,8 @@ $ boundary targets update [type] [sub command] [options] [args]
Please see the typed subcommand help for detailed usage information.
Subcommands:
- ssh Update a ssh-type target (HCP only)
+ rdp Update an rdp-type target (HCP & Boundary Enterprise only)
+ ssh Update a ssh-type target (HCP & Boundary Enterprise only)
tcp Update a tcp-type target
```
@@ -37,9 +38,52 @@ Subcommands:
### Usages by type
-You can update SSH or TCP targets.
+You can update RDP, SSH, or TCP targets.
+
+
+The `targets update rdp` command lets you update existing RDP targets.
+
+#### Example
+
+This example updates an RDP target with the id `rdp_1234567890` to add the name `devops` and the description `RDP target for DevOps`:
+
+```shell-session
+$ boundary targets update rdp -id trdp_1234567890 -name "devops" -description "RDP target for DevOps"
+```
+
+#### Usage
+
+
+
+```shell-session
+$ boundary targets update rdp [options] [args]
+```
+
+
+
+#### RDP target options
+
+- `-address=` - An optional valid network address for the target to connect to.
+You cannot use an address alongside host sources.
+
+ If you set a target address for RDP targets that use Kerberos authentication, use the target's hostname and append the domain to it, for example `target-hostname.mydomain.com`. For RDP targets that use NTLM authentication, set the target address to the target's IP address.
+- `-default-client-port=` - The default client port on the target.
+- `-default-port=` - The default port on the target.
+Due to a port conflict on modern Windows operating systems (Windows 11+, Windows Server 2025), transparent sessions cannot use the default RDP port `3389`.
+You must configure a custom port to use transparent sessions with RDP targets.
+
+ Refer to [Using transparent sessions with RDP on Windows](/boundary/docs/credentials/rdp-testing-and-compatibility-matrix#using-transparent-sessions-with-rdp-on-windows) for more information about configuring a custom port for transparent sessions.
+- `-egress-worker-filter=` - A Boolean expression that filters which egress workers can process sessions for the target.
+- `-ingress-worker-filter=` - A Boolean expression that filters which ingress workers can process sessions for the target.
+- `-session-connection-limit=` - The maximum number of connections allowed for a session.
+A value of `-1` means the connections are unlimited.
+- `-session-max-seconds=` - The maximum lifetime of the session, including all connections.
+You can specify an integer number of seconds or a duration string.
+If you do not specfiy a maximum duration, Boundary uses the default value of 8 hours (28800 seconds).
+
+
The `targets update ssh` command lets you update SSH targets.
diff --git a/website/content/docs/concepts/credential-management.mdx b/website/content/docs/concepts/credential-management.mdx
index b5220ee481..2c741f962a 100644
--- a/website/content/docs/concepts/credential-management.mdx
+++ b/website/content/docs/concepts/credential-management.mdx
@@ -33,8 +33,8 @@ The credential brokering process works as follows:
The user is authenticated to the target.
-You can attach brokered credentials to either TCP targets or SSH targets.
-Brokered credentials can take the form of a token, username and password, SSH private key, certificate, JSON blob, or an unstructured secret stored in Vault, for example.
+You can attach brokered credentials to SSH, TCP, or RDP targets.
+Brokered credentials can take the form of a token, username password, username password domain, JSON blob, or an unstructured secret stored in Vault, for example.
### Security considerations
@@ -87,7 +87,18 @@ The credential injection process works as follows:
Then the controller passes credentials to the worker.
The worker authenticates to the target, and the user is then authenticated to the target.
-Credential injection is required for the SSH target type, allowing users to inject the following credential types when they access targets using SSH:
+### Target types
+
+Credential injection is required for the RDP and SSH target types.
+
+
+
+RDP credential injection is currently in beta.
+For more information about known issues, configuration requirements, and compatibility with Windows, refer to [RDP credential injection compatibility](/boundary/docs/credentials/rdp-testing-and-compatibility-matrix).
+
+
+
+You can inject the following credential types when you access SSH targets:
- SSH certificates
- Usernames and passwords
@@ -96,7 +107,9 @@ Credential injection is required for the SSH target type, allowing users to inje
Keyboard-interactive authentication is not supported for credential injection.
When you use Username password credentials, ensure that your SSH server is configured to allow password authentication.
-You can broker additional credentials to SSH targets after the session is established using injected credentials.
+You can inject username password domain credentials when you access RDP targets in Windows environments that use Active Directory or NTLMv2 for authentication.
+
+You can broker additional credentials to RDP or SSH targets after the session is established using injected credentials.
### Security considerations
@@ -124,6 +137,8 @@ Refer to the [Manage SSH keys with HCP Boundary and Vault](/boundary/tutorials/h
## More information
+Refer to [Credentials in Boundary](/boundary/docs/credentials) to learn more about how Boundary centralizes credential management to enhance security.
+
To configure credential brokering or credential injection with static credentials, refer to the following topics:
- [Create a static credential store](/boundary/docs/credentials/static-cred-boundary)
diff --git a/website/content/docs/credentials/configure-credential-injection.mdx b/website/content/docs/credentials/configure-credential-injection.mdx
index 08cbd8552b..e409883bb5 100644
--- a/website/content/docs/credentials/configure-credential-injection.mdx
+++ b/website/content/docs/credentials/configure-credential-injection.mdx
@@ -10,13 +10,21 @@ description: >-
This feature requires HCP Boundary or Boundary Enterprise
The following section provides steps to configure your targets with credential injection.
-Credential injection provides end users with a passwordless experience when they connect to targets.
+Credential injection provides end users with a passwordless experience when they connect to targets by automatically injecting credentials without exposing them to the user.
+
+Credential injection is supported for:
+- **SSH targets**: Protocol-aware SSH connections
+- **RDP targets**: Protocol-aware RDP connections (BETA)
+
+ @include 'alerts/beta.mdx'
## Requirements
- This feature requires either HCP Boundary or Boundary Enterprise
-- You must have an existing target available. If you use the SSH target type, the target must be configured with an injected application credential.
-
+- You must have an existing target available that supports credential injection:
+ - **RDP targets**: Must be configured with at least one injected application credential
+ - **SSH targets**: Must be configured with at least one injected application credential
+ - **TCP targets**: Do not support credential injection
- You must have configured either a static credential store or a Vault credential store:
- To configure a static credential store, refer to [Create static credential stores](/boundary/docs/credentials/static-cred-boundary).
@@ -24,7 +32,8 @@ Credential injection provides end users with a passwordless experience when they
- You must have a static credential saved in your static credential store or Vault credential store. The credential must correspond to the target to which you want to authenticate.
-- Keyboard-interactive authentication is not supported. When you use Username password credentials, ensure that your SSH server is configured to allow password authentication.
+- **For RDP targets**: Network Level Authentication (NLA) is supported. Kerberos and NTLMv2 authentication methods are supported for domain-joined workers. NTLMv2 is supported for non-domain-joined workers.
+- **For SSH targets**: Keyboard-interactive authentication is not supported. When you use username-password credentials, ensure that your SSH server is configured to allow password authentication.
## Configuration
@@ -34,14 +43,14 @@ Complete the following steps to configure targets with credential injection:
1. Log in to Boundary.
-1. Select **Orgs** on the navigation pane.
-1. Select your desired org.
-1. Select the project where your target resides.
-1. Click **Targets** on the navigation pane.
-1. Click on your target you want to configure for credential injection.
-1. Click on the **Injected Application Credential** tab.
-1. Click **Managed** and select **Add Injected Application Credential** in the pull down menu.
-1. Do one of the following:
+2. Select **Orgs** on the navigation pane.
+3. Select your desired org.
+4. Select the project where your target resides.
+5. Click **Targets** on the navigation pane.
+6. Click on your target you want to configure for credential injection.
+7. Click on the **Injected Application Credential** tab.
+8. Click **Managed** and select **Add Injected Application Credential** in the pull down menu.
+9. Do one of the following:
- **If you are using a static credential store**: Select the credential that corresponds to your target and click **Add Injected Application Credential**.
- **If you are using a Vault credential store**: Select the credential library that corresponds to your target and click **Add Injected Application Credential**.
@@ -56,11 +65,11 @@ Complete the following steps to configure targets with credential injection:
Please enter the password (it will be hidden):
```
-1. Add credential injection to target.
+2. Add credential injection to target.
```shell-session
$ boundary targets add-credential-sources \
- -id ttcp_vO60a7TwpI \
+ -id trdp_vO60a7TwpI \
-injected-application-credential-source csvlt_Xqa6V6QwfM
```
diff --git a/website/content/docs/credentials/index.mdx b/website/content/docs/credentials/index.mdx
index 27c2727a83..475d01a139 100644
--- a/website/content/docs/credentials/index.mdx
+++ b/website/content/docs/credentials/index.mdx
@@ -16,9 +16,9 @@ Boundary supports credential management using [credential stores](/boundary/docs
There are two types of credential stores:
1. Static credential store
-1. Vault credential store
+2. Vault credential store
-Static credential stores are built into Boundary and only store static credentials like username and password, or keypairs. Vault credential stores point to a HashiCorp Vault instance, which provides additional capabilities like generating short-lived dynamic credentials.
+Static credential stores are built into Boundary and store static credentials like username password, username password domain, or keypairs. Vault credential stores point to a HashiCorp Vault instance, which provides additional capabilities like generating short-lived dynamic credentials and integrating with external systems like Active Directory through the LDAP secrets engine.
Boundary can retrieve credentials from the credential stores and present them back to the user when they connect to targets. This workflow is referred to as **credential brokering**. Boundary can also inject credentials directly into the session on behalf of the user. This workflow is referred to as **credential injection**.
@@ -31,11 +31,30 @@ The second workflow uses a feature called credential brokering, where credential
The third workflow uses a featured called credential injection, where credentials are retrieved from a credential store and injected directly into the session on behalf of the end user. This workflow is the most secure because credentials are not exposed to the end user, reducing the chances of a leaked credential. This workflow is also more streamlined as the user goes through a passwordless experience. For more information, refer to the [Credential injection](/boundary/docs/concepts/credential-management#credential-injection) concepts page.
-The type of target you connect to also determines which credential workflows you can configure.
-An SSH target must have at least one injected application credential to establish the SSH connection.
-A TCP target cannot have any injected application credentials.
+The type of target you connect to also determines which credential workflows you can configure:
+
+- **TCP targets** cannot have any injected application credentials
+- **SSH targets** must have at least one injected application credential to establish the SSH connection
+- **RDP targets** must have at least one injected application credential to establish the RDP connection
+
+
+
+RDP credential injection is currently in beta and requires HCP Boundary or Boundary Enterprise.
+
+
+
For more information, refer to the [Target types](/boundary/docs/domain-model/targets#target-types) documentation.
+## Credential types
+
+Boundary supports several credential types to accommodate different authentication methods:
+
+- **Username password**: Basic username and password authentication
+- **Username password domain**: Username, password, and domain for Windows environments that use Active Directory authentication, commonly used for credential injection when connecting to an RDP target
+- **SSH private key**: SSH private key authentication
+- **SSH certificate**: SSH certificate-based authentication
+- **JSON**: Flexible JSON-based credential storage
+
## Next steps
The following pages provide steps to configure static credentials using both a static credential store and a Vault credential store. You can also configure targets for either credential brokering or credential injection workflows.
@@ -43,4 +62,6 @@ The following pages provide steps to configure static credentials using both a s
- [Create a static credential store](/boundary/docs/credentials/static-cred-boundary)
- [Create a Vault credential store](/boundary/docs/credentials/static-cred-vault)
- [Configure targets with credential brokering](/boundary/docs/credentials/configure-credential-brokering)
-- [Configure targets with credential injection](/boundary/docs/credentials/configure-credential-injection)
\ No newline at end of file
+- [Configure targets with credential injection](/boundary/docs/credentials/configure-credential-injection)
+
+To learn more about what is supported for the RDP credential injection beta and to view known issues, refer to [RDP credential injection compatibility](/boundary/docs/credentials/rdp-testing-and-compatibility-matrix).
diff --git a/website/content/docs/credentials/rdp-testing-and-compatibility-matrix.mdx b/website/content/docs/credentials/rdp-testing-and-compatibility-matrix.mdx
new file mode 100644
index 0000000000..e06f450362
--- /dev/null
+++ b/website/content/docs/credentials/rdp-testing-and-compatibility-matrix.mdx
@@ -0,0 +1,203 @@
+---
+layout: docs
+page_title: RDP credential injection compatibility
+description: >-
+ Learn about what is supported and understand known limitations for the beta version of the RDP credential injection feature.
+---
+
+# RDP credential injection compatibility
+
+@include 'alerts/beta.mdx'
+
+RDP credential injection is currently in **beta**. This feature is under active development and testing.
+
+**Important considerations:**
+
+- The [compatibility matrix](#compatibility-status) below reflects currently tested configurations.
+- Additional client/target combinations are being validated and will be added regularly.
+- Some functionality may change before general availability.
+- Please report any issues or untested combinations through [official support channels](https://support.hashicorp.com).
+- [Create an issue](https://github.com/hashicorp/boundary/issues/new/choose) to send the Boundary team feedback about the beta.
+
+This documentation will be updated frequently as new combinations are tested and validated.
+
+**Key takeaways for the RDP credential injection beta:**
+
+- **Credential source:** The initial beta only supports static credentials from Boundary's built-in **static credential store** or Vault's Key Value store.
+- **Supported authentication:** Only **Kerberos** and **NTLMv2** are supported.
+- **Unsupported authentication:** Microsoft Entra ID, passwordless methods (Windows Hello, FIDO2), and Smart Cards are **not** supported.
+- **Transparent sessions:** RDP transparent sessions on Windows clients require a custom port configuration due to a conflict with the default port `3389`. Refer to [Using transparent sessions with RDP on Windows](#using-transparent-sessions-with-rdp-on-windows) for two possible workarounds.
+- **Initial connection:** Users must manually accept a self-signed certificate on their first connection to a target. Some clients prompt users for a username and password even when credential injection is in use, but Boundary ignores the entries. You can enter anything and Boundary uses the configured injected credential to authenticate to the target.
+- **Important configuration note:** If you use the Windows RDP client and set the `connection limit` to `1` for RDP targets it will cause all RDP connections to fail. You can leave the connection limit unset or configure a limit of 2 or higher to account for the multiple connections used by the RDP client.
+
+## How credential injection works
+
+When users connect to RDP targets, Boundary can automatically inject credentials, preventing exposure to the end-user. This is the most secure workflow, providing a passwordless experience within the supported authentication frameworks.
+
+Boundary retrieves credentials from a supported credential store and injects them directly into the RDP session on behalf of the user. **The initial beta release only supports static credentials from Boundary's built-in static credential store or Vault's KV store.** Support for the Vault LDAP Secrets Engine, is planned as a fast-follow release.
+
+Refer to [Credential injection](/boundary/docs/concepts/credential-management#credential-injection) for more information about how credential injection works in Boundary.
+
+### Supported authentication methods
+
+As of Boundary 0.20, we **only** support the following traditional authentication methods for RDP targets:
+
+1. **Kerberos authentication** - The primary method for domain-joined Windows servers.
+1. **NTLMv2 authentication** - Used for standalone servers or as a fallback.
+
+
+
+Modern and cloud-based authentication methods are **not supported** at this time. This includes, but is not limited to:
+
+- Microsoft Entra ID (formerly Azure Active Directory)
+- Passwordless methods (Windows Hello, FIDO2 keys)
+- Certificate-based authentication (including Smart Cards)
+
+
+
+## Known limitations
+
+The following issues may affect RDP connections, particularly when using transparent sessions:
+
+- **Concurrent transparent sessions hanging:** Attempting to launch more than one concurrent transparent session for RDP will cause the Boundary desktop client to hang silently. You must fully terminate the first session before starting another.
+- **Improper session termination:** Closing the RDP client window does not always properly terminate the underlying Boundary session. This can prevent new connections and contributes to the hanging issue described above.
+- **Transparent sessions on Windows:** Transparent sessions for RDP do not work out-of-the-box on modern Windows clients (Windows 11+, Windows Server 2025) due to a port conflict. Refer to [Using transparent sessions with RDP on Windows](/boundary/docs/credentials/rdp-testing-and-compatibility-matrix#using-transparent-sessions-with-rdp-on-windows) for two possible workarounds.
+- **Error during basic settings exchange:** When you connect to an RDP target using the built-in Windows Remote Desktop Connection app, it creates the following error:
+
+ `rdp.handleProxy:error during basic settings exchange`
+
+ The error has no impact on the connection, it is a known issue.
+
+## Configuration requirements
+
+Refer to the following sections for specific configuration requirements for the RDP credential injection beta.
+
+### Using transparent sessions with RDP on Windows
+
+Due to a port conflict with the Windows Remote Desktop Connection app on modern Windows operating systems (Windows 11+, Windows Server 2025), transparent sessions fail when you use the default port (`3389`) to establish an RDP connection.
+The port conflict is an issue even if you enable Remote Desktop.
+This issue prevents users from establishing transparent sessions by entering a target alias in their RDP client.
+
+To connect to an RDP target using a transparent session from a Windows client, you **must** use a custom port. Two primary workarounds are available:
+
+1. **Configure a default client port:** Set a custom port (e.g., `83389`) in the target's configuration within Boundary. The user must then connect by specifying this port in their RDP client (for example, `my-server:83389`).
+1. **Use `.rdp` bookmark files:** Create and distribute an `.rdp` file that contains the full connection string, including the custom port for the localhost listener (for example, `full address:s:localhost:51129`). Bookmark files allow users to connect by simply opening the file.
+
+### Certificate handling
+
+Boundary generates self-signed certificates for each RDP target. When users first connect to a target, they must manually accept the certificate. This is a one-time action per target for most clients, though behavior varies:
+
+- **Windows clients** remember certificates across sessions.
+- **macOS clients** require accepting certificates per alias or endpoint.
+- **Custom listen addresses** generate certificate mismatch warnings.
+
+Future releases may support enterprise certificate authorities for trusted certificates.
+
+### Connection limits
+
+The Windows Remote Desktop Connection application consumes multiple connections when initiating a session.
+
+If you set the connection limit to `1` for RDP targets it will cause all RDP connections using this client to fail. You can leave the connection limit unset or configure a limit of 2 or higher to account for the multiple connections used by the RDP client.
+
+### Network configuration
+
+RDP credential injection has specific network requirements:
+
+- UDP transport is disabled.
+- Server redirection is not supported.
+- The maximum TLS version is 1.2. TLS 1.3 is incompatible with Windows Server 2025.
+
+### Client behavior
+
+Different RDP clients exhibit unique behaviors:
+
+**Windows Remote Desktop Connection:**
+- Does not prompt for credentials when Boundary injects them.
+- Requires manual certificate acceptance per endpoint.
+
+**macOS Windows App:**
+- Prompts for credentials, but Boundary ignores the entries. Boundary uses the configured injected credential to authenticate to the target.
+- Requires manual certificate acceptance per endpoint.
+
+## Compatibility status
+
+Refer to the following sections for information about which Windows versions the beta RDP credential injection feature is compatible with.
+
+The tables below use the following to indicate compatiblity:
+
+- **✅:** Tested and verified to be compatible.
+- **Pending:** Validation is planned but not yet complete.
+
+### Windows Server 2025
+
+| Client OS | Kerberos only | Kerberos + NTLMv2 (domain-joined worker) | Kerberos + NTLMv2 (non-domain worker) |
+|-----------|:-------------:|:----------------------------------------:|:--------------------------------------:|
+| Windows 11 | Pending | ✅ | Pending |
+| Windows 10 | ✅ | Pending | Pending |
+| macOS 15 | Pending | Pending | Pending |
+| macOS 14 | Pending | Pending | Pending |
+| macOS 13 | Pending | Pending | Pending |
+
+### Windows Server 2022
+
+| Client OS | Kerberos only | Kerberos + NTLMv2 (domain-joined worker) | Kerberos + NTLMv2 (non-domain worker) |
+|-----------|:-------------:|:----------------------------------------:|:--------------------------------------:|
+| Windows 11 | ✅ | ✅ | ✅ |
+| Windows 10 | ✅ | ✅ | ✅ |
+| macOS 15 | Pending | ✅ | ✅ |
+| macOS 14 | Pending | Pending | Pending |
+| macOS 13 | Pending | Pending | Pending |
+
+### Windows Server 2019
+
+| Client OS | Kerberos only | Kerberos + NTLMv2 (domain-joined worker) | Kerberos + NTLMv2 (non-domain worker) |
+|-----------|:-------------:|:----------------------------------------:|:--------------------------------------:|
+| Windows 11 | ✅ | ✅ | ✅ |
+| Windows 10 | ✅ | ✅ | ✅ |
+| macOS 15 | ✅ | ✅ | ✅ |
+| macOS 14 | Pending | Pending | Pending |
+| macOS 13 | Pending | Pending | Pending |
+
+### Windows Server 2016
+
+| Client OS | Kerberos only | Kerberos + NTLMv2 (domain-joined worker) | Kerberos + NTLMv2 (non-domain worker) |
+|-----------|:-------------:|:----------------------------------------:|:--------------------------------------:|
+| Windows 11 | Pending | ✅ | ✅ |
+| Windows 10 | ✅ | ✅ | Pending |
+| macOS 15 | ✅ | ✅ | ✅ |
+| macOS 14 | Pending | Pending | Pending |
+| macOS 13 | Pending | Pending | Pending |
+
+## Quick troubleshooting and FAQ
+
+**Q: Can I use credentials from my Vault LDAP engine or Active Directory for this feature?**
+
+A: Not yet. The initial beta only supports credentials stored in Boundary's static credential store and the Vault K/V store. Support for the Vault LDAP Secrets Engine is a high-priority addition planned for a fast-follow release.
+
+**Q: Why am I getting a certificate warning when I connect?**
+
+A: This is expected behavior. Boundary generates a self-signed certificate for each RDP target. You must accept this certificate on your first connection.
+
+**Q: My connection is failing immediately. What should I check first?**
+
+A: Check the `connection limit` on your target. It cannot be set to `1`. Leave it unset, or set it to 2 or higher.
+
+**Q: Why can't I connect to my RDP transparent session on Windows by just using its name?**
+
+A: Modern Windows versions block local applications from using the default RDP port (3389). You must use a workaround, such as connecting to a custom port or using a pre-configured `.rdp` file. Refer to [Using transparent sessions with RDP on Windows](#using-transparent-sessions-with-rdp-on-windows).
+
+**Q: My desktop client hung after I tried to open a second RDP session. What do I do?**
+
+A: This is a known issue. The client currently does not support more than one concurrent RDP transparent session. You must ensure your first session is completely terminated before starting a new one.
+
+**Q: Does this work with servers that require Entra ID login?**
+
+A: No. At this time, only servers using traditional Kerberos or NTLMv2 authentication are supported.
+
+**Q: The macOS RDP client is asking for a password. Is injection not working?**
+
+A: This is a known behavior of the macOS client. You can leave the password field blank and proceed; Boundary will still inject the correct credentials in the background.
+
+## More information
+
+For more information about how Boundary manages credentials, refer to [Credentials in Boundary](/boundary/docs/credentials).
diff --git a/website/content/docs/credentials/static-cred-boundary.mdx b/website/content/docs/credentials/static-cred-boundary.mdx
index 72da776dfa..89f73698e1 100644
--- a/website/content/docs/credentials/static-cred-boundary.mdx
+++ b/website/content/docs/credentials/static-cred-boundary.mdx
@@ -8,7 +8,8 @@ description: >-
# Create a static credential store
You can manage credentials in Boundary using [credential stores](/boundary/docs/domain-model/credential-stores), which are resources that store credentials for various targets.
-Static credential stores are built into Boundary and only store static credentials like username and password or keypairs.
+
+Static credential stores are built into Boundary and store static credentials like username password, username password domain, or keypairs.
## Requirements
@@ -22,14 +23,14 @@ Complete the following steps to create a static credential store:
1. Log in to Boundary
-1. Select **Orgs** on the navigation pane.
-1. Select your desired org.
-1. Select the project to which your static credential store should belong.
-1. Select **Credential Stores** on the navigation pane.
-1. Select **New Credential Store**.
-1. Provide a name for your credential store and select type **Static**.
-1. Click **Save**. You now have a static credential store where you can store static credentials.
-1. (Optional) If you have a static credential, you can add it into the static credential store. Static credential types can be a username and password, username and private key, or JSON blob.
+2. Select **Orgs** on the navigation pane.
+3. Select your desired org.
+4. Select the project to which your static credential store should belong.
+5. Select **Credential Stores** on the navigation pane.
+6. Select **New Credential Store**.
+7. Provide a name for your credential store and select type **Static**.
+8. Click **Save**. You now have a static credential store where you can store static credentials.
+9. (Optional) If you have a static credential, you can add it into the static credential store. Static credential types can be a username password, username password domain, username private key, or JSON blob.
a. In your static credential store, click on the **Credentials** tab.
@@ -38,7 +39,7 @@ Complete the following steps to create a static credential store:
c. Complete the following fields to add static credentials to your static credential store:
- Name (optional) - The name is optional, but if you enter a name, it must be unique.
- Description (optional) - An optional description of the credential for identification purposes.
- - Type - The type of static credential you want to add. Select between username and password, username and keypair, or a JSON blob.
+ - Type - The type of static credential you want to add. Select between username password, username keypair, username password domain, or a JSON blob.
- Credential data - Depending on the credential type selected, enter the credential data.
d. Click **Save**.
@@ -54,7 +55,7 @@ Complete the following steps to create a static credential store:
Please enter the password (it will be hidden):
```
-1. Create a credential store and provide a name and project ID.
+2. Create a credential store and provide a name and project ID.
```shell-session
$ boundary credential-stores create static \
@@ -62,9 +63,9 @@ Complete the following steps to create a static credential store:
-name "my-static-credential-store"
```
-1. (Optional) If you have a static credential, you can add it into the static credential store using one of the following commands, based on the type of credential. Static credential types can be a username and password, username and keypair, or JSON blob.
+3. (Optional) If you have a static credential, you can add it into the static credential store using one of the following commands, based on the type of credential. Static credential types can be a username password, username password domain, username and keypair, or JSON blob.
- - For username and password credentials:
+ - For username password credentials:
```shell-session
$ boundary credentials create username-password \
@@ -97,6 +98,19 @@ Complete the following steps to create a static credential store:
To prevent credentials from being logged in the terminal, you must place the JSON map value in a file, and pass it to the `-object` option using the `file://` syntax.
+ - For username-password-domain credentials:
+
+ ```shell-session
+ $ boundary credentials create username-password-domain \
+ -name "ad-admin-credentials" \
+ -credential-store-id csst_O8utI0b3XC \
+ -username \
+ -password env:// \
+ -domain
+ ```
+
+ To prevent credentials from being logged in the terminal, you must place passwords in an environment variable or file, and pass them to the `-password` option using the `env://` or `file://` syntax.
+
@@ -107,4 +121,6 @@ When you use credential brokering, Boundary centrally manages credentials and re
Credential injection requires HCP Boundary or Boundary Enterprise, and it provides end users with a passwordless experience when they connect to targets.
- [Configure a target for credential brokering](/boundary/docs/credentials/configure-credential-brokering)
-- [Configure a target for credential injection](/boundary/docs/credentials/configure-credential-brokering)
\ No newline at end of file
+- [Configure a target for credential injection](/boundary/docs/credentials/configure-credential-brokering)
+
+To learn more about what is supported for the RDP credential injection beta and to view known issues, refer to [RDP credential injection compatibility](/boundary/docs/credentials/rdp-testing-and-compatibility-matrix).
\ No newline at end of file
diff --git a/website/content/docs/credentials/static-cred-vault.mdx b/website/content/docs/credentials/static-cred-vault.mdx
index 64bc5004e5..d7f6eff6fd 100644
--- a/website/content/docs/credentials/static-cred-vault.mdx
+++ b/website/content/docs/credentials/static-cred-vault.mdx
@@ -13,7 +13,7 @@ Vault credential stores point to a HashiCorp Vault instance, which provides capa
## Requirements
- You must have a Vault instance available with an address or URL that is reachable from your Boundary instance. This will be used to connect Boundary to Vault.
-- You must have static credentials stored in Vault’s key/value secrets engine. Examples of static credential types include username and password or username and SSH private key.
+- You must have static credentials stored in Vault’s key/value secrets engine. Examples of static credential types include username password or username and SSH private key.
- You must have a Vault token for Boundary to authenticate and access your static credentials.
## Configuration
@@ -72,7 +72,7 @@ Complete the following steps to create a Vault credential store:
1. Create a credential library using one of the following commands, based on the type of credential.
- - For username and password credentials:
+ - For username password credentials:
```shell-session
$ boundary credential-libraries create vault-generic \
@@ -82,7 +82,7 @@ Complete the following steps to create a Vault credential store:
-vault-path "path/to/vault/credentials"
```
- - For username and private key credentials:
+ - For username private key credentials:
```shell-session
$ boundary credential-libraries create vault-generic \
diff --git a/website/content/docs/domain-model/credential-stores.mdx b/website/content/docs/domain-model/credential-stores.mdx
index 8be26cea23..6b6538d190 100644
--- a/website/content/docs/domain-model/credential-stores.mdx
+++ b/website/content/docs/domain-model/credential-stores.mdx
@@ -178,7 +178,7 @@ $ vault policy write boundary-controller boundary-controller-policy.hcl
## Static credential store
-A static credential store allows user-supplied credentials to be managed by Boundary. Credentials are encrypted and stored directly in Boundary. Currently, the static credential store can hold credentials of types `username_password`, `ssh_private_key`, and `json`.
+A static credential store allows user-supplied credentials to be managed by Boundary. Credentials are encrypted and stored directly in Boundary. Currently, the static credential store can hold credentials of types `username_password`, `username_password_domain`, `ssh_private_key`, and `json`.
[token_requirements]: /boundary/docs/domain-model/credential-stores#vault-token-requirements
[token_policy]: /boundary/docs/domain-model/credential-stores#vault-boundary-controller-policy
diff --git a/website/content/docs/domain-model/credentials.mdx b/website/content/docs/domain-model/credentials.mdx
index cc6cb978a6..220f75578c 100644
--- a/website/content/docs/domain-model/credentials.mdx
+++ b/website/content/docs/domain-model/credentials.mdx
@@ -13,6 +13,7 @@ Optionally, credentials can be typed to indicate compliance with a specific form
The following credential types are supported in Boundary:
- [Username password](#username-password)
+- [Username password domain](#username-password-domain)
- [SSH private key](#ssh-private-key)
- [SSH certificate](#ssh-certificate)
- [JSON](#json)
@@ -25,6 +26,16 @@ The following credential types are supported in Boundary:
- `password` - The password field associated with the credential.
+## Username password domain
+
+`username_password_domain` credentials contain the following fields:
+
+- `username` - The username field associated with the credential.
+
+- `password` - The password field associated with the credential.
+
+- `domain` - The domain field associated with the credential.
+
## SSH private key
`ssh_private_key` credentials contain the following fields:
diff --git a/website/content/docs/domain-model/targets.mdx b/website/content/docs/domain-model/targets.mdx
index 0b30bd27bd..b6b8bc9d31 100644
--- a/website/content/docs/domain-model/targets.mdx
+++ b/website/content/docs/domain-model/targets.mdx
@@ -44,6 +44,8 @@ A target has the following configurable attributes:
This value represents a network resource address and is used when establishing a session.
It does not accept a port, only an IP address or DNS name.
+ If you set a target address for RDP targets that use Kerberos authentication, use the target's hostname and append the domain to it, for example `target-hostname.mydomain.com`. For RDP targets that use NTLM authentication, set the target address to the target's IP address.
+
- `default_client_port` - (optional)
Represents a local port that you want Boundary to listen to by default when someone initiates a session on the client.
@@ -88,8 +90,8 @@ A target has the following configurable attributes:
## Target types
-Boundary supports TCP and SSH target types.
-An SSH target **must** have at least one injected application credential to establish the SSH connection.
+Boundary supports RDP, SSH, and TCP target types.
+RDP and SSH targets **must** have at least one injected application credential to establish the connection.
A TCP target **cannot** have any injected application credentials.
Note the following target type requirements:
@@ -100,19 +102,27 @@ Note the following target type requirements:
You can configure brokered credentials for use with SSH targets for purposes other than establishing the initial SSH connection.
-### TCP target attributes
+### RDP target attributes
-TCP targets have the following additional attribute:
+This feature requires HCP Boundary or Boundary Enterprise
-- `default_port` - (required)
+RDP targets use injected application credentials to authenticate an RDP session between the client and end host in Windows environments that use Active Directory authentication.
+Injected credentials allow users to securely connect to remote hosts using RDP, while never being in the possession of a valid credential for that target host.
+
+For more information about known limitations, configuration requirements, and software compatibility for the RDP credential injection beta, refer to [RDP credential injection compatibiity](/boundary/docs/credentials/rdp-testing-and-compatibility-matrix).
+
+RDP targets have the following additional attribute:
+
+- `default_port` - (optional)
The default port to set on this target.
+ If this is not specified the default port will be 3389.
### SSH target attributes
This feature requires HCP Boundary or Boundary Enterprise
SSH targets use injected application credentials to authenticate an SSH session between the client and end host.
-Injected credentials allow users to securely connect to remost hosts using SSH, while never being in the possession of a valid credential for that target host.
+Injected credentials allow users to securely connect to remote hosts using SSH, while never being in the possession of a valid credential for that target host.
The injected credentials can be a username/password or username/private key credential from Vault credential libraries or they can be static [credentials][] or an SSH certificate from Vault SSH credential libraries.
SSH targets require you to configure injected credentials to create a session.
@@ -133,6 +143,13 @@ SSH targets have the following additional attributes:
Designates the storage bucket to be used for session recording.
This attribute is required if you set `enable_session_recording` to `true`.
+### TCP target attributes
+
+TCP targets have the following additional attribute:
+
+- `default_port` - (required)
+ The default port to set on this target.
+
## Referenced by
- [Credential library][]
diff --git a/website/content/docs/overview/bastion-hosts.mdx b/website/content/docs/overview/bastion-hosts.mdx
index a64a0be606..23b05c3760 100644
--- a/website/content/docs/overview/bastion-hosts.mdx
+++ b/website/content/docs/overview/bastion-hosts.mdx
@@ -19,7 +19,7 @@ Boundary streamlines just-in-time access to privileged sessions for users, and t
Boundary validates a user's identity using your identity provider of choice, and then dynamically grants them access to the resources they need using their associated permissions.
Boundary's worker nodes, the resources that proxy connections to private endpoints, are fundamentally stateless and can be easily scaled elastically using modern development tools.
-You can use SSH to inject the credentials of any target resources that you want to connect to using Boundary, so that the credentials are never exposed to the user while establishing a connection.
+You can use SSH or RDP to inject the credentials of any target resources that you want to connect to using Boundary, so that the credentials are never exposed to the user while establishing a connection.
Alternatively, Boundary can return brokered credentials back to users (if permitted), which could take the form of API tokens, usernames and passwords, public keys, etc.
**Can Boundary replace a bastion/jumphost access model?**
@@ -29,4 +29,4 @@ The advantages to Boundary's access model are outlined above.
**Can Boundary extend a bastion/jumphost access model?**
-Yes, some users may see value in Boundary providing access to an existing bastion host deployment.
\ No newline at end of file
+Yes, some users may see value in Boundary providing access to an existing bastion host deployment.
diff --git a/website/content/docs/overview/faq.mdx b/website/content/docs/overview/faq.mdx
index 754d8a8088..dd82295751 100644
--- a/website/content/docs/overview/faq.mdx
+++ b/website/content/docs/overview/faq.mdx
@@ -19,7 +19,7 @@ check out the [worker networking requirements](/hcp/docs/boundary/self-managed-w
## Q: Does Boundary require Vault? What is the integration story?
While Vault isn't a *required* secrets backend for Boundary sessions, the potential for Boundary | Vault integration is a core part of Boundary's overall
-value proposition for identity-based access.There are three primary points of integration with Vault:
+value proposition for identity-based access. There are three primary points of integration with Vault:
1. Vault can be used as a secrets backend for Boundary, offering single signon to end target systems via credential brokering. This was covered in Boundary's
[0.4 announcement](https://www.hashicorp.com/blog/announcing-hashicorp-boundary-0-4) and there are ample
[tutorials](/boundary/tutorials/credential-management/community-vault-cred-brokering-quickstart) of this scenario.
diff --git a/website/content/docs/release-notes/v0_20_0.mdx b/website/content/docs/release-notes/v0_20_0.mdx
new file mode 100644
index 0000000000..7029e9a266
--- /dev/null
+++ b/website/content/docs/release-notes/v0_20_0.mdx
@@ -0,0 +1,212 @@
+---
+layout: docs
+page_title: v0.20.0 release notes
+description: >-
+ Learn more about the new features included in the Boundary 0.20.0 release. Understand any deprecations, changes, and known issues.
+---
+
+# Boundary 0.20.0 release notes
+
+**GA date:** September 25, 2025
+
+@include 'release-notes/intro.mdx'
+
+## Important changes
+
+
+
+
+ | Change |
+ Description |
+
+
+
+
+
+ |
+ Error when sending requests to aliases using HCP Boundary
+ |
+
+ A known issue that was caused by the way default grants were previously configured in HCP Boundary could cause you to receive 500 errors when you attempted to list resolvable aliases. The issue has been resolved. Any clusters that you created on or after April 26, 2025 should not have the issue.
+
+ You can add grants to resolve the error for any older clusters that exhibit this behavior.
+
+ Learn more: Known issues and breaking changes
+ |
+
+
+
+ |
+ Boundary client version number realignment
+ |
+
+ Previously, the Boundary Client Agent and installer used a numbering scheme that was inconsistent with Boundary's release numbers. This inconsistency could make it difficult to understand version support and compatibility.
+
+ On May 27, 2025 new versions of the Boundary Client Agent and installer were released with a new numbering scheme that more closely follows Boundary's release numbers. Those versions were released as 0.19.5 to match the major Boundary version 0.19.x. Going forward, the Client Agent and installer will use the same major number as the current Boundary release. Any patches or updates will be reflected in the minor number.
+
+ Learn more about control plane and client compatibility: Boundary Enterprise supported versions policy
+ |
+
+
+
+ |
+ Redundant grant scopes are no longer permitted
+ |
+
+ You may have redundant grant scopes if you applied a grant to a scope and the scope also inherited the grant from the this, children, or descendants options. As of Boundary version 0.19.3, redundant grant scopes are no longer permitted.
+
+ When you upgrade a Boundary Enterprise or Community edition cluster to version 0.19.3 or later, the migration will fail with a message if the database contains any redundant grant scopes. The migration tool provides a command that automatically removes any redundant grant scopes so that you can proceed with the upgrade.
+
+ For HCP Boundary users, the redundant grant scopes are automatically removed as part of the migration process.
+
+ Learn more about removing redundant grant scopes and upgrading to version 0.19.3 or later: Known issues and breaking changes
+ |
+
+
+
+
+
+## New features
+
+
+
+
+ | Feature |
+ Update |
+ Description |
+
+
+
+
+
+ |
+ RDP targets
+ |
+
+ GA
+ |
+
+ Boundary now supports a new RDP target type. RDP targets let you use injected credentials to authenticate an RDP session between the client and end host in Windows environments that use Active Directory authentication. RDP targets use the new username password domain credential type.
+
+ Learn more: Target types and targets create command.
+ |
+
+
+
+ |
+ Username password domain credentials
+ |
+
+ GA
+ |
+
+ There is a new username password domain credential type for Windows environments that use Active Directory authentication. You can use username password domain credentials for credential injection when you connect to an RDP target.
+
+ Learn more: Credential management, Credentials in Boundary, and credentials create command.
+ |
+
+
+
+ |
+ RDP credential injection
+ |
+
+ BETA
+ |
+
+ Boundary now supports RDP credential injection as a beta feature. When users connect to RDP targets, Boundary can automatically inject credentials into the RDP session on behalf of the user.
+
The initial beta release supports static credentials from Boundary's built-in static credential store or Vault's KV store. Refer to the documentation for known limitations, configuration requirements, and Windows compatibility.
+
+ Learn more: RDP credential injection compatibility.
+ |
+
+
+
+
+
+## Known issues and breaking changes
+
+
+
+
+ | Version |
+ Issue |
+ Description |
+
+
+
+
+
+ |
+ 0.13.0+
+ |
+
+ Rotation of AWS access and secret keys during a session results in stale recordings
+ |
+
+ In Boundary version 0.13.0+, when you rotate a storage bucket's secrets, any new sessions use the new credentials. However, previously established sessions continue to use the old credentials.
+
+ As a best practice, administrators should rotate credentials in a phased manner, ensuring that all previously established sessions are completed before revoking the stale credentials.
+ Otherwise, you may end up with recordings that aren't stored in the remote storage bucket, and are unable to be played back.
+ |
+
+
+ |
+ 0.13.0+
+ |
+
+ Unsupported recovery workflow during worker failure
+ |
+
+ If a worker fails during a recording, there is no way to recover the recording. This could happen due to a network connectivity issue or because a worker is scaled down, for example.
+
+ Learn more:
+ Unsupported recovery workflow
+ |
+
+
+
+ |
+ 0.17.1+
+ |
+
+ Docker image no longer contains curl
+ |
+
+ As of version 0.17.1 and later, the curl binary is no longer included in the published Docker container image for Boundary.
+
+ The image now includes wget. You can use wget to check the health endpoint for workers.
+
+ Learn more: Check the health endpoint using wget
+
+ If your workflow depends on having curl in the image, you can dynamically install it using apk. Refer to the following commands for examples of using apk to install curl:
+
+ <CONTAINER-ID> apk add curl
+
+ or
+
+ kubectl exec -ti <NAME> -- apk add curl
+ |
+
+
+
+ |
+ 0.18.x+
+ |
+
+ Boundary version 0.18.x and later CLI is unable to establish connections using the boundary connect command
+ |
+
+ Boundary version 0.18.x uses Go version 1.23, which introduced a new TLS handshake behavior. Some VPN providers struggle with the TLS handshake being sent over 2 frames instead of 1, which can lead to Boundary version 0.18.x and later controllers, workers, or clients being unable to establish connections. As a workaround, you can revert back to the previous TLS handshake behavior.
+
+ To revert back to the previous TLS handshake behavior, add the tlskyber=0 parameters to the GODEBUG environment variable before the boundary connect command. For example:
+
+ GODEBUG=tlskyber=0 boundary connect ssh -target-id <ID>
+
+ Learn more: Go issue #70047 and Go 1.23 Release Notes
+
+ |
+
+
+
+
diff --git a/website/content/docs/targets/configuration/create-target-alias.mdx b/website/content/docs/targets/configuration/create-target-alias.mdx
index 7793ec7866..33df535804 100644
--- a/website/content/docs/targets/configuration/create-target-alias.mdx
+++ b/website/content/docs/targets/configuration/create-target-alias.mdx
@@ -110,9 +110,11 @@ Complete the following steps to create a new target and new alias at the same ti
- **Name**: Enter the target name for identification purposes.
- **Description**: (Optional) Enter an optional description for identification purposes.
- **Type**: Select the target type.
- You can create SSH or TCP targets.
+ You can create RDP, SSH, or TCP targets.
- **Target Address**: (Optional) Enter a valid IP address or DNS name.
- Alternatively, you can configure host catalogs and host sets.
+ Alternatively, you can configure host catalogs and host sets.
+
+ If you set a target address for RDP targets that use Kerberos authentication, use the target's hostname and append the domain to it, for example `target-hostname.mydomain.com`. For RDP targets that use NTLM authentication, set the target address to the target's IP address.
- **Default Port**: (Optional) Enter an optional default port for the target to use for connections.
- **Default Client Port**: (Optional) Enter an optional local proxy port on which to listen when a session is started on a client.
- **Maximum Duration**: (Required) Enter a maximum duration for sessions on this target, in seconds.
@@ -153,6 +155,8 @@ Complete the following steps to create a new target and new alias at the same ti
You can also specify the scope using the BOUNDARY_SCOPE_ID environment variable.
- `-address=` - An optional valid network address for the target to connect to.
You cannot use an address alongside host sources.
+
+ If you set a target address for RDP targets that use Kerberos authentication, use the target's hostname and append the domain to it, for example `target-hostname.mydomain.com`. For RDP targets that use NTLM authentication, set the target address to the target's IP address.
- `-default-client-port=` - The default client port on the target.
- `-default-port=` - The default port on the target.
If you do not specify a default port, Boundary uses port 22.
@@ -171,7 +175,7 @@ A value of `-1` means the connections are unlimited.
- `-with-alias-value=` - The value of the alias that you want to use to represent the target.
Use this parameter to create the alias and target, and associate them with each other, at the same time.
- Note that you can create SSH or TCP [target types](/boundary/docs/domain-model/targets#target-types).
+ You can create RDP, SSH, or TCP [target types](/boundary/docs/domain-model/targets#target-types).
The example command in this section creates an SSH target.
@@ -314,6 +318,12 @@ Target aliases point directly to the target they are associated with. You can as
You assign [direct target addresses](/boundary/docs/domain-model/targets#address) directly to the target. They refer to a specific network resource, like an IP address. Boundary only connects to the direct target address when it establishes a connection to the associated target.
+
+
+If you set a target address for RDP targets that use Kerberos authentication, use the target's hostname and append the domain to it, for example `target-hostname.mydomain.com`. For RDP targets that use NTLM authentication, set the target address to the target's IP address.
+
+
+
When you create a target alias, you can also assign it to a specific host. Assigning an alias to a specific host is useful if you want to avoid creating multiple targets for specific hosts using direct target addresses.
For example, you could create two aliases for the same target that has been assigned a host set. One alias could refer to the target itself, and would allow Boundary to randomly select a host to connect to for a session. Another alias could point to the same target, but you could assign a host ID that Boundary should use for a session.
@@ -460,7 +470,7 @@ $ boundary targets add-host-sources -id tssh_lhH5pa425G -host-sourchsst_56oiL0Wa
- In the following examples, Terraform resources are named with underscores instead of dashes, such as `linux_dev_servers`. The target alias values use dashes, such as `dev-041.linux-dev.app-servers.eng`. You do not need to follow these naming conventions.
+ In the following examples, Terraform resources are named with underscores instead of dashes, such as `linux_dev_servers`. The target alias values use dashes, such as `dev-041.linux-dev.app-servers.eng`. You do not need to follow these naming conventions.
diff --git a/website/content/docs/targets/connections/transparent-sessions.mdx b/website/content/docs/targets/connections/transparent-sessions.mdx
index f6ee9a9ac7..7c69822417 100644
--- a/website/content/docs/targets/connections/transparent-sessions.mdx
+++ b/website/content/docs/targets/connections/transparent-sessions.mdx
@@ -37,7 +37,7 @@ Alternatively, you can use the Boundary Desktop Client to start a session, and c
$ ssh 127.0.0.1 -p 55374
```
-With transparent sessions, you use the target alias as the address to establish a session. If the Client Agent is runningand you have authenticated using the CLI or Boundary Desktop Client, you can use the alias to start a session:
+With transparent sessions, you use the target alias as the address to establish a session. If the Client Agent is running and you have authenticated using the CLI or Boundary Desktop Client, you can use the alias to start a session:
```shell-session
$ ssh my.alias.name
@@ -45,6 +45,17 @@ $ ssh my.alias.name
Boundary starts the session as usual, and brokers or injects any credentials you have configured.
+### RDP targets
+
+Due to a port conflict with the Windows Remote Desktop Connection app on modern Windows operating systems (Windows 11+, Windows Server 2025), transparent sessions fail when you use the default port (`3389`) to establish an RDP connection.
+The port conflict is an issue even if you enable Remote Desktop.
+To connect to an RDP target from a Windows client using a transparent session, you must use a custom port.
+Refer to [RDP credential injection compatibility](/boundary/docs/credentials/rdp-testing-and-compatibility-matrix) for more information.
+
+When you connect to the RDP target using transparent sessions, you must specify the custom port with the alias in the RDP client, for example:
+
+`my.alias.name:33890`
+
## Next steps
When you have validated that transparent sessions work, you can create and establish transparent sessions to other services.
diff --git a/website/data/docs-nav-data.json b/website/data/docs-nav-data.json
index cc8046e551..43d15add68 100644
--- a/website/data/docs-nav-data.json
+++ b/website/data/docs-nav-data.json
@@ -307,6 +307,10 @@
{
"title": "Release notes",
"routes": [
+ {
+ "title": "v0.20.0",
+ "path": "release-notes/v0_20_0"
+ },
{
"title": "v0.19.0",
"path": "release-notes/v0_19_0"
@@ -557,6 +561,15 @@
"type": "outlined",
"color": "neutral"
}
+ },
+ {
+ "title": "RDP credential injection compatibility",
+ "path": "credentials/rdp-testing-and-compatibility-matrix",
+ "badge": {
+ "text": "HCP/ENT BETA",
+ "type": "outlined",
+ "color": "neutral"
+ }
}
]
},