scottk/vault
1
0
Fork 0
mirror of https://github.com/optim-enterprises-bv/vault.git synced 2025-10-31 02:28:09 +00:00
Code Issues Packages Projects Releases Wiki Activity

[DOCS]Fix wrong api path for ldap secrets (#23225)

Browse Source 
* [DOCS]Fix wrong api path for ldap secrets

* added changelog
This commit is contained in:
Sergey Kutovoy
2023-09-22 20:01:14 +05:00
committed by GitHub
parent 54c84decfd
commit 1d61aeb8ae
2 changed files with 20 additions and 17 deletions
Download Patch File Download Diff File Expand all files Collapse all files

3
changelog/23225.txt Normal file
View File

@@ -0,0 +1,3 @@
```release-note:bug
docs: fix wrong api path for ldap secrets cli-commands
```

34
website/content/docs/secrets/ldap.mdx
View File

@@ -34,7 +34,7 @@ The secrets engine has three primary features:
to generate passwords: to generate passwords:
```sh ```sh
$ vault write auth/ldap/config \ $ vault write ldap/config \
binddn=$USERNAME \ binddn=$USERNAME \
bindpass=$PASSWORD \ bindpass=$PASSWORD \
url=ldaps://138.91.247.105 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: 3. Rotate the root password so only Vault knows the credentials:
```sh ```sh
$ vault write -f auth/ldap/rotate-root $ vault write -f ldap/rotate-root
``` ```
Note: it's not possible to retrieve the generated password once rotated by Vault. 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): password can be configured using a [password policy](/vault/docs/concepts/password-policies):
```bash ```bash
$ vault write auth/ldap/config \ $ vault write ldap/config \
binddn=$USERNAME \ binddn=$USERNAME \
bindpass=$PASSWORD \ bindpass=$PASSWORD \
url=ldaps://138.91.247.105 \ url=ldaps://138.91.247.105 \
@@ -94,7 +94,7 @@ For managing Active Directory instances, the secret engine must be configured to
schema `ad`. schema `ad`.
```bash ```bash
$ vault write auth/ldap/config \ $ vault write ldap/config \
binddn=$USERNAME \ binddn=$USERNAME \
bindpass=$PASSWORD \ bindpass=$PASSWORD \
url=ldaps://138.91.247.105 \ url=ldaps://138.91.247.105 \
@@ -109,7 +109,7 @@ $ vault write auth/ldap/config \
Password rotation settings will be managed by this role. Password rotation settings will be managed by this role.
```sh ```sh
$ vault write auth/ldap/static-role/hashicorp \ $ vault write ldap/static-role/hashicorp \
dn='uid=hashicorp,ou=users,dc=hashicorp,dc=com' \ dn='uid=hashicorp,ou=users,dc=hashicorp,dc=com' \
username='hashicorp' \ username='hashicorp' \
rotation_period="24h" rotation_period="24h"
@@ -118,7 +118,7 @@ $ vault write auth/ldap/config \
2. Request credentials for the "hashicorp" role: 2. Request credentials for the "hashicorp" role:
```sh ```sh
$ vault read auth/ldap/static-cred/hashicorp $ vault read ldap/static-cred/hashicorp
``` ```
### Password rotation ### 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: Dynamic credentials can be configured by calling the `/role/:role_name` endpoint:
```bash ```bash
$ vault write auth/ldap/role/dynamic-role \ $ vault write ldap/role/dynamic-role \
creation_ldif=@/path/to/creation.ldif \ creation_ldif=@/path/to/creation.ldif \
deletion_ldif=@/path/to/deletion.ldif \ deletion_ldif=@/path/to/deletion.ldif \
rollback_ldif=@/path/to/rollback.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: To generate credentials:
```bash ```bash
$ vault read auth/ldap/creds/dynamic-role $ vault read ldap/creds/dynamic-role
Key Value Key Value
--- ----- --- -----
lease_id ldap/creds/dynamic-role/HFgd6uKaDomVMvJpYbn9q4q5 lease_id ldap/creds/dynamic-role/HFgd6uKaDomVMvJpYbn9q4q5
@@ -283,7 +283,7 @@ to an AD server.
$ vault secrets enable ldap $ vault secrets enable ldap
Success! Enabled the ad secrets engine at: ldap/ Success! Enabled the ad secrets engine at: ldap/
$ vault write auth/ldap/config \ $ vault write ldap/config \
binddn=$USERNAME \ binddn=$USERNAME \
bindpass=$PASSWORD \ bindpass=$PASSWORD \
url=ldaps://138.91.247.105 \ url=ldaps://138.91.247.105 \
@@ -293,7 +293,7 @@ $ vault write auth/ldap/config \
Our next step is to designate a set of service accounts for check-out. Our next step is to designate a set of service accounts for check-out.
```shell-session ```shell-session
$ vault write auth/ldap/library/accounting-team \ $ vault write ldap/library/accounting-team \
service_account_names=fizz@example.com,buzz@example.com \ service_account_names=fizz@example.com,buzz@example.com \
ttl=10h \ ttl=10h \
max_ttl=20h \ 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. available or checked out.
```shell-session ```shell-session
$ vault read auth/ldap/library/accounting-team/status $ vault read ldap/library/accounting-team/status
Key Value Key Value
--- ----- --- -----
buzz@example.com map[available:true] 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: To check out any service account that's available, simply execute:
```shell-session ```shell-session
$ vault write -f auth/ldap/library/accounting-team/check-out $ vault write -f ldap/library/accounting-team/check-out
Key Value Key Value
--- ----- --- -----
lease_id ldap/library/accounting-team/check-out/EpuS8cX7uEsDzOwW9kkKOyGW 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: for a shorter time by using:
```shell-session ```shell-session
$ vault write auth/ldap/library/accounting-team/check-out ttl=30m $ vault write ldap/library/accounting-team/check-out ttl=30m
Key Value Key Value
--- ----- --- -----
lease_id ldap/library/accounting-team/check-out/gMonJ2jB6kYs6d3Vw37WFDCY 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. If no service accounts are available for check-out, Vault will return a 400 Bad Request.
```shell-session ```shell-session
$ vault write -f auth/ldap/library/accounting-team/check-out $ vault write -f ldap/library/accounting-team/check-out
Error writing data to ldap/library/accounting-team/check-out: Error making API request. 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 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: To check a service account back in for others to use, call:
```shell-session ```shell-session
$ vault write -f auth/ldap/library/accounting-team/check-in $ vault write -f ldap/library/accounting-team/check-in
Key Value Key Value
--- ----- --- -----
check_ins [fizz@example.com] 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. caller, Vault will need to know which one(s) to check in.
```shell-session ```shell-session
$ vault write auth/ldap/library/accounting-team/check-in service_account_names=fizz@example.com $ vault write ldap/library/accounting-team/check-in service_account_names=fizz@example.com
Key Value Key Value
--- ----- --- -----
check_ins [fizz@example.com] 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: service accounts can be forcibly checked in by a highly privileged user through:
```shell-session ```shell-session
$ vault write -f auth/ldap/library/manage/accounting-team/check-in $ vault write -f ldap/library/manage/accounting-team/check-in
Key Value Key Value
--- ----- --- -----
check_ins [fizz@example.com] check_ins [fizz@example.com]