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"?
- 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.
- 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.
- 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.
More Subscription / RBAC controls
- Azure overprovisioned identities should have only the necessary permissions
- Blocked accounts with read and write permissions on Azure resources should be removed
- Deprecated accounts with owner permissions should be removed from subscriptions
- External accounts with read permissions should be removed from subscriptions
- External accounts with write permissions should be removed from subscriptions
- Guest accounts with owner permissions on Azure resources should be removed
- Guest accounts with read permissions on Azure resources should be removed
- Guest accounts with write permissions on Azure resources should be removed
- Permissions of inactive identities in your Azure subscription should be revoked
- Privileged roles should not have permanent access at the subscription and resource group level
- Service Principals should not be assigned with administrative roles at the subscription and resource group level
- There should be more than one owner assigned to subscriptions