LDAP Auth Method - Fixing broken policy template due upgrade to Vault 1.9.x

The below steps applied to Vault 1.9.x only. If you are using Vault 1.10, please click HERE and HERE for latest updates. 

A change introduced in #11000 introduced a subtle change to entity aliases if upndomain is configured or if you don't have binddn configured (using anonymous binds) . For more information click here.

When using upndomain, the name value in the alias now contains the value stored in upndomain:

{
  "data": {
    "aliases": [
      {
        ...
        "name": "bob@corp.example.net"
      }
    ],
  },
}

This has caused issues in 1.9.x where users are using templated policies and now the UPN domain is being appended. A solution introduced in 1.9.x (#13726) to add alias.metadata.name which contains the raw username without UPN domain.

"aliases": [
  {
    "canonical_id": "c05d6c0a-8d0b-f10b-ab9a-26bb09abf821",
    "creation_time": "2022-01-14T22:00:51.8852898Z",
    "custom_metadata": null,
    "id": "290f51a7-14d9-8488-c344-20ce7b159fd5",
    "last_update_time": "2022-01-14T22:00:51.8852898Z",
    "local": false,
    "merged_from_canonical_ids": null,
    "metadata": {
      "name": "bob"
    },
    "mount_accessor": "auth_ldap_6e553280",
    "mount_path": "auth/ldap/",
    "mount_type": "ldap",
    "name": "bob@corp.example.net"
  }

In contrast, a templated policy that is used with ldap auth method in vault versions < 1.9.x will be in this format:

ACCESSOR=$(vault auth list -detailed | grep ldap | awk '{ print $3 }')

vault policy write dev - <<EOF
path "secret/data/{{identity.entity.aliases.${ACCESSOR?}.name}}/*" {
  capabilities = ["read"]
}

For templated policy with vault > 1.9.x

ACCESSOR=$(vault auth list -detailed | grep ldap | awk '{ print $3 }')

vault policy write dev - <<EOF
path "secret/data/{{identity.entity.aliases.${ACCESSOR?}.metadata.name}}/*" {
  capabilities = ["read"]
}