May's Blog

If you’ve ever tried to shoehorn your organization’s identity requirements into Azure AD’s default schema, you’ve probably come up against that all-too-familiar frustration: “Why can’t I store this one extra user field?” Much like Itachi Uchiha hiding years of backstory beneath a single Sharingan stare, Azure Active Directory hides a surprising amount of extensibility under its sleek UI. Recently, I came across this excellent post by Boris Bajonczak on extending Azure AD with custom attributes via Microsoft Graph API. It’s a dense topic that many developers and IT admins shy away from—but trust me, it’s one worth diving into.

Let’s unpack the magic, wonder, and yes, some lurking potential dangers of customizing Azure AD schemas using Microsoft Graph… with a few nods to open source, security best practices, and anime logic along the way.

🔍 The TL;DR: Can You Just Add Custom Attributes to Azure AD?

Out of the box, Azure Active Directory offers standard user attributes like displayName, jobTitle, and department—but sometimes your organization needs more. Think internal employee codes, skill badges, or even favorite anime characters as profile attributes (hey, don’t judge—culture fit matters).

Microsoft Graph API lets you extend the Azure AD schema using custom directory extensions. This feature is incredibly versatile, but poorly understood.

Bajonczak’s guide provides a solid roadmap to:

Sounds easy enough, right? But as with anything involving identity management and cloud infrastructure, the devil’s in the details—and the permissions.

🔧 How It Actually Works: Schema Extensions 101

Instead of just throwing in your own fields willy-nilly (thankfully), Azure requires you to define a “schema extension” first. Think of this like creating a new class definition in a TypeScript model.

Here’s what’s involved:

  1. Define a schema extension by POSTing to /schemaExtensions
  2. Provide a unique ID and a set of custom fields (up to 100 per extension)
  3. Wait until the extension becomes ‘Available’ (this can take several minutes)
  4. Patch the extension values into user objects

Example Snippet from Bajonczak:

 1POST https://graph.microsoft.com/v1.0/schemaExtensions
 2{
 3  "id":"maymeow_customAttr",
 4  "description":"Extra AD attributes for user tracking",
 5  "targetTypes":["User"],
 6  "properties":[
 7    {
 8      "name":"githubUsername",
 9      "type":"String"
10    },
11    {
12      "name":"favoriteAnime",
13      "type":"String"
14    }
15  ]
16}

Once created and available, you can use PATCH to attach it to a user:

1PATCH https://graph.microsoft.com/v1.0/users/{id}
2{
3  "extension_maymeow_customAttr_githubUsername": "maycOpen",
4  "extension_maymeow_customAttr_favoriteAnime": "Steins;Gate"
5}

That’s it. Your Azure AD user profile now contains the spicy metadata your environment needs.

But wait—it gets better/worse.

🛡️ Security Considerations: What Could Go Wrong?

Here’s where my cybersecurity spidey sense (or should I say, ninja intuition) starts tingling. Extending your directory schema isn’t dangerous per se—but if you’re not careful, you’re adding shadow data to your most critical identity system.

Ask yourself:

Even more importantly, data stored in Azure AD is often replicated across services via SAML claims, OAuth tokens, or SCIM provisioning systems. If that new “favoriteAnime” claim ends up escaping into your HR SaaS, questions will be asked 😅.

You’ll want to:

👥 Open Source, Compliance… and When to Use Something Else

As an open-source advocate, I have to raise this point: not everything needs to live inside Azure AD. While extending the directory schema makes sense for cloud-native environments, sometimes a better approach is to manage metadata in a separate app registry or identity overlay built on open tools (e.g., Keycloak, Gluu, or WSO2).

That’s especially true if:

If you’re extending Azure AD extensively, you may be building what should be a separate identity management layer. I’ve seen this become technical debt real fast.

💡 Developer Pro Tips (From the Trenches)

Having wrestled with Microsoft Graph APIs during late-night hackathons (yes, I once debugged a permissions issue while watching Eva Rebuild 3.33—do not recommend), here are a few practical tips:

And always… Always document your schema extensions. Future You will thank you.

🌐 Community Signal Boost: OSS Identity Projects

If this topic excites you (yes, it should), don’t stop at Azure. The identity space is buzzing with open-source initiatives:

Let’s push Microsoft to be more transparent about roadmap and field limits—and maybe even open up schema extension lifecycle management via ARM templates or Terraform 😎.

📎 Conclusion: Should You Extend Azure AD?

If you need richer user metadata in your identity layer, schema extensions are a powerful, legit approach—so long as you go in with eyes wide open. Just like a character building a custom Gunpla in Gundam Build Fighters, you’re customizing a framework with precision—and potential pitfalls.

Keep your extension footprint minimal, permissions tight, and your documentation gold-tier. Consider your data lifecycle. And when in doubt… don’t store it in Azure AD.

And hey, what would your favorite anime character want listed as their Azure user attributes? Get creative (securely).

—

Have you implemented custom schema extensions in Azure AD? What best practices or gotchas can you share? Hit me up in the comments or on GitHub—I’d love to hear how folks are extending identity the smart way.

Stay secure, stay curious—and yes, don’t forget to back up your schema.

Keywords: Azure AD custom attributes, Microsoft Graph API, schema extension, cybersecurity, open source identity, Azure AD best practices, identity management, Microsoft Graph tutorials, user metadata, Azure security tips

#Azure AD #Microsoft Graph #Custom Attributes #Cybersecurity #Open Source #Identity Management