💠 Entra ID roles : Configure, harden, and clean-up (built-in & custom) following the principle of least privilege. >
Entra ID roles : Configure, harden, and clean-up (built-in & custom) following the principle of least privilege.
Overview
A practical, auditable workflow to configure, harden, and clean up Microsoft Entra ID roles that enforces least privilege: Discover current assignments, reduce built-in role use, create scoped custom roles when needed, require just-in-time (JIT) activation, apply approval and MFA guards, remove stale or unused assignments, and document everything for audit and operations.
🔸 1. Preparatory discovery and planning
Inventory roles and assignments
Export current role assignments for users, groups, and service principals so you can analyze scope and risk.
Identify accounts with highly privileged built-in roles (Global Admin, Privileged Role Administrator, Security Administrator).
Map responsibilities to minimal privileges
For each administrative task, determine the minimum built-in role or set of permissions required.
Prefer role assignment at the smallest scope possible (management group, subscription, resource group, or specific resource) rather than tenant-wide.
Define policy guardrails via PIM
Decide which roles must require JIT via Privileged Identity Management (PIM), which need multi-person approval, and which require MFA or conditional access context.
Plan remediation batches and waves
Group cleanup actions (e.g., remove Direct role assignments, replace user assignments with eligible group-based PIM assignments) in change windows with rollback steps and communications.
🔸 2. Hardening actions (technical controls)
Remove excessive built-in role assignments
Replace user direct assignments to highly privileged built-in roles with eligible group assignments or PIM eligible assignments.
Use Privileged Identity Management (PIM)
Make all privileged roles “eligible” rather than permanently assigned for humans.
Require activation with justification, approval (where appropriate), time limits, and MFA when activating.
Adopt group-based role assignments
Create security groups for role responsibilities, verify membership rules, and assign roles to groups rather than individuals.
Create custom roles when necessary
Author custom roles limited to exactly the needed actions and scope; avoid broad wildcard permissions.
Apply conditional access and authentication guards
Require MFA for activation and role use, enforce sign-in risk checks, and limit activation to allowed locations or devices where appropriate.
Enforce approval workflows and notifications
For high-impact roles require approval flow for activation and enable email alerts and audit logs for activation events.
Minimize service principal and managed identity privileges as well as application registration API permissions
Grant managed identities and applications only the permissions they need; prefer resource-scoped RBAC over tenant-wide Graph permissions.
Token lifetime and session controls
Configure session timeouts and reauthentication requirements for high-privilege portals and tasks.
Enable logging and alerting
Ensure Audit logs, Sign-in logs, and PIM activity logs are retained and forwarded to SIEM; create alerts for unusual activation patterns or multiple failed activation attempts.
🔸 3. Cleanup actions (remove stale or risky configurations)
Revoke direct role assignments to users
Replace with group or PIM eligible assignments; keep a change log of what was removed and why.
Remove inactive, orphaned, or stale role assignments
Identify assignments for accounts that are disabled, stale devices, or service principals with no recent activity and remove or revalidate them.
Consolidate overlapping roles
Remove redundant roles where a narrower role plus a scoped permission set suffice.
Retire unused custom roles
Audit custom role usage; delete or archive roles that no longer have assignments or purpose.
Cleanup overprivileged service principals
Remove unused app registrations, reduce their delegated/ application permissions, and rotate client secrets or replace with certificate auth.
Document and reassign responsibilities
Update your runbooks and owner records for every role change to preserve operational knowledge.
🔸 4. Operationalize least privilege (process and governance)
Role request and approval process
Implement a formal request flow for role elevation with time-boxed assignments and required justification. Create a justification text template.
Periodic reviews and certification
Schedule automated access reviews for privileged roles and group memberships; remove access where reviewers do not approve.
Automated enforcement
Use policies and automation (scripts or governance tools) to detect and remediate deviation from policy (e.g., direct permanent assignments to Global Admin).
Auditing and reporting
Produce quarterly reports of privileged assignments, PIM activations, and access reviews for compliance stakeholders.
Onboarding/offboarding enforcement
Integrate role assignment checks into HR-driven provisioning and deprovisioning workflows.
Training and least-privilege culture
Train admins on JIT and scope concepts; require use of break-glass procedures for emergency situations with logging.
🔸 5. Example actionable custom-role creation guidance
Design stage
Identify precise Graph or management actions required (for example: read and reset password for subset of users).
Build stage
Define role actions using the smallest operation verbs and resource types; avoid "*/read" at tenant scope.
Scope stage
Assign the role to a management group, subscription, or resource group instead of tenant when possible.
Test stage
Validate the role using a non-privileged test account with the intended scope and adjust until it provides only the needed rights.
Review and publish
Add documentation describing purpose, owners, and acceptable assignees; include audit tags or naming convention.
Click Microsoft Entra ID (or Azure Active Directory) in the left nav.
Click Roles and administrators.
To export assignments: open a role (e.g., Global Administrator) then click Role assignments, then click Download or Export (if available) to get a CSV.
🞛 6.2 Convert direct assignments to group-based assignments
Portal: Microsoft Entra ID > Roles and administrators.
Select the role to change.
Click Add assignment.
In Add assignment, choose Group as the assignee type, search and select the security group, set the Scope if prompted, then click Add.
After group assignment is active, remove direct user assignments: in the role’s Role assignments list select the user, click Remove.
🞛 6.3 Configure Privileged Identity Management (PIM) for roles
Portal: Microsoft Entra ID > Privileged Identity Management (PIM).
Click Microsoft Entra roles.
Click Manage > Roles or find a specific role and click it.
For a role, click Add assignments and choose Eligible (not Permanent), select the user or group, set Assignment settings: require MFA, require approval, set Max activation duration, then click Assign.
Under Role settings (within PIM), configure Require approval to activate, Activation email notifications, and Multi-factor authentication.
🞛 6.4 Create a custom role
Portal: Microsoft Entra ID > Roles and administrators.
Click + New custom role.
Provide Name and Description.
Under Permissions, click Add permissions, search the exact actions required, select them, and click Add.
Set Assignable scopes (tenant or specific scopes), then click Create.
Assign the custom role using Add assignment and prefer group eligibility or PIM.
🞛 6.5 Configure Conditional Access for role activation or portal sign-in
Portal: Microsoft Entra ID > Security > Conditional Access.
Click + New policy.
Name policy, under Users or workload identities pick the privileged role group or specific users.
Under Cloud apps or actions, select Microsoft Entra admin center or Sign-in risk as needed.
Under Grant, choose Require multi-factor authentication and any additional controls (e.g., require hybrid Azure AD joined device).
Enable policy and click Create.
🞛 6.6 Run an access review for role/group membership
Portal: Microsoft Entra ID > Identity Governance > Access reviews.
Click + New access review.
Choose Review type (Group or Role), select the role or group to review, set reviewers and recurrence, then Start.
Monitor review results and apply removals after completion.
🞛 6.7 Remove stale or unused service principals and APP permissions
Portal: Microsoft Entra ID > Enterprise applications or App registrations.
Filter by Last sign-in or check the application’s Activity.
For unused items: open the app, on the overview page click Delete to remove registration, or under Certificates & secrets rotate or remove secrets.
For application permissions: open API permissions, remove unnecessary permissions, and click Grant admin consent only when needed.
🞛 6.8 Audit and logging configuration
Portal: Microsoft Entra ID > Monitoring > Audit logs or Sign-ins.
Use Export Data Settings to route logs to Log Analytics, Event Hub, or Storage account for long-term retention and SIEM ingestion.
In PIM: Privileged Identity Management > Activity to review activation logs and export as needed.
🞛 Quick checklist to apply immediately
Change all human highly privileged accounts from Permanent to Eligible in PIM.
Assign roles to groups, not to individual users.
Create or refine custom roles for narrow tasks; test before production use.
Enable MFA and conditional access guards for role activations.
Schedule monthly PIM activity and quarterly access reviews.
Export and archive role assignment reports for audit trail.
🞛 Closing operational notes
Always test changes in a non-production or pilot tenant where possible.
Keep a documented rollback plan before making mass changes to role assignments.
Maintain an auditable change log and attach justification to every privileged role change in PIM.
Privileged Identity Management (PIM) provides just-in-time, time-bound, and approval-backed elevation for Microsoft Entra roles (Azure AD roles) and Azure resource roles (Azure roles) it reduces standing administrative privileges and captures activation audit trails for governance and compliance.
Preparatory discovery and planning
Inventory current privileged assignments: export Azure AD role assignments, Azure RBAC elevated assignments, and PIM activity to identify permanent vs eligible, owners, and last-use dates.
Define risk tiers and controls: classify roles by impact (Critical: Global Admin, Privileged Role Admin; High: Intune/Exchange admins; Medium/Low) and map required controls (MFA, approval, activation duration).
Choose pilot scope and stakeholders: pick a non-critical business unit and owners, define rollback procedures and communication plan for activation changes.
Ensure licensing and telemetry: confirm Microsoft Entra P2 or equivalent licenses and plan log collection to Log Analytics / SIEM for PIM and sign-in events.
🔸 7. Configure and harden PIM — Steps and actions
🞛 7.1 Enable and onboard PIM for Microsoft Entra roles (Azure AD roles) and Azure resource roles (Azure roles)
Turn on PIM, prepare baseline role settings, and verify eligible assignment capability for groups and users.
🞛 7.2 Convert permanent assignments to eligible assignments
Replace permanent role assignments with eligible assignments for people; where needed, assign roles to security groups and make the group eligible to reduce individual standing privilege.
🞛 7.3 Configure role settings per role
Require MFA to activate, set max activation duration (least time needed), require justification on activation, and enable multi-person approval for high-impact roles.
🞛 7.4 Require approval workflows where needed
For Critical roles, enforce approval chains with defined approvers; configure timeouts and escalation behavior for pending requests.
🞛 7.5 Limit activation scope and session controls
Enforce conditional access controls on activation (trusted locations, compliant devices), and configure Just-In-Time start/end times and session reauthentication when possible.
🞛 7.6 Harden service principals and eligible groups
Only allow managed identities or service principals as eligible if absolutely necessary; prefer narrowly scoped Azure RBAC for automation and avoid tenant-wide application roles.
🞛 7.7 Enable alerts, notifications, and email justification retention
Turn on activation notifications, require reason text, and retain activation justifications and audit logs for review and evidence.
🞛 7.8 Automate policy enforcement
Use automation (Logic Apps, runbooks, Graph API) to detect new permanent assignments and automatically raise remediation tickets or convert to eligible assignments.
🔸 8. Maintain PIM and regular cleanup actions
🞛 8.1 Scheduled access reviews
Run quarterly access reviews for privileged roles and eligible groups; remove or reassign access based on reviewer decisions and activity data.
🞛 8.2 Review and remove stale or unused eligibilities
Identify eligibilities with no activations in defined retention window (e.g., 90 days) and revoke or require re-request of access.
🞛 8.3 Audit activation patterns and anomalous behavior
Monitor PIM activation frequency, activation outside business hours, or activation from atypical locations; trigger investigations and temporary suspension where suspicious.
🞛 8.4 Clean up orphaned and legacy assignments
Remove permanent assignments created before PIM onboarding, delete unused custom roles, and remove inactive service principals or rotate credentials for in-use automation principals.
🞛 8.5 Revalidate approval chains and approvers
Ensure approvers are current and rotate approver assignment periodically to prevent approval bottlenecks or stale approvers.
🞛 8.6 Test and exercise emergency (break-glass) process
Maintain at least one audited emergency account with documented process; test recovery and ensure the account sits outside normal PIM approvals with monitoring in place.
🞛 8.7 Reporting and compliance evidence
Produce monthly PIM activation summaries, remediation logs, and quarterly certification evidence for auditors; keep logs forwarded to retained storage or SIEM.
🔸 9 Step-by-step Azure Portal actions (where to click)
🞛 9.1 Enable and access PIM
Azure portal > Microsoft Entra ID > Identity Governance > Privileged Identity Management > Click Get started if not enabled, then Microsoft Entra roles to manage Entra roles.
🞛 9.2 Convert a permanent assignment to eligible
Microsoft Entra ID > Privileged Identity Management > Microsoft Entra roles > Select role (e.g., Global Administrator) > Assignments tab > locate user with Assigned status > Click the assignment > Change to eligible or Remove then Add assignment and select Eligible when re-adding.
🞛 9.3 Assign a role to a group as eligible
PIM > Microsoft Entra roles > Select role > Add assignments > Select Group as the principal type > Search and select the security group > Under Assignment type choose Eligible > Configure start/end and settings > Assign.
🞛 9.4 Configure role settings (MFA, approval, duration)
PIM > Microsoft Entra roles > Select role > Role settings > Edit settings: set Require MFA to activate, set Require approval to activate, set Maximum activation duration, enable Email notifications > Save.
🞛 9.5 Require approval workflow
PIM > Microsoft Entra roles > Select role > Role settings > Require approval to activate > Add approvers (individuals or groups) and configure approval timeout and fallback approver > Save.
🞛 9.6 Configure conditional access for activation
Azure portal > Microsoft Entra ID > Security > Conditional Access > + New policy > Name policy > Users or workload identities pick the privileged group or users > Cloud apps or actions choose Microsoft Entra admin center or specific management app > Grant controls choose Require multi-factor authentication and/or Require device to be marked as compliant > Enable policy > Create.
🞛 9.7 Set alerts and notifications
PIM > Activity > Alerts and notifications (or PIM Settings) > Enable activation notifications and configure email recipients and retention settings > Save.
🞛 9.8 Run access reviews
Azure portal > Microsoft Entra ID > Identity Governance > Access reviews > + New access review > Choose Review type (Role) > Select PIM role or group > Define reviewers, recurrence and settings > Create and then Start when ready.
🞛 9.9 Export logs and route to SIEM
Azure portal > Microsoft Entra ID > Monitoring > Audit logs / Sign-ins > Click Export Data Settings > Route to Log Analytics or Event Hubs or Storage account and configure retention/diagnostic settings > Save.
🞛 9.10 Clean up stale assignments
PIM > Microsoft Entra roles > Assignments list > Filter by Last activation or Assigned since > Select stale entries > Remove or change to Eligible > Add note in change log/justification field when removing.
🞛 Quick prioritized checklist (immediate actions)
Convert all human Global Administrators from Permanent to Eligible in PIM and require MFA on activation.
Enforce approval for Critical roles and set short max activation durations (1–8 hours).
Schedule quarterly access reviews for all privileged roles and remove inactive eligibilities.
Forward PIM audit and activation logs to SIEM and enable alerts for abnormal activation patterns.
📕 Privileged Identity Management (PIM) can be linked to Conditional Access (CA) Policies via Authentication Contexts
💠 Deploy Baseline Entra hardening restrictions and controls : Follow Microsoft best practices and industry benchmarks.
Overview
Deploy a baseline Entra hardening posture that enforces least privilege, defends identity as the primary control plane, and maps to Microsoft guidance and industry benchmarks(CIS, Azure Well-Architected) to produce an auditable, repeatable configuration.
🔸 11. Preparatory discovery and planning
Inventory and classify: export role assignments, conditional access hits, app registrations, and sign-in logs to identify high-impact users, apps, and privileged principals; tag assets by sensitivity (Critical/High/Medium/Low) for targeted controls.
Verify licensing and telemetry: confirm Entra P1/P2 coverage required for Conditional Access, PIM, and Identity Protection; plan log routing to Log Analytics or SIEM for retention and alerting.
Define minimum viable baseline: document required controls, emergency break-glass process, owners, and rollout plan with pilot groups and rollback procedures.
🔸 12. Baseline controls and why each matters
Strong authentication everywhere: require MFA or passwordless for all interactive accounts; prioritize FIDO2 or Windows Hello for admins to mitigate credential theft.
Harden privileged roles via PIM: convert permanent assignments to eligible, require MFA and approval for critical roles, and set short activation durations to reduce standing privilege.
Targeted Conditional Access posture: protect admin portals and high-impact apps with app-specific policies that require compliant devices and MFA; block legacy auth tenant-wide except monitored emergency accounts.
Least-privilege RBAC and custom roles: replace broad built-in role usage with scoped assignments and narrowly authored custom roles assigned at the smallest scope necessary.
Restrict app and consent model: disable user app registrations and consent for high-risk permissions; require admin consent and review OAuth grants and API permissions regularly.
Secure non-human identities: use managed identities or service principals with resource-scoped RBAC, remove unused app registrations, rotate secrets, and prefer certificate auth for automation.
Logging, alerting, and retention: forward audit, sign-in, and PIM logs to SIEM; create alerts for abnormal activations, elevation spike, or unusual sign-in geographies.
Baseline tenant settings: enforce user restrictions (device registration, password reset policies), deny by default where possible, and apply well-architected hardening recommendations for resource configuration.
🔸 13. Implementation steps and actions (high level)
Pilot and enable telemetry: enable diagnostic export for Audit and Sign-ins to Log Analytics or Event Hub; validate ingestion and queries for key signals.
Enforce strong auth: configure Conditional Access policies to require MFA/passwordless for admins and privileged groups; test in Report-only, then enforce.
Onboard PIM and remediate assignments: enable PIM for Microsoft Entra roles (Azure AD roles) and Azure resources (Azure roles); convert permanent assignments to Eligible, require justification, approval, and MFA for Critical roles.
Replace direct assignments with groups and scoped custom roles: create security groups for role responsibilities and author custom roles with minimal actions and assign at narrow scopes.
Lock down app registrations and permissions: disable self-service app registration and restrict which users can consent to apps, review existing app permissions and remove excessive Graph or tenant-wide rights.
Secure automation principals: audit service principals, remove inactive ones, reduce application permissions to the minimum, rotate secrets or replace with certificates or managed identities.
Block legacy auth and enforce device posture: create a Conditional Access policy to block legacy auth and require device compliance for sensitive apps.
Run access reviews and periodic certification: schedule quarterly access reviews for high-impact roles and monthly checks for stale eligibilities and unused service principals.
Document and operationalize: maintain runbooks, naming standards, owner lists, and an approval flow for role elevation and policy changes for auditability.
🔸 14. Cleanup and continuous maintenance
Scheduled reviews: quarterly role and app access reviews; monthly scans for stale assignments and unused app registrations; remove or revalidate access where no recent activity exists.
Automation for drift detection: implement scripts or governance automation to detect permanent assignments to privileged roles, new user app registrations, or Conditional Access misconfigurations and create remediation tickets.
Incident readiness: keep a monitored break-glass account outside normal PIM flows, store recovery steps in runbooks, and test emergency procedures periodically.
Reporting and evidence: produce monthly PIM and Conditional Access summaries and retain logs for compliance windows required by your regulator or standard.
🔸 15. Step-by-step Azure Portal actions (where to click)
Open tenant overview and telemetry
Azure portal > Microsoft Entra ID > Monitoring > Audit logs / Sign-ins > Diagnostic settings >Add diagnostic setting > choose Log Analytics / Event Hub / Storage and select AuditLogs and SignInLogs > Save.
Enforce strong authentication with Conditional Access
Azure portal > Microsoft Entra ID > Security > Conditional Access >+ New policy > Name policy (e.g., Require MFA for Admins).
Assignments > Users or workload identities > Select users and groups > pick admin group(s).
Cloud apps or actions > Select apps > choose Microsoft Entra admin center or specific apps.
Conditions configure Locations or Device platforms if required.
Access controls > Grant > Require multi-factor authentication (and/or Require device to be marked as compliant) > Create; start in Report-only then switch Enable policy to On after validation.
Onboard and configure PIM
Azure portal > Microsoft Entra ID > Identity Governance > Privileged Identity Management >Get started (if needed) > Microsoft Entra roles.
PIM >Roles > select role (e.g., Global Administrator) > Assignments tab > locate permanent assignments and click the assignment > Remove or change to Eligible by adding a new assignment and selecting Eligible.
PIM > role >Role settings > edit to Require MFA to activate, set Maximum activation duration, enable Require approval to activate and configure approvers > Save.
Replace direct role assignments with groups and custom roles
Microsoft Entra ID > Roles and administrators > open role > Add assignment > choose Group > select security group > Add.
To create a custom role: Roles and administrators > + New custom role > fill Name/Description > Permissions > Add permissions (search and pick minimal actions) > set Assignable scopes > Create.
Test custom role with a non-privileged test account before wider assignment.
Restrict app registrations and review app permissions
Microsoft Entra ID > User settings >App registrations > set Users can register applications to No to block self-service app registrations.
Microsoft Entra ID > App registrations / Enterprise applications > open an app > API permissions > remove unnecessary permissions; Certificates & secrets rotate or remove secrets; delete stale apps via Delete.
Block legacy authentication
Microsoft Entra ID > Security > Conditional Access >+ New policy > Block legacy authentication > Assignments select All users (exclude break-glass) > Conditions > Client apps > configure Other clients (legacy) > Access controls > Block access > Create.
Schedule access reviews and automation
Microsoft Entra ID > Identity Governance > Access reviews >+ New access review > choose Review type (Role or Group) > select target > set reviewers and recurrence > Create.
Implement automation by scripting Graph API queries for assignments and integrating with Logic Apps/Runbooks to enforce remediation (use your existing automation pipelines).
💠 Clean-up stale IDs, orphaned accounts and objects within the Entra ID tenant
Summary: Steps to discover, clean up, and prevent stale or orphaned accounts and objects in your Entra tenant, plus exact Azure Portal click paths to identify and remediate them.
🔸 16. Clean-up Account Candidates discovery, validation, safe removal or remediation, prevention, and monitoring.
🞛 16.1. Discover and inventory stale or orphaned objects
Export role assignments, service principals, app registrations, and user lists to find mismatches and no-activity principals.
Why: role assignments can remain after principals are deleted leaving orphaned assignments.
Identify candidates:
Users: disabled accounts, accounts with no sign-ins in N days, accounts never used, guest accounts with no activity.
Service principals / app registrations: no recent sign-ins, expired or no valid credentials, unused delegated/application permissions.
Managed identities: identities created by deleted resources or automation that no longer exist.
Orphaned role assignments: “identity not found” or principals referenced that no longer exist in the directory.
Synced objects from on-prem AD that lost their source or were deleted on-prem (these may be immutable without fixing on-prem)..
🞛 16.2. Validate before removing (safety and audit)
Confirm owner and business justification for each candidate; create a remediation ticket for traceability.
Cross-check: last sign-in, last password change, last activity on associated resources, group memberships, and any dependent role assignments.
Special checks:
For synced users, verify on-prem status (Azure AD Connect) before deletion; if object was synced, deletion must be done on the source or handled with proper de-sync steps.
For service principals, check app usage and granted API permissions; review enterprise application sign-in logs.
Mark items for staged removal: Tag as “quarantine” or add to a temporary group and wait a validation window (7–30 days) before final delete.
🞛 16.3. Remediation actions (remove or remediate safely)
Users
Disable or block sign-in first (soft-remove) rather than immediate delete. Document reason and owner.
After validation window and approvals, delete from Entra ID (if not synced); if synced from on-prem, delete from source or use proper de-provisioning process.
Service principals / App registrations
Remove unused credentials (secrets/certs) and then rotate or disable the app. If unused for the retention window, delete the App Registration and corresponding Enterprise Application.
Remove excessive API permissions and revoke admin consent for unused apps.
Managed identities
If resource still exists, reassign proper RBAC; if resource is gone, remove identity and related role assignments.
Orphaned role assignments
Identify assignments where the principal is missing or shows “identity not found”; remove these role assignments to clean RBAC across subscriptions/resources.
Audit and retention
Export and store the change log (who, what, why), preserving audit evidence for compliance.
🞛 16.4. Prevent recurrence (guardrails and automation)
Disable user self-service app registration and restrict consent capabilities to reduce sprawl.
Implement lifecycle automation: integrate HR system and provisioning flows to disable and delete accounts on offboarding.
Automate detection:
Scheduled scripts using Microsoft Graph to find principals with no sign-ins, orphaned role assignments, expired secrets, and unattended app registrations; create tickets or take automated remediation (disable, notify owners).
Enforce RBAC hygiene:
Prefer group-based role assignments and PIM eligible assignments; avoid direct permanent assignments that persist when principals are removed.
Cleanup policy cadence:
Weekly scan for expired credentials; monthly scan for no-activity principals; quarterly full entitlement and app reviews.
🞛 16.5. Monitoring, reporting, and governance
Forward Audit and Sign-in logs to Log Analytics / SIEM and build queries to surface:
principals with no sign-ins in X days, orphaned role assignments, apps with no token issuance, and deleted-but-assigned role issues.
Schedule regular access reviews for privileged groups, app owners, and guest accounts; act on findings.
Maintain runbooks: quarantine steps, approval flows, rollback, and who to notify for service interruptions.
🔸 17. Step-by-step Azure Portal actions (where to click)
🞛 17.1 Find disabled, inactive, or stale users
Azure portal > Microsoft Entra ID > Users.
Use filters: Block sign-in = Yes or filter by User type (Guest) and export list.
To check activity: open Users > select user > Sign-ins (on the left) to view last interactive activity.
To block (soft-remove): user page > Profile > Block sign-in > set to Yes > Save.
To delete (after validation): user page > Delete > confirm.
🞛 17.2 Detect and review service principals and app registrations
Azure portal > Microsoft Entra ID > App registrations.
Use All applications view, sort or filter by Owner or Created date; open candidate app > Authentication and Certificates & secrets to inspect credentials.
Check usage: Microsoft Entra ID > Enterprise applications > select the app > Sign-in logs to see usage.
To disable or remove secret: app page > Certificates & secrets > Remove secret or add new cert; to delete app: app page > Delete.
If app has enterprise application mapping, open the Enterprise application and use Properties > set Enabled for users to sign in to No (quarantine) before deletion.
🞛 17.3 Identify and remove orphaned role assignments
Azure portal > Subscriptions (or specific resource group/resource) > open scope > Access control (IAM).
Click Role assignments > use Filter for Principal type = Service principal or Show assignments for = Deleted principals (if shown) or scan for entries with missing principal details.
Select orphaned assignment(s) and click Remove to delete the assignment.
For broad discovery across subscription(s): Azure portal > Azure Active Directory > Roles and administrators > check role assignment lists for principals that no longer resolve.
🞛 17.4 Handle synced/orphaned AD-Connect objects
Azure portal > Microsoft Entra ID > Users > open suspected synced user > check Source property (shows Azure AD or Windows Server AD).
If Source = Windows Server AD, do not delete in cloud; investigate on-premises AD or Azure AD Connect sync rules. Use on-prem AD to delete or fix anchor attributes, then allow sync to remove cloud object.
If a synced object is in an inconsistent state, consult Azure AD Connect health and the on-prem AD admins before making deletions.
🞛 17.5 Cleanse managed identities and their role assignments
Azure portal > Virtual machines or service resource where managed identity was created > open resource > Identity > check if system-assigned identity exists.
If resource deleted but identity persists as user-assigned: Azure portal > Managed Identities (or Resource groups > search) > open identity > Overview and Role assignments and remove assignments or delete identity.
🞛 17.6 Export reports and create quarantine/review groups
Many lists support Download or Export (CSV) from Users, App registrations, Enterprise applications, and Role assignments blades—use export to feed ticketing and review.
Create a security group named Orphaned-Quarantine or similar: Microsoft Entra ID > Groups > + New group > add accounts flagged for review. Use an access review for the group before final deletion.
🞛 17.7 Configure recurrent scans and alerts (portal steps to start)
Azure portal > Microsoft Entra ID > Monitoring > Audit logs / Sign-ins > click Export Data Settings to send logs to Log Analytics or Event Hub.
In Log Analytics workspace create saved queries to find no-activity principals and orphaned role assignments; configure alerts from queries to create work items automatically.
🞛 Quick prioritized checklist
Immediately block sign-in for accounts with no activity for 90+ days and place them in quarantine groups.
Identify and disable apps with no sign-ins in the last 90 days; remove secrets and delete after validation.
Run a cross-tenant scan for orphaned role assignments and remove them; keep an audit log of changes.
Ensure synced objects are fixed on the source before attempting cloud deletion to avoid inconsistent state issues.
Automate detection and ticket creation via scheduled Graph queries and Log Analytics alerts to keep the tenant clean long-term.
Summary: Identify and remediate high-risk APP permissions, ensure only authorized individuals can register APPs, restrict or disable user-consent as needed,harden guest user access, clean-up.
🔸 18 Application Registration Hardening and Cleanup — Steps and Actions
🞛 18.1. Inventory and risk classification
Export all app registrations and enterprise applications to get a single inventory with owners, creation date, last sign-in, and assigned permissions.
Classify apps by sensitivity and exposure: high (tenant-wide or Graph app permissions), medium (app with delegated high-privilege scopes), low (internal tools with limited scopes).
Identify high-risk attributes: application permissions to Graph or Exchange, broad delegated scopes, owners that are unknown, no recent sign-ins, secrets older than policy, or excessive admin consent grants.
🞛 18.2. Restrict who can register apps and control consent
Disable self-service app registration for general users; limit app registration to a small admin/developer group.
Restrict user consent so only approved users or admins can grant permissions; require admin consent for high-impact permissions.
Enforce an approval workflow for any new application registration and require documented owner and business justification.
🞛 18.3. Harden app permissions and consent
Remove or reduce application permissions that grant tenant-wide access; replace broad permissions with least-privilege alternatives or resource-scoped RBAC.
Revoke unused delegated consent and remove unnecessary API permissions; use least privilege scopes only.
Require admin consent for any app requesting high-privilege scopes and document the business need.
🞛 18.4. Secure credentials and authentication methods
Replace client secrets with certificates where possible and enforce short validity for secrets; require rotation policies.
Prefer managed identities for Azure resources and certificate-based auth for automation over long-lived client secrets.
Remove expired or weak credentials and immediately rotate compromised credentials.
🞛 18.5. Enforce app ownership and lifecycle controls
Ensure every app has at least one documented owner who receives alerts; assign ownership to groups where operational continuity is required.
Quarantine unknown or ownerless apps by disabling sign-in and adding them to a remediation queue.
Implement retention and deletion windows: disable first, monitor impact for a quarantine period (7–30 days), then delete if unused.
🞛 18.6. Harden guest user access and app exposure
Limit guest access to only required apps and groups; use access reviews for guest memberships and app access.
Configure Conditional Access and entitlement checks for guests to require compliant devices and MFA when accessing sensitive apps.
Remove guest accounts with no activity after defined windows and document exceptions.
🞛 18.7. Continuous monitoring and automation
Monitor sign-ins, token issuance, and consent changes; alert on new app registrations with privileged permissions or changes to app owners.
Automate detection of stale apps, apps with no sign-ins, expired credentials, and orphaned owners; create tickets or automate quarantine.
Schedule periodic access reviews and permission re-certification for high-risk apps.
🔸 19. Azure Portal Click Path to Harden and Clean Up App Registrations
🞛 19.1. Inventory app registrations and service principals
Azure portal > Microsoft Entra ID > App registrations > choose All applications to view registrations.
For service principal view: Microsoft Entra ID > Enterprise applications > All applications.
Use Download or Export on lists to CSV for offline analysis.
🞛 19.2. Review app usage and permissions
Enterprise applications > select application > Sign-in logs to check last activity.
Open the app > Permissions or API permissions to inspect delegated and application permissions.
Open Owners on the app page to see and edit owners.
🞛 19.3. Quarantine or disable suspect apps
Enterprise applications > select app > Properties > set Enabled for users to sign in to No > Save.
For app registrations: App registrations > select app > Authentication or Certificates & secrets > remove secrets or set to expire; then disable service principal sign-in under Enterprise applications if needed.
🞛 19.4. Remove or reduce permissions and revoke consent
Enterprise applications > select app > Permissions or User consent > Revoke user consent or Consent and permissions > remove admin consent where inappropriate.
🞛 19.5. Rotate and remove credentials
App registrations > select app > Certificates & secrets > New client secret to rotate, then Remove old secrets when new is active.
🞛 19.6. Restrict who can register apps and consent
Microsoft Entra ID > User settings > App registrations > set Users can register applications to No > Save.
Microsoft Entra ID > Enterprise applications > Consent and permissions > configure User consent settings to restrict which users can consent to apps; choose Do not allow user consent or Allow specific users/groups.
🞛 19.7. Assign and enforce app owners
App registrations > select app > Owners > Add owners to assign responsible individuals or groups.
Use Groups for ownership: Microsoft Entra ID > Groups > add group as owner on app to ensure continuity.
🞛 19.8. Clean up unused APP registrations and service principals
App registrations > filter or sort by Created date or use exported sign-in data to find no-activity apps.
For each candidate: App registrations > select app > Delete or Enterprise applications > set Enabled for users to sign in to No and after quarantine delete.
Document deletion actions in a ticket or change log for audit.
🞛 19.9. Harden guest access to apps
Microsoft Entra ID > Users > External collaboration settings > reduce guest permissions and set collaboration restrictions.
Microsoft Entra ID > Identity Governance > Access reviews > + New access review > choose Groups or applications > select guest-facing apps or groups and schedule review; remove guests who fail review.
🞛 19.10. Monitor and alert on app changes
Microsoft Entra ID > Monitoring > Audit logs > filter for Application created, Permission granted, or Consent events.
Click Export Data Settings on Audit logs to send to Log Analytics or Event Hubs for automated alerting and SIEM integration.
🞛 Immediate prioritized checklist
Disable user self-service app registration and restrict consent to admins.
Identify and quarantine ownerless apps and apps with no recent sign-ins.
Remove or reduce tenant-wide application permissions and revoke unnecessary admin consent.
Replace long-lived client secrets with certificates and rotate existing secrets.
Schedule access reviews for guest users and app owners to certify access.
💠 Deploy Entra Password Protection across in-scope tenants and corresponding on-prem components : ensure consistent password protections across AD and Entra.
🔸 20. Deploy Entra Password Protection — Steps and actions
🞛 20.1. Plan scope, prerequisites, and licensing
Confirm in-scope tenants and on-prem AD DS domains, ensure Entra P1/P2 or required license coverage for features you will use, and document owner and rollout schedule.
Validate network connectivity from proxy/agents to Microsoft endpoints and ensure you have accounts with sufficient privileges to register the proxy and install DC agents.
Identify pilot OUs and non-production DCs for phased rollout and testing.
20.2. Inventory and baseline
Export current password policies, self-service password reset settings, and user sign-in activity to determine baseline frequency of password resets and typical password change processes.
Identify accounts that are excluded from policy (service/special accounts) and plan how to treat them (allowlist, staged remediation, or password rotation).
Install the Microsoft Entra Password Protection DC agent on each domain controller or on representative DCs per Microsoft guidance to evaluate enforcement and performance.
Install and register the Password Protection proxy service on a highly available server (or pair) that the DC agents use to reach the cloud banned-password service and custom banned list.
Register the proxy(s) with the Entra tenant so DC agents can validate passwords against the global and custom banned lists.
20.4. Configure banned password lists and custom terms
Configure the tenant-level global banned password enforcement (built-in) and add organization-specific banned terms (company names, product names, local words) to the custom banned password list.
Apply custom banned password lists to the on-prem proxy so DC agents enforce the combined global + custom lists during password set/change operations.
20.5. Enable enforcement modes and pilot
Start in Audit/Monitor mode to observe rejections and false positives and review logs collected from DC agents and proxy.
After an evaluation window, move to Enforce mode for pilot OUs, enforce deny-on-match behavior, and monitor helpdesk impact and user friction.
20.6. Harden around exceptions and special accounts
Protect break-glass and service accounts by assessing if they truly require exemption; where necessary, implement alternate strong credential management (managed service accounts, certificate-based auth) rather than permanent exemptions.
For hybrid accounts, ensure writeback or password change flow is aligned so cloud and on-prem rules are consistent.
20.7. Operationalize and maintain
Forward DC agent and proxy operation logs and tenant password-protection events into Log Analytics / SIEM for alerting on unusual increases in banned password attempts or proxy errors.
Schedule periodic review of custom banned list terms, update based on telemetry, and rotate credentials for any accounts found attempting banned passwords.
Document rollback steps and incident playbooks (how to switch proxy off or return agents to audit mode).
Key rationale and risk notes
Entra Password Protection enforces a global banned-password list plus tenant custom banned terms for both cloud and on-prem password changes, preventing weak and predictable passwords from being set (use audit mode first to tune the custom list).
On-prem deployment uses a proxy service that the DC agents query, so ensure high availability and network reachability for reliable enforcement.
Use phased deployment (pilot OUs, audit mode → enforce) to minimize helpdesk impact and catch false positives before tenant-wide enforcement.
21. Azure Portal and on-prem click-paths (where to click)
21.1. Prepare tenant settings and custom banned list
Azure portal > Microsoft Entra ID > Security > Authentication methods > Password protection.
Under Password protection: review Password protection mode and Custom banned passwords; click Edit to upload or paste your custom list and Save (start in detection/audit first).
21.2. Download on-prem components and review requirements
Microsoft Learn article and docs (portal link from Password protection page) provide download links and prerequisites for the DC agent and proxy; follow link to download the installer and schema/privilege requirements.
21.3. Install and configure the Password Protection proxy
On a management server: run the proxy installer; after install open the Proxy configuration UI or use the provided PowerShell/CLI registration commands.
Portal: Microsoft Entra ID > Security > Authentication methods > Password protection > note the Tenant ID and registration instructions; use these values when registering the proxy with your tenant.
Verify the proxy shows healthy status in your server logs and in the proxy diagnostic output.
21.4. Install DC agent(s) on domain controllers
On each chosen domain controller: run the Microsoft Entra Password Protection DC agent installer.
After install, validate agent connectivity to the proxy and that the agent can fetch the banned list; check the agent’s event logs for successful operations and metric outputs.
21.5. Validate and switch modes (Audit → Enforce)
Azure portal > Microsoft Entra ID > Security > Authentication methods > Password protection > under Mode, set to Audit to collect telemetry first and Save.
Monitor agent and proxy logs for rejected attempts and false positives for your pilot OUs for the chosen window.
After validation, return to the portal and set Mode to Enforce for the tenant or for targeted scope and Save.
21.6. Monitor logs and route telemetry
Azure portal > Microsoft Entra ID > Monitoring > Audit logs / Sign-ins to view related events; click Export Data Settings or Diagnostic settings to send Password Protection and AD agent logs to Log Analytics or Event Hub for SIEM ingestion and alerting.
In Log Analytics run saved queries to surface blocked password attempts, proxy errors, or spikes in password change failures.
21.7. Manage exceptions and updates
Portal: Authentication methods > Password protection > Custom banned passwords > edit to add or remove terms based on observed false positives.
For an urgent rollback: disable the proxy registration on the server or set Mode back to Audit in the portal while troubleshooting.
Quick checklist to apply immediately
Enable Password Protection in Audit mode and add a small, conservative custom banned list for pilot tenants/ OUs.
Deploy and register at least one proxy and a subset of DC agents in the pilot OU; validate connectivity and logs.
Route logs to Log Analytics for alerting, tune custom banned list, then move to Enforce mode for broader rollout.
