'Azure AD OIDC Single Sign-On with HashiCorp Vault - Interactive Login Prompt Not Appearing

I have carried out two implementations of Azure AD Single Sign-On with HashiCorp Vault using OIDC and achieved contrasting results which are baffling me.

I have used the same code (Terraform and Vault CLI) to:

  1. Implement the above solution in my private Azure subscription and Vault instance running on localhost, having completed an Azure AD app registration and other required configuration. The result has been an instant success and I am able to achieve a single sign-on into Vault, using my Azure AD credentials for authentication.

  2. Implement the very same solution using my organisation's Azure subscription and Vault instance and even though I can see that the OIDC access method and configuration appears to have been successfully set up in Vault as expected, when I then attempt to login to Vault using OIDC, whether through the UI or Vault CLI (vault login -method=oidc role=aad), the expected interactive login prompt fails to pop up.

I must emphasise though that due to security restrictions within my organisation, the entire setup and configuration in Azure AD (App registration, etc) was carried out manually by a designated team and I had no direct input or involvement whatsoever, so my knowledge on how it was all done is a bit limited.

What could therefore be the most likely cause of the issue described?

I have a strong inkling it may be due to some wrong Azure AD configuration, but without having direct access to our Azure subscription, I can't say for definite. I can only provide some troubleshooting tips to our dedicated Azure team to investigate and hope I can get some pointers, from the feedback on this thread.

azureazure-active-directorysingle-sign-onterraform-provider-azurehashicorp-vault


Solution 1:[1]

If the popup fails to appear, then often it is due to a misconfiguration on the Vault side. Based on your oneline vault login -method=oidc role=aad we can assume the mount is at auth/oidc and therefore the oidc_discovery_url, oidc_client_id, oidc_secret_id, and ideally provider_config should all be set on auth/oidc/config. (You can validate this through a vault read auth/oidc/config command, and the related policy path "auth/oidc/config" { capabilities = ["read"] } should be safe to grant to any Vault super user.)

Inside the role definition at auth/oidc/role/aad the allowed_redirect_uris parameter must match what is reflected in the application tile configuration inside AAD. Also defined are user_claim, TTL values, and oidc_scopes, but usually not token_policies as they often aggregate via the Identity system for human users. (Again, you can validate this through a vault read auth/oidc/role/aad command, and the related policy path "auth/oidc/role/aad" { capabilities = ["read"] } should be safe to grant to any Vault super user.)

Often, people will mistype the role name, and instead of giving an error message, Vault will simply do nothing. But the "do nothing" case can also occur if the role definition or the auth method configuration are in any way incorrect or mismatch the configuration on the identity provider.

If your Vault login is not "doing nothing" and is instead giving an error message, providing that error message would be helpful.

Sources

This article follows the attribution requirements of Stack Overflow and is licensed under CC BY-SA 3.0.

Source: Stack Overflow

Solution Source
Solution 1 spurgavie

Related Questions