IMPORTANT NOTE: This site is not official Red Hat documentation and is provided for informational purposes only. These guides may be experimental, proof of concept, or early adoption. Officially supported documentation is available at and

Considerations when using AAD as IDP

Authors: Ricardo Martins
Last Editor: Ricardo Martins
Published Date: 24 May 2023
Modified Date: 25 May 2023

Author: Ricardo Macedo Martins

May 24, 2023

In this guide, we will discuss key considerations when using Azure Active Directory (AAD) as the Identity Provider (IDP) for your ARO or ROSA cluster. Below are some helpful references:

Default Access for All Users in Azure Active Directory

Once you set up AAD as the IDP for your cluster, it’s important to note that by default, all users in your Azure Active Directory instance will have access to the cluster. They can log in using their AAD credentials through the OpenShift Web Console endpoint:

OpenShift Web Console Login

However, for security purposes, it’s recommended to restrict access and only allow specific users who are assigned to access the cluster.

Restricting Access

To implement access restrictions, follow these steps:

  1. Log in to the Azure Portal and navigate to your AAD instance.

  2. Under Enterprise applications, select the application created for the ARO IDP configuration.

Select Application

  1. In the selected Enterprise application, go to Properties and switch the “Assignment required?” option to YES.

Assignment Required

  1. If you attempt to log in at this point, you will receive a denial error:

Enter your username:

Login Attempt

Enter your password:

Login Attempt 2

The error message indicates that only users specifically granted access to the application are allowed:

Access Denied

  1. To allow access, go to Users and groups in the main blade, click + Add user/group, and add the desired users/groups who should have access to the ARO cluster.

Add User

Search for the desired user/group and click Select.

Assign User

Verify that the user has been assigned:

User Assigned

  1. You should now be able to log in with the specified user/group to your cluster:

Enter your username:

Login Attempt

Enter your password:

Login Attempt 2

You will then be logged in:

Logged In

Approval Workflow

If you receive a message like the one below, it means that your AAD has the admin consent workflow enabled:

Approval Required

In this case, you will need to request and wait for approval from your AAD domain admin. To request access, fill out the request form:

Approval Request

And wait for approval:

Request Sent

Self-Approval Process

If you have administrative privileges, you can self-approve the request by following these steps:

Please note that these steps are based on the official guidance from Microsoft, which is available here.

  1. Go to your Azure Active Directory Tenant > Enterprise Applications > Admin Consent Requests > All (Preview):

Admin Consent Request

  1. Select the application (openshift, in this case) and click Review permissions and consent:

Details Admin Consent Request

  1. A new window will open, prompting you to log in with credentials of an admin with permissions:

Admin Login

  1. Click Accept to consent to the permission:

Permissions Requested

You will then see that the request was approved:

Request Approved

Now you will be able to log in through the AAD option:

OpenShift Web Console Login

Enter your username:

Login Attempt

Enter your password:

Login Attempt 2

It worked!

Logged In

As a best practice, we recommend removing the kubeadmin user after setting up an identity provider. You can find instructions on how to do this here .