Custom Attributes in Entra ID -- Use Cases

This article is the seventh in a series about Custom Attributes in Entra ID and will discuss the use cases of each these approaches. There are seven use cases that have only one solution, three exclusive use cases for Extension Attributes, three exclusive for Custom Security Attributes and one for Directory Extensions.

1. Names and aliases
2. Naming Conventions
3. Resource Types
4. Data Types
5. Lifecycle
6. Limitations
7. Use Cases
8. Decision Tree

My default answer: use a Directory Extension unless you can’t!

• They cover most use cases

• You can create as many definitions as you want

• Each resource can have 100 values

• If you squint your eyes you can ignore the ugly name

  

Extension Attributes

While Extension Attributes cover many of the use cases including all but one of the use cases that Directory Extensions cover you might think that Extension Attributes is the way to go:

• They already exist
• They cover most use cases

But I want you to recall, that we only have 15 Extension Attributes. Furthermore, there are two use cases for users that can only be done using them:

• Making custom data visible on the Profile Card (Only Extension Attributes can be added to the Profile Card and show up “Teams, Outlook, or other Office apps and services.")
• Using Custom Data in membership rules for Exchange Online Dynamic Groups.

We have no other way to do these things. Therefore, I urge you to use Directory Extensions instead and save the Extension Attributes for its exclusive use cases.

Extension Attributes also have an exclusive on using Custom Data for Conditional Access Filters for Devices.

Custom Security Attributes

While Custom Security Attributes have only six uses cases in my list, it is the only way to extend servicePrincipals (Enterprise Applications and Managed Identities) and they do have three exclusive use cases that no other method can satisfy:

• Can be used in conjunction with resource tags inside of Azure ABAC to do finer grained access control. For example you could grant read and/or write permissions to certain Azure resources, such as blobs that have an index tag that matches a custom security attribute on a user or Enterprise Application.

• Conditional Access Filter on Enterprise Applications can provide a great help to categorizing Enterprise Applications (Service Principals, which includes Managed Identities) and then being apply to apply Conditional Access Policies in systematized categoric way. For example, one client has many Storage Account Enterprise Apps that they had excluded individually from a number of policies – creating a management headache.

• Storing custom data in a way that you can allow a user or app to read and write some of the data but not all of it. When a user, group or service principal has access to read a resource in Entra ID they generally have permissions to read everything on the resource. When they have write permissions they generally have permissions to write to all attributes on the resource. Custom Security Attributes presents the only way to add custom data to Entra ID and control who can read which Attribute Sets and who can write to which Attribute Sets. In this way it is very similar to on-prem AD.

  

Schema Extensions

You will notice that Schema Extensions on has only one use case listed:

• It is filterable in Graph queries

In other words you can include properties from a schema extension in a Microsoft Graph Query to limit the results you will get back. The inclusion of only one user case isn’t to say the Schema Extensions have no uses. On the contrary there are resource types where only Schema Extensions and Open Extensions can provide a way to add custom data – the Outlook Resource Types. Application developers are far more likely than Identity Admins and developers to need to customize data on those.

The only real advantages I can see for Schema Extensions over Directory Extensions is that you can have:

• a much friendlier name
• more control over the lifecycle of the Extension
• discoverability of schema extensions

Although, I am not certain that I view the discoverability of schema extensions everywhere in the world as a plus because it means that if I (or my application) can write to a user then I can start using Schema Extensions defined in other tenants. This is bad because I have not found a practical way to discover which Schema Extensions are in use in a particular tenant. To find which Schema Extensions are in use in an Entra ID tenant you have to query Graph for each resource type for each Schema Extension property that is discoverable. Yikes! If someone knows a way please tell the world (and me)!

At least with Directory Extensions you only have to go through the Enterprise Applications in your tenant as opposed to the whole world and then query Graph for each resource type. Not easy but it could be worse.

Open Extensions

Open Extensions on the other hand cannot be included in a graph query. I also haven’t listed a use case for them. From a directory and identity viewpoint there really aren’t any use cases. Even worse to an Entra ID admin it looks like the wild, wild west, where any old cowboy, I mean, application developer can just start writing data to any resource (of the resource types applicable) to which the app has delegated ReadWrite permissions (of course the signed in user must have the permissions to the resource as well).

From an application developer viewpoint, there are loads of use cases for Open Extensions. An application can create up to 2 Open extensions per resource and the number of properties in each resource is only limited by the 2kb limit on directory resources of the Named MAPI Property limits associated with Outlook resources.

From a discoverability standpoint you only have to query each resource in your tenant and access the extensions collection on each resource to find all of the Open Extensions in use your tenant. Child’s Play

<- Previous – Limitations
Next – Decision Tree ->