Configuring Azure Active Directory (AAD) with Consul using OpenID Connect (OIDC) – HashiCorp Help Center

The information contained in this article has been verified as up-to-date on the date of the original publication of the article. HashiCorp endeavors to keep this information up-to-date and correct, but it makes no representations or warranties of any kind, express or implied, about the ongoing completeness, accuracy, reliability, or suitability of the information provided.

All information contained in this article is for general information purposes only. Any reliance you place on such information as it applies to your use of your HashiCorp product is therefore strictly at your own risk.

Introduction

Expected Outcome

Configure Consul OIDC with Azure Active Directory Single Sign-On (SSO).

Prerequisites

An enterprise license for Consul
- OIDC Auth Method requires a Consul enterprise license with all modules enabled for it
An active Azure subscription and a user with the proper roles
- See the prerequisites on Microsofts learning pages

Use Case

Enabling users to authenticate to the Consul UI via OIDC Auth Method on Azure Active Directory (AD)

Procedure

This configuration takes place in 2 areas.

Azure AD Configuration
Consul Configuration

Azure AD Configuration

Log in to Microsoft Azure.
Go to Azure Active Directory.
- TenantID will be used as part of the endpoint in the OIDCDiscoveryURL in the oidc.json file.
Go to App registration and click on New registration as shown below.
- The Application (client) ID is used as the OIDCClientID in the Consul oidc.json file.
Enter a Name and the Redirect URI for Consul in the settings.
1. Select Web for the type of Redirect URI.
2. The two URLs needed are comma-separated and as follows.
  - The below example uses HTTP, but HTTPS is preferred by Azure.
  - Azure will only allow HTTP on localhost.
```
http://localhost:8550/oidc/callback,http://localhost:8500/ui/oidc/callback
```
Go to Certificates & secrets and click New client secret.
- Save the value of the SECRET as it is used as the OIDCClientSecret in the oidc.json file.
  - The secret is visible only at the time of creation and if lost then a new Secret needs to be created.

Consul Configuration

Write an ACL policy as per our requirements.
- The below example has the following configurations associated with it
  - The user has access to everything except for the KV store.
  - The policy name used is oidc_policy
  - The corresponding file name is oidc_policy.json and was saved in the /etc/consul.d folder.
```
acl = "write"
agent_prefix "" {
  policy = "read"
}
service_prefix "" {
  policy = "read"
}
node_prefix "" {
  policy = "read"
}
key_prefix "" {
  policy = "deny"
}
```
After the policy is created, create a role in Consul that will be assigned this policy.
- All users in the SSO group will require this authorization based on this policy.
  consul acl role create -name "oidc_user" -policy-name "oidc_policy"

Create the oidc.json file.
For example: touch /etc/consul.d/oidc.json

Below are the bare minimum configurations to get OIDC correctly registered and working between Consul and Azure AD.

{
  "Name": "oidc2",
  "Type": "oidc",
  "Description": "example oidc auth method",
  "MaxTokenTTL": "15m",
  "Config": {
    "OIDCDiscoveryURL": "<OpenID Connect metadata document URL from Endpoints of the App>",
    "OIDCClientID": "<Application (client) ID from step 3 in the Azure AD Configuration section>",
    "OIDCClientSecret": "<The secret from step 5 in the Azure AD Configuration section>",
    "AllowedRedirectURIs": [
      "http://localhost:8550/oidc/callback",
      "http://localhost:8500/ui/oidc/callback"
    ]
  }
}

The OIDCDiscoveryURL can be found by clicking on the Endpoints tab of the particular App Registration Overview page and copying the OpenID Connect metadata document URL.
DO NOT add the string /.well-known/openid-configuration into the OIDCDiscoveryURL as it may cause issues with the connection due to Consul adding that string to all URL values encountered in the file automatically.

Create an oidc type auth-method in Consul via the CLI
- In this example we use -name-oidc2; however, oidc2 is an arbitrary name.
```
consul acl auth-method create -type=oidc -name=oidc2 -config=@/etc/consul.d/oidc.json -max-token-ttl="15m"
```
Once the auth-method and the user role are created, create a bind-rule from the AD OIDC auth method to the user role.
```
consul acl binding-rule create -bind-name "oidc_user" -bind-type "role" -method "oidc"
```

Test the Configuration

After everything is enabled and you navigate to the Consul UI, you should see a similar Log in page

All applications created under the OIDCDiscoverURL will be listed here.

If you have a valid enterprise Consul license, then the SSO option will be available and you can click on it to log in. Upon successful authentication, the user is redirected back to Consul UI.

It is worth noting that upon successful login, a new token is created via the OIDC login.

Additional Resources