Rolling Out Phishing-resistant MFA Org wide with Microsoft Entra ID

 I recently moved an entire organisation to passkeys in Microsoft Entra ID with a 1 month deadline. This post is the short version of how I did it: what counts as phishing-resistant, what to set up first, how the registration campaign works, and the Conditional Access policy that makes it stick. At the end I share what I learned along the way.

Why phishing-resistant MFA matters

MFA alone is no longer enough. Attackers use adversary-in-the-middle phishing kits that relay the user's sign-in in real time, steal the session token and walk straight past SMS codes and push approvals. MFA fatigue attacks do the same thing with less effort: spam push notifications until someone taps Approve.

Phishing-resistant methods stop this because the credential is bound to the real sign-in domain. A fake login page simply can't use it. The user doesn't have to spot the phish for the protection to work.

In Entra ID, this is what counts:

Phishing-resistant	Not phishing-resistant
Passkeys (FIDO2) on security keys	SMS and voice call
Passkeys in Microsoft Authenticator (device-bound)	One-time codes (Authenticator, hardware or software OATH tokens)
Synced passkeys (iCloud Keychain, Google Password Manager and similar)	Microsoft Authenticator push, even with number matching
Windows Hello for Business	Email OTP
macOS Platform SSO (platform credential)	Password on its own
Certificate-based authentication (multifactor)

The built-in Phishing-resistant MFA authentication strength in Conditional Access covers the left column. That's what we enforce later in this post.

Since 1 September 2026, SMS and voice users get the passkey nudge, but they can still skip it as often as they like. The blocking prompt only starts on 1 February 2027, or 1 July 2027 for Global Administrators and external users

Step 1: Get the passkey method ready

The registration campaign does nothing useful until the Passkey (FIDO2) method is set up properly. Skip this and users get prompted, try to register, and fail. That's a helpdesk ticket for every one of them.

Go to Entra admin center > Entra ID > Authentication methods > Policies > Passkey (FIDO2) and do the following:

1. Enable the method and target All users (or the groups you're rolling out to). Anyone you'll target in the campaign must be in scope here too.
2. Opt in to passkey profiles if you haven't already. Your existing settings move into a Default passkey profile. Note that you can't opt out afterwards.
3. In the Default profile, set Allow self-service setup to Yes. Without this, users can't register a passkey themselves and the campaign has nothing to point them to.
4. Under Passkey types, select both Device-bound and Synced. Device-bound covers security keys and Microsoft Authenticator. Synced covers passkeys stored in iCloud Keychain, Google Password Manager and other providers, which follow the user to their other devices.
5. Set Enforce attestation to No. Synced passkeys don't support attestation, so this option disappears from Passkey types if attestation is enforced.
6. Leave key restrictions off unless you have a specific list of approved authenticators.

A quick word on synced passkeys. They make the rollout much smoother because users can register once and sign in from their phone, laptop and tablet. The trade-off is that the passkey lives with a consumer provider and you can't verify the make or model. If that's a problem for your admins, create a second profile for privileged users with device-bound only and attestation enforced. You can have up to three profiles.

If you're using passkeys in Microsoft Authenticator, make sure users are on a current version of the app before you start.

Step 2: Configure the registration campaign

The registration campaign (the "nudge") prompts users to set up a passkey right after they complete MFA. It's the easiest way to get people registered without chasing them one by one.

Go to Entra admin center > Entra ID > Authentication methods > Registration campaign. First, check the current state. Many tenants are already on Microsoft managed, which nudges users daily but lets them skip forever. If you have a deadline, you need to take control.

Setting	What it does	What I used
State	Microsoft managed uses Microsoft's defaults and can change without notice. Enabled gives you control. Disabled turns it off.	Enabled
Authentication method	The method users are prompted to register. Only one at a time.	Passkey (FIDO2)
Days allowed to snooze	How long the prompt stays hidden after a user selects Skip for now. 0 to 14 days.	2 (short deadline)
Limited number of snoozes	Enabled: three skips, then registration is required. Disabled: unlimited skips.	Enabled
Include	Who gets prompted.	All users (dynamic Group)
Exclude	Who never gets prompted.	Break-glass, service and shared accounts

How the three skips work

With Limited number of snoozes enabled, every user gets three chances to skip. After the third skip and its quiet period, the next prompt has no skip button. They register a passkey or they don't get in.

With a 2-day snooze, a user who signs in every day looks like this:

1. Day 0: first prompt, skip 1
2. Day 2: skip 2
3. Day 4: skip 3
4. Day 6: registration required

That's the best case. A few things stretch it out in real life:

• The prompt only shows at an interactive MFA sign-in. No reminder emails, no notifications. Weekends and long-lived sessions push the dates back.
• Each user's clock starts at their own first prompt, not the day you saved the setting.
• Users who already have a suitable passkey on that device and browser aren't prompted at all.
• Snooze counts are kept per user and survive configuration changes. Decide your settings up front, because changing them later won't hand out fresh skips.

Rule of thumb for picking the snooze days: the forced date is roughly three times the snooze value after the first prompt. Two weeks to deadline? Use 1 or 2 days. A relaxed six-week rollout? 14 days works fine.

Step 3: Enforce with Conditional Access

The campaign gets passkeys registered. It doesn't make anyone use them. Until Conditional Access requires phishing-resistant authentication, users can still sign in with push or SMS, and so can an attacker.

Create a new policy under Entra admin center > Entra ID > Conditional Access > Policies:

Setting	Value
Name	CA - Require phishing-resistant MFA - All users
Users: Include	All users
Users: Exclude	Break-glass accounts, plus a time-limited exceptions group
Target resources	All resources, exclude any application that not working with Phishing-resistant MFA
Conditions	location exclude (This will help you to exclude some servers)
Grant	Grant access, Require authentication strength: Phishing-resistant MFA
Session	None
Enable policy	Report-only first, then On

•  Excluding location will help you some server location which some users need to sign-in insider the RDP.
•  Users: Exclude, time-limited exceptions group help admin users to exclude them self when they required. PIM group with timebound with eligible membership.  

A few things worth knowing before you flip it to On:

• Run report-only for at least a week. Check the sign-in logs or the Conditional Access insights workbook to see exactly who would be blocked. That list is your to-do list.
• Think about guests. Guest users authenticate in their home tenant, so this policy will hit them differently. Many teams exclude guests at first and handle them in a separate policy.
• Service and shared accounts that sign in interactively need a plan. Workload identities aren't covered by this policy, but anything signing in as a user is.
• Have a recovery path. Keep Temporary Access Pass (TAP) ready for users who are locked out or replacing a device, and test the TAP flow against this policy before go-live.
• Stage it if you can. Start with IT, then expand group by group. If you have a hard deadline like I did, at least have report-only running while the campaign does its work.

What I learned doing this for real

Check what's already running. When I opened the registration campaign page, it was already on Microsoft managed and targeting passkeys. Users had been getting daily prompts and skipping them with no limit. Nobody had noticed. Look before you plan.

Measure first. A lot of our users already had passkeys. The User registration details report showed me the real gap, and it was much smaller than "All users" suggested. That changed how hard I needed to push.

The check is per device, not per account. Someone with a passkey on their phone can still get prompted on a new laptop or browser. Test this with users who are already registered, otherwise you'll get confused tickets.

The best phishing-resistant options for users are Windows Hello and passkeys. For Windows users, I recommend Windows Hello and the passkey option, based on user preference. For Mac users, synced passkeys through iCloud should be sufficient. This will provide a better user experience. Additionally, AVD supports passkeys.

Build the exclusion group on day one. Break-glass, service accounts, shared mailboxes and privileged vaulted accounts. If a break-glass account gets forced into registration in the middle of an outage, you'll have a very bad day.

The snooze math is the minimum. On paper our forced date was six days out. In practice weekends pushed most people to day eight or nine. Plan helpdesk cover for the peak, not just the first day.

Write one short guide. One page with screenshots for Windows, Mac, iPhone and Android. Send it before the prompts get serious, and give the helpdesk the same guide plus the TAP process.

Plan for the last few percent. You won't hit 100% by the deadline. People are on leave, devices break. Put them in an exceptions group with an owner and an expiry date, and don't let them hold up enforcement for everyone else.

Do the change request properly. Even though it's a settings change, it changes how every user signs in. A clear backout plan (switch Limited number of snoozes to Disabled, or set the CA policy back to report-only) made approval easy.

Quick checklist

• Passkey (FIDO2) enabled and scoped to the users you'll target
• Allow self-service setup set to Yes
• Passkey profile allows device-bound and synced passkeys (attestation off)
• Exclusion group created for break-glass, service and shared accounts
• Baseline taken from User registration details
• Registration campaign set to Enabled, Passkey (FIDO2), snooze days picked for your deadline, limited snoozes on
• User guide sent and helpdesk briefed, TAP process ready
• Conditional Access policy requiring Phishing-resistant MFA running in report-only
• Stragglers chased, exceptions group with expiry dates
• Conditional Access policy switched to On

Passkeys are the first MFA rollout I've done where users actually said sign-in got easier. Get the setup right before you turn on the campaign, and the rest mostly takes care of itself.

Read More

When Windows Hello for Business breaks after someone deletes it from Entra ID

This one came up at work last week. An engineer’s Windows Hello for Business entry got deleted from Entra ID. Right after that, she was stuck in a loop of sign-in prompts asking her to set up authentication again, her PIN stopped working, and when she tried to add a passkey from the Security info page she got this:

“Passkey not registered. This might be due to a timeout, a canceled request or a private browsing window.”

None of those reasons was the real cause, which is why it took a bit of digging. If you manage Entra ID, you will probably run into this too, so here is what was going on and how I fixed it.

What was actually wrong

Windows Hello for Business works with a key pair. The private key lives on the device, protected by the TPM, and the PIN or fingerprint unlocks it. The public key is registered on the user’s account in Entra ID.

When you delete the Windows Hello entry from the user’s Authentication methods page, you only remove the public key. The private key and the PIN container are still sitting on the laptop. So Windows thinks Hello is set up and keeps trying to sign in with a key that Entra has never heard of. The user can’t simply set it up again either, because the old container is still in the way.

I confirmed it by running this in her own session:

dsregcmd /status

Under User State, NgcSet was YES, so a Hello container existed locally. But the SSO State section showed the PRT failing with these errors:

AADSTS130004: UserPrincipal doesn't have the NGC key configured
AADSTS135010: UserPrincipal doesn't have the key ID configured

Both mean the same thing. The device is presenting a Hello key and Entra has no matching one on the user. The Authentication methods page in the portal showed no Windows Hello entry at all, which matched.

One small tip. Run dsregcmd /status as the affected user, not as yourself or an admin. NgcSet is per user, so if you run it under another account you will be looking at the wrong container.

How I fixed it

The goal is to clear the old container on the device so Windows can start fresh and register a new key.

First, the user needs a way to sign in that isn’t the PIN. A password works, or a passkey. If she can’t pass MFA because her methods are tangled up in the same mess, issue a Temporary Access Pass.

Then remove the old PIN. Go to Settings, Accounts, Sign-in options, PIN (Windows Hello), and select Remove. If that button is greyed out or fails, open a command prompt in the user’s session and run:

certutil -deletehellocontainer

Sign out and restart the machine so the container is really gone.

After the restart, sign in with the password. The Windows Hello setup prompt should show up. She goes through MFA, sets a new PIN, and adds a fingerprint or face if the laptop supports it. The whole thing takes two to five minutes. If the laptop was only recently enrolled in Intune, the policy may take a while to arrive, and you can speed it up with a manual sync under Settings, Accounts, Access work or school, Info, Sync.

To check that it worked, run dsregcmd /status again. NgcSet should be YES with a new NgcKeyId, different from the old one. Then refresh the user’s Authentication methods page in Entra and you should see the Windows Hello entry back. If the portal looks stale, which it sometimes does, ask Graph directly:

GET /users/{id}/authentication/windowsHelloForBusinessMethods

About that “Passkey not registered” message

That popup is a generic error from the passkey registration flow, and the text it gives is only a guess at the cause. A timeout, a cancelled prompt, or a private browsing window can all trigger it, so it is worth retrying once in a normal window and finishing the Windows Security prompt quickly.

In this case the real problem was the broken Hello state on the device. Once the container was cleared and Hello was re-provisioned, there was nothing left to fix on the passkey side. If you still see the error after that, check whether your authentication methods policy actually allows that passkey type for the user.

If it still doesn’t work

Open Event Viewer on the device and look at these two logs, under Applications and Services Logs, Microsoft, Windows:

• HelloForBusiness, Operational
• User Device Registration, Admin

They usually say plainly where provisioning failed. Beyond that, check that WHfB is still enabled for her through Intune or group policy, that the device can reach login.microsoftonline.com and enterpriseregistration.windows.net, that the TPM is healthy, that the clock is right, and that no Conditional Access policy is blocking the registration step.

Doing it properly next time

The lesson for me was that deleting the entry in Entra is only half of a reset. If a user’s Hello needs to be redone, there are two clean ways to do it. One is to have the user pick “I forgot my PIN” on the device, which resets both sides together. The other is, if you do delete the entry in Entra, to have the user remove the PIN on the device straight afterwards so the two sides stay in sync.

It’s worth writing this into your helpdesk process. The mismatch is easy to create and not obvious when you first see it, since the user just reports that their PIN stopped working and the error message points you somewhere else entirely.

Read More

Excluding Admins from a Dynamic "All Users" Group in Microsoft Entra ID (The Hard Way, So You Don't Have To)

 If you manage identity in any reasonably mature Entra ID tenant, you've probably wanted a dynamic group that captures "everyone" for baseline Conditional Access policies, licensing, onboarding automation while cleanly leaving out your admin accounts. It sounds like a two-minute rule. It isn't. Here's what actually works, and why the obvious approaches don't.

The problem

A dynamic "all users" group is simple enough on its own:

(user.objectId -ne null) and (user.userType -eq "Member") and (user.accountEnabled -eq true)

The trouble starts the moment you try to add "and exclude anyone assigned an admin role." Directory role assignments and PIM eligibility are not attributes the dynamic membership rule engine can evaluate. There's no user.assignedRoles property, and role membership isn't exposed to the rule builder at all.

Dead end #1: memberOf

Entra does have a preview rule operator that lets a dynamic group pull in members of another group:

user.memberof -any (group.objectId -in ['<admin-group-id>'])

This works but only in isolation. memberOf cannot be combined with any other condition in the same rule. You cannot write:

(user.accountEnabled -eq true) and not(user.memberof -any (group.objectId -in ['<id>']))

Entra's validator rejects it outright, often with an unhelpful error like Invalid object type '...' specified on property 'memberof'. It's also worth knowing this operator is in preview and being sunset Microsoft has flagged it for retirement, so building anything long-term on top of it is a bad bet regardless of the combination limitation.

There's a second wrinkle if your admin structure is a "group of groups": memberOf only reads direct members of whatever group ID you reference. Users sitting inside a nested group underneath it won't be picked up.

Dead end #2: Custom security attributes

The next instinct is Entra ID Governance's custom security attributes feature cloud-native, flexible, seems perfect. It isn't usable here either: custom security attributes are explicitly not supported as a property in dynamic group membership rules. They exist for access reviews and RBAC conditions, not for this.

What actually works: directory extension attributes

The feature that is supported in dynamic rules, and is cloud-writable regardless of on-prem sync status, is a Microsoft Entra directory extension attribute (also called a custom extension property). It's registered against an app registration, and once created it behaves like any other attribute:

(user.objectId -ne null) and (user.userType -eq "Member") and (user.accountEnabled -eq true) and (user.extension_<appid>_isPrivilegedUser -ne "Admin")

This combines freely with other conditions because it's a normal property, not a relationship like memberOf.

Registering it

There's no portal UI for this step, it's Graph or PowerShell only:

Run on this powershell - 

Connect-MgGraph -Scopes "Application.ReadWrite.All"

$app = New-MgApplication -DisplayName "Directory Extensions Owner App"
New-MgApplicationExtensionProperty -ApplicationId $app.Id -BodyParameter @{
    Name = "isPrivilegedUser"
    DataType = "String"
    TargetObjects = @("User")
}

One gotcha that cost real debugging time: an app registration alone isn't enough. Writing the extension property onto a user fails with The following extension properties are not available until the app also has a service principal in the tenant:

Run on this powershell - 

New-MgServicePrincipal -AppId $app.AppId

Once that exists, Update-MgUser -AdditionalProperties @{ "extension_<appid>_isPrivilegedUser" = "Admin" } works as expected.

Bridging the gap: a tagging script

Since the dynamic rule can't read group or role membership directly, something has to translate "is this person an admin" into "does this attribute say Admin," and keep it current. That's a scheduled script's job:

1. Recursively walk the admin group(s). If your admin structure nests groups inside groups, a flat membership read misses anyone underneath the nested layer so this needs to recurse until it hits actual users.
2. Account for PIM. If your admin groups are PIM-for-Groups enabled, Get-MgGroupMember only returns active members. Anyone with an eligible-but-not-activated assignment won't show up in that call at all, which quietly defeats the purpose of the exclusion. Eligible members need a separate query Get-MgIdentityGovernancePrivilegedAccessGroupEligibilitySchedule unioned in with the active set.
3. Tag, then untag. Every run tags newly-found admins and clears the tag from anyone no longer under any admin group, so people who lose admin status fall back into the "all users" group automatically on the next cycle rather than staying excluded indefinitely.

Script - https://github.com/pathumudana/Automation/blob/main/Tag-AdminExclusionAttribute

Running it unattended

This lands naturally in an Azure Automation runbook:

• Create the Automation Account

In the Azure portal, search "Automation Accounts" > Create. Pick your subscription/resource group, a name (e.g. entra-admin-exclusion-automation), and a region. Leave other defaults as-is for a simple runbook like this one.

• Enable a system-assigned managed identity

Inside the Automation Account, go to Account Settings > Identity. Turn System assigned to On and save. This gives the Automation Account its own identity in Entra ID that Connect-MgGraph -Identity will authenticate as  no stored credentials or secrets needed.

• Import the required Graph modules into the Automation Account

Go to Modules > Browse gallery (or Modules > Add a module for newer UI). Add these, one at a time, and wait for each to finish installing before adding the next: Microsoft.Graph.Authentication, Microsoft.Graph.Users, Microsoft.Graph.Groups, Microsoft.Graph.Identity.Governance, Microsoft.Graph.Applications. These match what your script imports/uses locally.

• Create the runbook and paste in the script

Go to Runbooks > Create a runbook. Choose PowerShell as the type and match the runtime version to what you tested locally (PowerShell 7.2 is the current recommended default). Paste in the full script content, with one change: swap the interactive Connect-MgGraph -Scopes "..." line for Connect-MgGraph -Identity, since Automation authenticates via the managed identity, not a browser prompt.

• Test the runbook before scheduling it

Use the Test pane (Edit view > Test pane) to run it once manually and confirm the same output you saw locally: groups walked, PIM-eligible counts, users tagged, and no permission or extension-property errors. This catches any permission-scope gaps from step 3 before it's running unattended.

• Create and link a schedule

Go to Schedules > Add a schedule > create new, set your recurrence (hourly or daily is typical for this kind of exclusion-tag refresh), then go back to the runbook's Schedules tab and link the schedule to it. This is what makes it run unattended going forward.

• Check job history periodically

Under Jobs, review recent runs' output and any warnings/errors (the Write-Warning lines in the script surface here). Since PIM eligibility and group membership can shift, keep an eye on this for the first few runs to confirm the numbers look stable before trusting it fully.

Create Dynamic Group

Create a new Security group and select Dynamic query

Dynamic Query -  

(user.objectId -ne null) and (user.userType -eq "Member") and (user.accountEnabled -eq true) and (user.extension_<App ID>_isPrivilegedUser -ne "Admin")

Note - you need to include this on the App ID we created on the above registration process without any Space or hyphen. 

Now you can see that New custom extension appear for dynamic rules and able select it. 

Read More

Custom Attributes in Entra ID: Choosing and Implementing the Right Approach

 

In on-premises Active Directory, we rely on Custom Extension attributes 1 to 15. Once those are used up, extending further means a schema extension. Several of these slots are already mapped into Entra ID and used to park attributes or tags, mainly to drive Entra identity lifecycle events and dynamic group membership rules.

For new requirements like this, Microsoft offers two ways to store custom values in Entra ID:

1. Entra ID Custom Security Attributes
2. Entra Directory Extension Attributes

Option 1: Custom Security Attributes

These live under Entra ID Governance, in Protection > Custom security attributes.

Limitation: they are explicitly not supported in dynamic group membership rules. Microsoft's own documentation confirms this: these attributes are not exposed to the dynamic group evaluation engine, so there is no way to reference them in a rule, regardless of syntax.

This rules them out for our use case.

Option 2: Directory Extension Attributes

Also called custom extension properties, these are registered against an app registration in the tenant.

Key characteristics:

• Fully supported in dynamic group rules, using the syntax user.extension_<appId>_<AttributeName> -eq "value"
• Cloud-native and writable via Graph regardless of on-prem sync status. Entra Connect has no ownership of them, so there is no sync-conflict risk (unlike extensionAttribute1 to 15)
• No Hybrid Runbook Worker required. A standard cloud Automation Account with a managed identity is sufficient

This is the right fit for our scenario.

How Directory Extension Attributes Work

Ownership through an app registration

Every extension attribute must be registered under an app registration, and that app becomes its owner. This is why a dedicated app is created for the purpose. It is not optional scaffolding; it is how the feature is designed to work. One app can own multiple extension attributes, and different apps can each own their own sets.

Naming convention

Once registered, the attribute receives a permanent, auto-generated name:

extension_<appId-without-dashes>_<attributeName>

Example: an attribute named isPrivilegedUser, registered under app c1c518d8-ee7d-48af-8d89-eb4da4c8f20e, becomes:

user.extension_c1c518d8ee7d48af8d89eb4da4c8f20e_isPrivilegedUser

This is the only name that exists for the attribute. It is used consistently across Graph API calls, dynamic group rules, and PowerShell. There is no separate friendly name exposed anywhere.

Two flavors of directory extension attributes

Cloud-native attributes (what we are building) Created directly via Graph or PowerShell against an app registration we control. Fully cloud-writable, with no dependency on sync.

Entra Connect synced attributes If the on-prem AD schema is extended and those custom attributes are synced up, Entra Connect auto-registers them as directory extensions as well, but under its own app called the Tenant Schema Extension App, not one we create. In this case, on-prem AD remains the source of truth, and the cloud side is read-only for those values. This is the same ownership constraint we already have with extensionAttribute1 to 15, just under a different app.

The Tenant Schema Extension App

When Microsoft Entra Connect is installed with the classic sync engine (not Cloud Sync) and custom on-prem AD attributes are selected for sync, the installer automatically registers a special application called the Tenant Schema Extension App. It is created once, during installation. We never create it ourselves, and it does not appear in the standard app list unless the filter is switched to "All Applications."

During the Entra Connect configuration wizard's custom settings step, it presents a list of AD schema attributes eligible for extension. Whichever ones are selected get registered as directory extension attributes under this single app, using the same naming pattern described above:

extension_<TenantSchemaExtensionAppId>_<attributeName>

The key point: every synced attribute shares the same app ID, the Tenant Schema Extension App's own ID. This is different from our setup, where a separate app is created specifically for one custom attribute. On-prem synced attributes all funnel through this one shared app.

Classic sync vs Cloud Sync

	Classic Entra Connect	Entra Connect Cloud Sync
Owning app	Tenant Schema Extension App	App with identifier URI api://<tenantId>/CloudSyncCustomExtensionsApp
App creation	Auto-created at install time	Not guaranteed to exist; created on demand

For Cloud Sync, Microsoft's documentation shows a check-and-create pattern:

$cloudSyncCustomExtApp = Get-MgApplication -Filter "identifierUris/any(uri:uri eq 'api://$tenantId/CloudSyncCustomExtensionsApp')"

If this returns empty, the app must be created. If the app exists but has no service principal, that also needs to be created:

POST https://graph.microsoft.com/v1.0/servicePrincipals
{ "appId": "<application appId>" }

Our Custom App vs the Tenant Schema Extension App

	Our custom app	Tenant Schema Extension App
Created by	Us, manually, via Graph/PowerShell	Entra Connect, automatically, at install time
Source of truth	Cloud (writable via Graph anytime)	On-prem AD (Entra Connect owns it, syncs one-way)
Used for	The isPrivilegedUser tagging we built	Any AD attribute exposed via Entra Connect's wizard

Setup: Creating a Cloud-Native Attribute

There is no portal UI for this step. It is Graph or PowerShell only.

Connect-MgGraph -Scopes "Application.ReadWrite.All"

$app = New-MgApplication -DisplayName "Directory Extensions Owner App"

New-MgApplicationExtensionProperty -ApplicationId $app.Id -BodyParameter @{
    Name = "isPrivilegedUser"
    DataType = "String"
    TargetObjects = @("User")
}

New-MgServicePrincipal -AppId $app.AppId

How to add another Extension for same app. 
To add another attribute, reuse the same app — don't run New-MgApplication again, or you'll end up with a second, duplicate "Directory Extensions Owner App" and a confusing mess of two apps owning different attributes.
Step 1 — Get the existing app's ID (don't recreate it):
powershell
$app = Get-MgApplication -Filter "displayName eq 'Directory Extensions Owner App'"
$app.Id
This should return 7ffcea56-09ff-4d28-982d-94de68690e36 — the same app you already have a service principal for.
Step 2 — Register the new extension property on that same app:
powershell
New-MgApplicationExtensionProperty -ApplicationId $app.Id -BodyParameter @{
    Name = "yourNewAttributeName"
    DataType = "String"
    TargetObjects = @("User")
}
Just swap yourNewAttributeName for whatever you want to call it.
That's it — no new service principal needed. Since this attribute is registered under the same app that already has a working service principal, it inherits that and should be immediately writable via Update-MgUser -AdditionalProperties, without repeating the New-MgServicePrincipal step.
Step 3 — Confirm it's there:
powershell
Get-MgApplicationExtensionProperty -ApplicationId $app.Id
You should now see both isPrivilegedUser and your new attribute listed side by side, both usable in dynamic group rules and via Graph once you copy the exact name field for each.

Q&A

• Why create an app registration for this at all?

Entra ID's user profile works like a fixed form with predefined fields: name, email, job title, and so on. A new field cannot simply be invented; Entra needs something to own that field before it will let one be created. An app registration is a container that can claim ownership of custom attributes. It is not being used as an app in any functional sense: no sign-in, no permissions consumed by it. It exists purely so the attribute has a home, which is why it is named descriptively, such as "Directory Extensions Owner App."

• How does the attribute get added to a user?

Once registered on the app, the attribute becomes a real, optional field on every user object in the tenant, effectively a new extension attribute slot that did not exist before. It stays empty until something writes a value into it. For each user identified as an admin, the script opens that user's record and writes a value into the field. It is a normal write operation, just to a field we created rather than a built-in one.

• Can this attribute be seen in the Entra ID portal?

Not on a user's profile page; there is no tab listing custom extension attributes and their values for a user. Values can only be viewed via Graph or PowerShell, for example:

Get-MgUser -Property "extension_..."

There is one place it does surface in the UI: when building a dynamic group rule in the Entra admin center, the rule editor has a "Get custom extension properties" button. Pointing it at the owning app and refreshing makes the attribute selectable in the rule builder dropdown. Outside of that workflow, it is not visible anywhere in the portal.

• Does this conflict with the on-prem extensionAttribute1 to 15?

No. Despite the similar naming, these are separate, unrelated storage locations.

extensionAttribute1 to 15 are legacy AD schema attributes. For synced users, Entra Connect owns them and pushes values one-way from on-prem AD to the cloud, which is exactly why they could not be used here: writing to them from the cloud side risks being overwritten by the next sync cycle.

Our new attribute, extension_<appid>_isPrivilegedUser, lives in a completely separate namespace tied to our app's ID. It is cloud-native, cloud-writable, and Entra Connect has no awareness of it or authority over it.

Read More