Part of this article needs the configuration parameter raw_storage_endpoint enabled and uses a token with a privileged policy on the path of: sys/*. A root-token is used in the demonstrations below.

As a Vault administrator you may be faced with the task of identifying tokens, leases or entities that may be associated to the respective identities in each mount.

Listing Token Accessors & Entities

The API or CLI list operation can be used on the path below to gain listings of:

/sys/leases/lookup - all leases presently applicable to any mount
/auth/token/accessors - accessor IDs of all generated tokens present

For example - using a newly installed Vault instance containing only the initial root token - we can use the listed accessor_id to perform a lookup where the parameters of: display_name, path, policy as well some others can help to identify its origin and owner.

# // list current auth accessors
vault list auth/token/accessors
  # Keys
  # ----
  # 3LtijwdXqw3AxuffghdRXREq

vault token lookup -accessor 3LtijwdXqw3AxuffghdRXREq
  # Key Value
  # --- -----
  # accessor 3LtijwdXqw3AxuffghdRXREq
  # creation_time 1632493058
  # creation_ttl 0s
  # display_name root
  # entity_id n/a
  # expire_time <nil>
  # explicit_max_ttl 0s
  # id n/a
  # meta <nil>
  # num_uses 0
  # orphan true
  # path auth/token/root
  # policies [root]
  # ttl 0s
  # type service
# // ^^ note that it's root from display_name, path & 'root' policy.

Accessors from other authentication mounts such as LDAP should be distinguishable by the difference in parameter values as seen in the following example:

# // After auth method (LDAP) setup & with creds generated by Vault.
vault list auth/token/accessors
  # Keys
  # ----
  # 3LtijwdXqw3AxuffghdRXREq
  # QBf9Rs3fTr8wlxJMoSDYCXhu

vault token lookup -accessor QBf9Rs3fTr8wlxJMoSDYCXhu
  # Key Value
  # --- -----
  # accessor QBf9Rs3fTr8wlxJMoSDYCXhu
  # creation_time 1632833445
  # creation_ttl 768h
  # display_name ldap-laura
  # entity_id cbd0846f-ed05-794c-d1cb-438b955b1de3
  # expire_time 2021-10-30T12:50:45.693048108Z
  # explicit_max_ttl 0s
  # id n/a
  # issue_time 2021-09-28T12:50:45.69305424Z
  # meta map[username:laura]
  # num_uses 0
  # orphan true
  # path auth/ldap/login/laura
  # policies [default]
  # renewable true
  # ttl 767h47m43s
  # type service
# // ^^ here we see this relates to ldap auth path.

The entity_id that's automatically generated by Vault can be read via a list on the /identity/entity/id API showing affiliated aliases, entity associations to the related mounts, roles or users - like for example :

vault read /identity/entity/id list=true -format=json
  # {
  #   "request_id": "630e0a42-6131-6235-bc70-6202a2f0ace8",
  #   "lease_id": "",
  #   "lease_duration": 0,
  #   "renewable": false,
  #   "data": {
  #     "key_info": {
  #       "cbd0846f-ed05-794c-d1cb-438b955b1de3": {
  #         "aliases": [
  #           {
  #             "id": "30972c7c-6c35-2ce5-0e5a-4e4395426965",
  #             "mount_accessor": "auth_ldap_13e27271",
  #             "mount_path": "auth/ldap/",
  #             "mount_type": "ldap",
  #             "name": "laura"
  #           }
  #         ],
  #         "name": "entity_00432429"
  #       }
  #     },
  #     "keys": [
  #       "cbd0846f-ed05-794c-d1cb-438b955b1de3"
  #     ]
  #   },
  #   "warnings": null
  # }

In the event that the LDAP auth mount in question is disabled and re-setup anew - a re-listing of /identity/entity/id will highlight former aliases that are clearly without any associated mount_type or mount_path (it can be a blank empty string "" too in some places)

vault read /identity/entity/id list=true -format=json
  # {
  #   "request_id": "dbb09de1-07d2-7fa1-2b85-2448fd01a9da",
  #   "lease_id": "",
  #   "lease_duration": 0,
  #   "renewable": false,
  #   "data": {
  #     "key_info": {
  #       "b17a5426-990c-58f7-af16-7b2f3c5aed24": {
  #         "aliases": [
  #           {
  #             "id": "9a377edd-2b53-08d4-a879-57059ff0c318",
  #             "mount_accessor": "auth_ldap_3569a3e6",
  #             "mount_path": "auth/ldap/",
  #             "mount_type": "ldap",
  #             "name": "andrew"
  #           }
  #         ],
  #         "name": "entity_d4d634e1"
  #       },
  #       "fe3c5bb1-a667-bdc7-8a49-29131f53a33b": {
  #         "aliases": [
  #           {
  #             "id": "6fec61e1-da0e-1a53-bc57-f9cf58b3eb53",
  #             "mount_accessor": "auth_ldap_3569a3e6",
  #             "mount_path": "auth/ldap/",
  #             "mount_type": "ldap",
  #             "name": "laura"
  #           }
  #         ],
  #         "name": "entity_657e082d"
  #       },
  #       "cbd0846f-ed05-794c-d1cb-438b955b1de3": {
  #         "aliases": [
  #           {
  #             "id": "30972c7c-6c35-2ce5-0e5a-4e4395426965",
  #             "mount_accessor": "auth_ldap_13e27271",
  #             "name": "laura"
  #           }
  #         ],
  #         "name": "entity_00432429"
  #       }
  #     },
  #     "keys": [
  #       "b17a5426-990c-58f7-af16-7b2f3c5aed24",
  #       "fe3c5bb1-a667-bdc7-8a49-29131f53a33b",
  #       "cbd0846f-ed05-794c-d1cb-438b955b1de3"
  #     ]
  #   },
  #   "warnings": null
  # }
# // ^^ former 'laura' alias is no longer linked to any mount.

Listing Leases

Viewing all of the leases presently stored in Vault can be done by starting at the root-level listing of /sys/leases/lookup - which lists both auth and secrets at the root-level or just auth if only authentication related leases are present.

Each auth and secrets path can be further detailed to comprise a complete path where the listed key values are the individual leases that are current - like for example:

vault list /sys/leases/lookup/auth
 # // ...
vault list /sys/leases/lookup/auth/ldap
 # // ...
# // ^^ vault list each sub-path till keys are listed:

vault list /sys/leases/lookup/auth/ldap/login/andrew
  # Keys
  # ----
  # h900f21036a8d83528ec6beaa4aa5a6cfdb1ddcbbc1ed7df18c4c74a4ec50d7b9
  # hc569e568a1e79095a1cf8e1d42784efe9c7b8dbab39756ef7d5c61948c839386
# // ^^ LDAP user Andrew has two leases

Performing a lease lookup of one of the above leases via CLI will show important TTL and duration related properties such as:

VLEASE_PATH=auth/ldap/login/andrew/h900f21036a8d83528ec6beaa4aa5a6cfdb1ddcbbc1ed7df18c4c74a4ec50d7b9
vault write /sys/leases/lookup lease_id=${VLEASE_PATH} -format=json
  # {
  #   "request_id": "d71f1e39-f6be-4e7b-e2b6-fd46992672a2",
  #   "lease_id": "",
  #   "lease_duration": 0,
  #   "renewable": false,
  #   "data": {
  #     "expire_time": "2021-10-30T13:23:17.639897824Z",
  #     "id": "auth/ldap/login/andrew/h900f21036a8d83528ec6beaa4aa5a6cfdb1ddcbbc1ed7df18c4c74a4ec50d7b9",
  #     "issue_time": "2021-09-28T13:23:17.639904852Z",
  #     "last_renewal": null,
  #     "renewable": true,
  #     "ttl": 2759489
  #   },
  #   "warnings": null
  # }

In the above example a positive TTL is indicative of the leases validity and the parameters of expire_time as well as issue_time help to determine its validity or relevance, whereas a negative TTL is hinting to potential issues with the revocation that was last performed. The revocation of leases use the complete lease_id path and can resemble:

VLEASE_PATH=auth/ldap/login/andrew/h900f21036a8d83528ec6beaa4aa5a6cfdb1ddcbbc1ed7df18c4c74a4ec50d7b9
vault lease revoke ${VLEASE_PATH}
  # All revocation operations queued successfully!

# // consider --force & --prefix as needed eg:
# vault lease revoke --force --prefix ...

However - in some cases you may be investigating a particular lease and striving to traverse directly to its token or accessor. This is possible in cases where raw_storage_endpoint is enabled (which should be used cautiously since it will divulge actual end-user tokens). Using the CLI utility jq to parse JSON responses from Vault - the example below can be used to read the lease in more detail:

vault read /sys/raw/sys/expire/id/${VLEASE_PATH} -format=json | jq .'data.value' | sed 's/\\"/"/g' | sed 's/\"{/\{/g' | sed 's/}\"/}/g' | jq
  # {
  #   "lease_id": "auth/ldap/login/andrew/h900f21036a8d83528ec6beaa4aa5a6cfdb1ddcbbc1ed7df18c4c74a4ec50d7b9",
  #   "client_token": "s.4lq1uAI705DstEWNlaMGOdjY",
  #   "token_type": 0,
  #   "path": "auth/ldap/login/andrew",
  #   "data": null,
  #   "secret": null,
  #   "auth": {
  #     "lease": 2764800000000000,
  #     "max_ttl": 0,
  #     "renewable": true,
  #     "internal_data": {
  #       "password": "andrew"
  #     },
  #     "display_name": "ldap-andrew",
  #     "policies": null,
  #     "token_policies": [
  #       "default"
  #     ],
  #     "identity_policies": null,
  #     "external_namespace_policies": null,
  #     "no_default_policy": false,
  #     "metadata": {
  #       "username": "andrew"
  #     },
  #     "client_token": "s.4lq1uAI705DstEWNlaMGOdjY",
  #     "accessor": "4V2AECc42R0y1fygZl9Vre6K",
  #     "period": 0,
  #     "explicit_max_ttl": 0,
  #     "num_uses": 0,
  #     "entity_id": "b17a5426-990c-58f7-af16-7b2f3c5aed24",
  #     "alias": {
  #       "mount_type": "ldap",
  #       "mount_accessor": "auth_ldap_3569a3e6",
  #       "name": "andrew"
  #     },
  #     "group_aliases": null,
  #     "bound_cidrs": null,
  #     "creation_path": "",
  #     "token_type": 1,
  #     "orphan": true
  #   },
  #   "issue_time": "2021-09-28T13:23:17.639904852Z",
  #   "expire_time": "2021-10-30T13:23:17.639897824Z",
  #   "last_renewal_time": "0001-01-01T00:00:00Z",
  #   "version": 1
  # }

In the above example we can see the completed correlation of the lease to the related accessor and all other available details.

Resources

Docs: vault list
Docs: List Entities by ID
Docs: Tokens - List Accessors
Docs: Read Lease
Learn: Auth Methods - Token
Learn: Token Management
Learn: Troubleshoot Irrevocable Leases
Docs: Vault Limits and Maximums - Entity and group limits

Identifying Tokens, Leases and Entities

Listing Token Accessors & Entities

Listing Leases

Resources

Articles in this section

Listing Token Accessors & Entities

Listing Leases

Resources

Articles in this section

Related articles