Skip to main content
emnode
Compliance High severity MCSB IM-1

Microsoft Defender for Cloud · Subscription / RBAC

Blocked accounts with owner permissions on Azure resources should be removed

Written and reviewed by Emnode · Last reviewed

What does the recommendation "Blocked accounts with owner permissions on Azure resources should be removed" check?

Flags any account that has been blocked from signing in to Microsoft Entra ID but still holds the Owner role on a subscription, management group, resource group or individual resource. The audit reconciles RBAC role assignments against Entra sign-in status, so it only surfaces principals where 'account enabled' is false yet Owner-level access remains. It is the AuditIfNotExists policy 'Blocked accounts with owner permissions on Azure resources should be removed', surfaced in Defender for Cloud. It does not cover blocked accounts holding lesser roles such as Contributor or Reader, those are tracked by separate recommendations, and it does not flag accounts that are merely inactive but still enabled, nor deleted accounts whose assignments have already been tidied up.

Why does "Blocked accounts with owner permissions on Azure resources should be removed" matter?

A blocked account is one your organisation has already decided should not be able to authenticate, usually a leaver, a compromised identity or a deprovisioned service account. Leaving Owner permissions attached to it means the highest privilege in the subscription is sitting on an identity nobody is watching: if the block is lifted by mistake, or the account is restored during an Entra recovery, full control over billing, resource deletion and further role grants comes back instantly. Owner can also assign roles to other principals, so re-enabling one stale account can quietly reopen access for many. It is the role attackers most want, so a forgotten blocked owner is a clear escalation path that bypasses your normal joiner-mover-leaver checks. In business terms it is a finding that fails an access review or an external audit outright, and it undermines the assurance that disabling an account in Entra actually removed that person's reach over production.

How do I fix "Blocked accounts with owner permissions on Azure resources should be removed"?

  1. List the offending assignments at the flagged scope: az role assignment list --scope <scope> --role Owner --query "[].{principal:principalName, id:principalId}" -o table, then confirm each principal is blocked in Entra ID before acting.
  2. Remove the Owner assignment from the blocked principal: az role assignment delete --assignee-object-id <objectId> --assignee-principal-type User --role Owner --scope <scope>. Use --assignee-object-id rather than --assignee so the deletion still works when the account can no longer be resolved through Microsoft Graph.
  3. Close the gap going forward by running access reviews in Microsoft Entra ID Governance over privileged role assignments, and grant standing Owner only through Privileged Identity Management so the role is time-bound and re-justified instead of left attached after an account is disabled.

Remediation script · bash

# Remove the highest-impact stale grants first: external/guest identities holding Owner.
SCOPE="/subscriptions/00000000-0000-0000-0000-000000000000"
az role assignment list --scope "$SCOPE" --all --include-inherited \
    --query "[?contains(principalName, '#EXT#') && roleDefinitionName=='Owner'].principalId" -o tsv |
while read -r oid; do
  az role assignment delete --assignee-object-id "$oid" --scope "$SCOPE"
  echo "$oid: external Owner assignment removed"
done

# Find blocked/deprecated (disabled) accounts that still hold a role on this scope.
for oid in $(az role assignment list --scope "$SCOPE" --all \
    --query "[?principalType=='User'].principalId" -o tsv | sort -u); do
  enabled=$(az ad user show --id "$oid" --query accountEnabled -o tsv 2>/dev/null)
  if [ "$enabled" = "false" ]; then
    echo "$oid is disabled in Entra but still holds a role - remove its assignment"
  fi
done

# Keep it shut: assign the built-in deprecated-owner policy by its exact display name
# (look the id up at runtime - never hardcode a policy GUID).
pid=$(az policy definition list \
  --query "[?displayName=='Deprecated accounts with owner permissions should be removed from your subscription'].name" -o tsv)
az policy assignment create \
  --name audit-deprecated-owners \
  --policy "$pid" \
  --scope "$SCOPE"

Full walkthrough (console steps, edge cases and verification) in the lesson Remove stale and external Azure identities.

Is "Blocked accounts with owner permissions on Azure resources should be removed" a false positive?

A break-glass account that you keep blocked by design and unblock only during an incident is a legitimate exception: it is meant to retain Owner while disabled. Document it, exclude it with a recommendation exemption in Defender for Cloud, and protect it with strong credentials and alerting rather than stripping its role.