Working with Extension Attributes Using Microsoft Graph


It is not possible to specify custom attributes for a user using the Azure portal for Azure AD (at least at the time of writing). Custom attributes (called extension attributes in Azure AD) for a user can only be set using Microsoft’s Graph API. Luckily, Microsoft makes it easy to use the API by using the Graph Explorer. You can sign into Graph Explorer with the same account details that you use to manage Azure AD in the portal. This will give you access to all the API methods without having to worry about authentication, as your signed in account will automatically be used. 

Working with custom attributes 

Once you have signed in, make a GET request to This will return all the applications registered on the Azure AD tenant. Within the list, find the application with the name aad-extensions-app. Do not modify. Used by AAD for storing user data. This is a special “application” created by Azure AD itself. When a user has custom attributes added to this application, those attributes are accessible by all users on the Azure AD tenant. Grab the Id of the application as well as the AppId as you need them both to create or modify custom attributes. For some reason, Azure AD has two different IDs for an application. There also doesn’t seem to be any pattern to which ID is used where. 

Getting extension attributes already created 

You can then get all the custom attributes that have already been created using the following URI:{id}/extensionProperties. 

The {id} should be replaced with the Id you copied previously. 

You’ll see the extension attributes take the format of extension_{AppId}_{extensionName} where AppId is the AppId of that special application we found earlier. However, in the GET URL, we use the normal Id of the application 🤷🏻‍♂️. 

Creating new extension attributes 

To create a new extension attribute, change the GET into a POST and use the same{id}/extensionProperties URL with the following header and request body. 

Content-Type: application/json 

    "name": "extensionName",
    "dataType": "string",
    "targetObjects": [

You’ll see this creates an extension property using the extension_{AppId}_{extensionName} format. 

You can also issue a GET request, removing the body and header to see the new extension property in the list. 

Deleting an extension attribute 

To delete an extension attribute, append the Id of the extension attribute to the URL and change the verb to DELETE. If we use the LikesPizza example from above, the ID would be de49b6f2-07cd-443c-84ba-8f38e0b3e495

After making the request you should receive a 204 response code with nothing in the response body. 

If you execute the GET request again, you’ll see the extension property is no longer in the list. 

Setting an attribute on a user’s profile 

Before we can set the values for an extension attribute on a user, we first need to obtain the user’s ID. The easiest way to do this is by making a GET request to and finding the user in the list. 

To set the custom attribute on a user, you need to make a PATCH request to{id} with the Content-Type header set to application/json and the following request body: 

  "extension_inputAppId_extensionName": "extensionValue"

You should receive a 204 response code and an empty response body. 

You can get the extension attributes for a user using the Graph API by making a GET request to{id}?$select=displayName,extension_inputAppId_extensionName. Unfortunately, I haven’t found a way to list all extension attributes for a user. They need to be queried individually. 


  1. First of all, does your blog have a different background color for different users?

    Second, thank you for pointing out the discrepancy between the attribute ID and the version of the weird transformed version we have to use when calling it in graph. This almost feels like a but on Microsoft’s side. Has this been discussed anywhere, I spent a long time trying to understand what was wrong with my query.

    Also, I wanted to point out that the name isn’t necessarily “aad-extensions-app”. It depends on how it’s initially created. For example, if setup by Azure AD Connect, it’s called “Tenant Schema Extension App”

    1. Hi Mike

      No, the blog doesn’t have different colours for different users – it just has the option to enable Dark mode which toggles between a light-green and a dark navy style.

      I haven’t been able to find the issue with the attribute ID discussed anywhere, and eventually figured out after spending quite a bit of time on it. It is consistent with the various places I’ve used Graph so if it’s a bug, it’s well built into the offering.

      Thanks for the update about the “aad-extensions-app” naming. I don’t think I’ve used a Graph resource that has been created another way, so I haven’t seen a new name yet. That’s good to know though as I’ll likely come across something new at some time in the future.

      1. Very helpful article, thanks! And for what it’s worth, in my case, the pertinent app name was “b2c-extensions-app. Do not modify. Used by AADB2C for storing user data.” because I am using a B2C tenant.

  2. Hey, to add some clarification here. The app you are using is for Azure AD B2B If you need to do above, i recommend creating a fresh Enterprise App.

    Tenant Schema Extension App is the app created by Azure AD Connect. You can only add extensions to this app via AADC. If you try to do it via graph you will receive the error below.


  3. Hi.
    To GET (READ) the extension attributes for a user, is User.Read.All sufficient or Directory.Read.All needed? We have a multi-tenant app that has been consented by the remote tenant Admin with User.Read.All app perms but unable to fetch the extension attributes via that access token.


    (a user inside the tenant is able to see all the extension attributes using the Graph Explorer /me user end point)

Leave a comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.