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