Vault oidc config with Microsoft ADFS : no groups returned in OIDC provider response

We’ve installed and configured Vault v1.11.3 with OIDC and Microsoft ADFS.
We followed and combined following pages to be able to authenticate with OIDC:

https://discuss.hashicorp.com/t/configuring-a-dex-oidc-auth-provider/23124/2

We can authenticate the users with OIDC and ADFS in the browser, but no group is returned
We’ve tested with user_claim=upn or sub
But no group info is returned.

Key Value


allowed_redirect_uris [https://dev-app-vault.mysite.com/ui/vault/auth/oidc/oidc/callback https://localhost:8250/oidc/callback]
bound_audiences [uri:dev-app-vault.mysite.com]
bound_claims
bound_claims_type string
bound_subject n/a
claim_mappings
clock_skew_leeway 0
expiration_leeway 0
groups_claim n/a
max_age 0
not_before_leeway 0
oidc_scopes [openid allatclaims profile]
policies [oidc-policy]
role_type oidc
token_bound_cidrs
token_explicit_max_ttl 10m
token_max_ttl 0s
token_no_default_policy false
token_num_uses 0
token_period 0s
token_policies [oidc-policy]
token_ttl 0s
token_type default
user_claim upn
user_claim_json_pointer false
verbose_oidc_logging true
./vault read /auth/oidc/config
Key Value


bound_issuer n/a
default_role oidc-policy
jwks_ca_pem n/a
jwks_url n/a
jwt_supported_algs
jwt_validation_pubkeys
namespace_in_state true
oidc_client_id uri:dev-app-vault.mysite.com
oidc_discovery_ca_pem n/a
oidc_discovery_url https://acc-claim.mysite.com/adfs
oidc_response_mode n/a
oidc_response_types
provider_config map

log information was received via :

./vault monitor -log-level=trace

2022-11-17T11:05:46.486+0100 [DEBUG] auth.oidc.auth_oidc_4740d27b: OIDC provider response: id_token=………gyMzQifQ.xxxxxxxxxxx
2022-11-17T11:05:46.489+0100 [DEBUG] auth.oidc.auth_oidc_4740d27b: OIDC provider response: claims="{"aud":"uri:dev-app-vault.mysite.com","auth_time":1668668300,"exp":1668683145,"iat":1668679545,"iss":"https://acc-claim.mysite.com/adfs\“,\“nbf\”:1668679545,\“pwd_exp\”:\“2663779\”,\“pwd_url\”:\“https://acc-claim.mysite.com/adfs/portal/updatepassword/\”,\“sid\”:\“S-1-5-21-3675852479-2980802970-892884109-58234\”,\“sub\”:\“6yuyP+Gr9fnDeGrwvgiVsACl+R1gHTBzLyKUyeqVSyk=\”,\“unique_name\”:\“DOMAIN\\\\USERACCOUNT\”,\“upn\”:\“david@mysite.com\”}”

What can we do to receive groups from our OIDC provider?

Best regards,

David

We found why we didn’t receive any groups.

We had to correct/adapt some properties at the ADFS side:

  • Access policy
  • Permitted scope: add profile with the already existing OpenID and AllAtClaims

Maybe this will help someone in his quest to have OIDC working with ADFS.

Best regards,

David

We also had this issue when using Azure AD as an OIDC provider.
This issue happens because Azure doesn’t support using the group name in the id token for AAD groups because the group name might not be unique.

You can use group_ids in the bound claims i.e :

vault write auth/oidc-aad/role/dev- <<EOF
{
  "user_claim": "email",
  "role_type": "oidc",
  "allowed_redirect_uris": ["http://localhost:8250/oidc/callback", "https://vault.xxx.com/ui/vault/auth/oidc-aad/oidc/callback"],
  "groups_claim": "groups",
  "policies": ["dev"],
  "oidc_scopes": "https://graph.microsoft.com/.default",
  "ttl": "2m",
  "bound_claims": { "groups": ["123456-1234-1234-1234-123456789"] }
}
EOF

But that will not be transparent.

Therefore, a better approach would be to create App Roles for your Azure App Registration (SP) and assign those roles to your Azure AD groups. In this way, you can use App Roles as bound claims to map your Azure AD groups with Vault policies i.e :

$ vault write auth/oidc-aad/role/infra - <<EOF
{
  "user_claim": "email",
  "role_type": "oidc",
  "allowed_redirect_uris": ["http://localhost:8250/oidc/callback", "https://vault.xxxx.com/ui/vault/auth/oidc-aad/oidc/callback"],
  "groups_claim": "groups",
  "policies": ["infra"],
  "oidc_scopes": "https://graph.microsoft.com/.default",
  "ttl": "2m",
  "bound_claims": { "roles": ["Infra"] }
}
EOF

Thanks,
eb

Thank you @erlisb for your input.
this will be helpful for the rest of my setup.

regards,

David