I didn’t find the one to add the credentials to access the machine. Any specific tutorials?
The general tutorial for credential brokering is here: Vault Credential Brokering Quickstart
What kind of credentials do your RDP targets use – built-in Windows accounts, or Active Directory?
Many thanks for the reply.
just username and password.
My goal is not to type these credentials (image in attachment).
I didn’t find in the Vault a suitable secret to store the name and password (rdp). Active Directory
internal accounts to be more specific. I’ve been working on this all week and haven’t made any progress.
You could store a plain username/password as keys in a Vault K/V secret and have that returned to the user when they connect to the target.
If it’s Active Directory, you can set up a role account that Vault can manage with the openldap engine using the ad schema, which makes password rotation with Vault simpler, or even set up completely ephemeral dynamic AD accounts with that same engine. Those will both require setting up an account in Active Directory for Vault to use to manage Active Directory accounts.
I understand. But using K/V the user will know the system credential, right? I wish he didn’t know the system username and password. I would like when he uses the boundary connect rdp -target-id ttcp_… he has direct access to the system without knowing the credentials. It’s possible?
In this case, I will not use Active Directory
Hi @symon_nascimento, your ask for static credentials being obfuscated from the user is well-taken!
Currently, Boundary supports credential brokering, whereby Boundary controllers check out credentials from Vault and return them back to users/clients (thus Boundary acts as a broker of the credential).
However, to your point, brokering lacks the ability to obfuscate credentials from clients. To do this, there is a potential alternative workflow in which controllers instead return credentials to Boundary workers where they might be used to create a session to a target such that the user/client never has access to the credential. This would require Boundary workers having the ability to protocol decode the arbitrary application layer traffic (eg RDP) that might be created over the session. We are referring to this workflow as credential injection as the credential is injected into a worker’s session, rather than being passed back to a user/client.
Currently, Boundary only supports credential brokering, however we will keep in mind the ask for future credential injection workflows. In the meantime, Active Directory is likely a more secure workflow than credential brokering for your workflow.