backport of commit 55414e6a733bc7d746618ddd0723bac38b90cc7d (#23198)

Co-authored-by: Aram Mirzadeh <aram535@users.noreply.github.com>
This commit is contained in:
hc-github-team-secure-vault-core 2023-09-20 17:20:09 -04:00 committed by GitHub
parent 2110530c6e
commit 0596707993
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 17 additions and 17 deletions

View File

@ -34,7 +34,7 @@ The secrets engine has three primary features:
to generate passwords:
```sh
$ vault write ldap/config \
$ vault write auth/ldap/config \
binddn=$USERNAME \
bindpass=$PASSWORD \
url=ldaps://138.91.247.105
@ -45,7 +45,7 @@ The secrets engine has three primary features:
3. Rotate the root password so only Vault knows the credentials:
```sh
$ vault write -f ldap/rotate-root
$ vault write -f auth/ldap/rotate-root
```
Note: it's not possible to retrieve the generated password once rotated by Vault.
@ -80,7 +80,7 @@ Generated passwords must be 8 characters or less to support RACF. The length of
password can be configured using a [password policy](/vault/docs/concepts/password-policies):
```bash
$ vault write ldap/config \
$ vault write auth/ldap/config \
binddn=$USERNAME \
bindpass=$PASSWORD \
url=ldaps://138.91.247.105 \
@ -94,7 +94,7 @@ For managing Active Directory instances, the secret engine must be configured to
schema `ad`.
```bash
$ vault write ldap/config \
$ vault write auth/ldap/config \
binddn=$USERNAME \
bindpass=$PASSWORD \
url=ldaps://138.91.247.105 \
@ -109,7 +109,7 @@ $ vault write ldap/config \
Password rotation settings will be managed by this role.
```sh
$ vault write ldap/static-role/hashicorp \
$ vault write auth/ldap/static-role/hashicorp \
dn='uid=hashicorp,ou=users,dc=hashicorp,dc=com' \
username='hashicorp' \
rotation_period="24h"
@ -118,7 +118,7 @@ $ vault write ldap/config \
2. Request credentials for the "hashicorp" role:
```sh
$ vault read ldap/static-cred/hashicorp
$ vault read auth/ldap/static-cred/hashicorp
```
### Password rotation
@ -155,7 +155,7 @@ rotated prior to deleting the role or revoking access to the static role.
Dynamic credentials can be configured by calling the `/role/:role_name` endpoint:
```bash
$ vault write ldap/role/dynamic-role \
$ vault write auth/ldap/role/dynamic-role \
creation_ldif=@/path/to/creation.ldif \
deletion_ldif=@/path/to/deletion.ldif \
rollback_ldif=@/path/to/rollback.ldif \
@ -169,7 +169,7 @@ executed if the creation fails for any reason. This ensures any entities are rem
To generate credentials:
```bash
$ vault read ldap/creds/dynamic-role
$ vault read auth/ldap/creds/dynamic-role
Key Value
--- -----
lease_id ldap/creds/dynamic-role/HFgd6uKaDomVMvJpYbn9q4q5
@ -283,7 +283,7 @@ to an AD server.
$ vault secrets enable ldap
Success! Enabled the ad secrets engine at: ldap/
$ vault write ldap/config \
$ vault write auth/ldap/config \
binddn=$USERNAME \
bindpass=$PASSWORD \
url=ldaps://138.91.247.105 \
@ -293,7 +293,7 @@ $ vault write ldap/config \
Our next step is to designate a set of service accounts for check-out.
```shell-session
$ vault write ldap/library/accounting-team \
$ vault write auth/ldap/library/accounting-team \
service_account_names=fizz@example.com,buzz@example.com \
ttl=10h \
max_ttl=20h \
@ -312,7 +312,7 @@ When a library of service accounts has been created, view their status at any ti
available or checked out.
```shell-session
$ vault read ldap/library/accounting-team/status
$ vault read auth/ldap/library/accounting-team/status
Key Value
--- -----
buzz@example.com map[available:true]
@ -322,7 +322,7 @@ fizz@example.com map[available:true]
To check out any service account that's available, simply execute:
```shell-session
$ vault write -f ldap/library/accounting-team/check-out
$ vault write -f auth/ldap/library/accounting-team/check-out
Key Value
--- -----
lease_id ldap/library/accounting-team/check-out/EpuS8cX7uEsDzOwW9kkKOyGW
@ -336,7 +336,7 @@ If the default `ttl` for the check-out is higher than needed, set the check-out
for a shorter time by using:
```shell-session
$ vault write ldap/library/accounting-team/check-out ttl=30m
$ vault write auth/ldap/library/accounting-team/check-out ttl=30m
Key Value
--- -----
lease_id ldap/library/accounting-team/check-out/gMonJ2jB6kYs6d3Vw37WFDCY
@ -353,7 +353,7 @@ check it back in."
If no service accounts are available for check-out, Vault will return a 400 Bad Request.
```shell-session
$ vault write -f ldap/library/accounting-team/check-out
$ vault write -f auth/ldap/library/accounting-team/check-out
Error writing data to ldap/library/accounting-team/check-out: Error making API request.
URL: POST http://localhost:8200/v1/ldap/library/accounting-team/check-out
@ -380,7 +380,7 @@ ends.
To check a service account back in for others to use, call:
```shell-session
$ vault write -f ldap/library/accounting-team/check-in
$ vault write -f auth/ldap/library/accounting-team/check-in
Key Value
--- -----
check_ins [fizz@example.com]
@ -390,7 +390,7 @@ Most of the time this will just work, but if multiple service accounts are check
caller, Vault will need to know which one(s) to check in.
```shell-session
$ vault write ldap/library/accounting-team/check-in service_account_names=fizz@example.com
$ vault write auth/ldap/library/accounting-team/check-in service_account_names=fizz@example.com
Key Value
--- -----
check_ins [fizz@example.com]
@ -405,7 +405,7 @@ Vault will check it back in automatically when the `ttl` expires. However, if th
service accounts can be forcibly checked in by a highly privileged user through:
```shell-session
$ vault write -f ldap/library/manage/accounting-team/check-in
$ vault write -f auth/ldap/library/manage/accounting-team/check-in
Key Value
--- -----
check_ins [fizz@example.com]