Default Entra self-service settings can lead to directory sprawl, shadow IT, and easy post-compromise persistence.

Preface

Self-service options reduce admin overhead but often grant non-admins excessive privileges by default. A new Entra tenant is configured for collaboration and low friction: any user can register applications, create groups, read most of the directory and, depending on age of the tenant, consent to applications. Those defaults are reasonable for a small team. In an organization with a security program, they become an attack surface that nobody owns.

Problem

Compromised standard users can register malicious apps, create groups that weaken Conditional Access, or enumerate the directory through the admin portal. Self-service group creation also enables unmonitored guest sharing.

How the abuse works in practice

An attacker with one phished, non-privileged account typically looks for three things:

  • Persistence through app registrations. If users can register applications, the attacker creates one, adds a client secret, and now holds a credential that survives the user's password reset and does not depend on MFA. Combined with user consent, that app can be granted delegated access to the user's mail and files.
  • Directory reconnaissance. Default user permissions allow reading users, groups, devices and their relationships. Public tooling turns that into a map of administrators, service accounts and Conditional Access exclusion groups, which feeds targeted phishing.
  • Policy weakening through groups. Many tenants exclude a group from Conditional Access for a service account or a pilot. If that group is user-owned, or if membership can be managed by people outside the identity team, it becomes a way to switch off MFA for selected accounts.

Self-created Microsoft 365 groups and Teams add a data dimension: each one gets a SharePoint site and mailbox, and the owner may be able to add guests without review. Nothing in this list requires an exploit. It is the tenant working as configured.

Solution

Align with the CIS Microsoft 365 Foundations Benchmark (its Entra identity controls; section numbering has changed between benchmark versions):

  1. Restrict Entra portal access for non-admins. Note that this setting only hides the admin center UI; it does not block Microsoft Graph, PowerShell or the Azure CLI, so it reduces casual browsing rather than determined enumeration.
  2. Disable user app registrations. Delegate registration to the Application Developer role or to a request process owned by the identity team.
  3. Disable self-service group creation and move group management to an approval workflow, for both security groups and Microsoft 365 groups.

Design guidance for the rest of the user settings

  • User consent: allow consent only for verified publishers and low-impact permissions, or disable it entirely and enable the admin consent workflow so requests reach a reviewer.
  • Tenant creation: block non-admin users from creating new tenants, which otherwise sit outside your governance.
  • Microsoft 365 group creation: restrict creation to a designated security group through the Group.Unified directory setting, and apply a naming policy and expiration policy.
  • Groups used in Conditional Access: make exclusion and targeting groups role-assignable, so only Privileged Role Administrators and Global Administrators can change their membership, and consider restricted management administrative units for sensitive accounts.
  • Directory read access: setting AllowedToReadOtherUsers to false is possible but breaks people pickers, Teams and Outlook features. Test carefully; for most organizations, detection of mass enumeration is more practical than blocking it.
  • Device settings: limit who can join devices to Entra ID, cap devices per user, and require MFA to register or join.

Implementation steps

  1. Export the current authorization policy and directory settings so you have a baseline and a rollback reference.
  2. Identify who currently registers apps and creates groups (audit logs for the last 90 days) and give those people a supported path before you remove the defaults.
  3. Apply the authorization policy changes below, then the Microsoft 365 group creation restriction.
  4. Review existing app registrations and groups created by non-admins; assign owners from IT or remove what has no business purpose.
  5. Convert Conditional Access exclusion groups to role-assignable groups and document each exclusion.
  6. Communicate the request process to users and the help desk.

PowerShell: Harden Directory Access Defaults

These defaults live in the tenant authorization policy, not in directory synchronization settings:

Connect-MgGraph -Scopes "Policy.ReadWrite.Authorization"
$params = @{
    DefaultUserRolePermissions = @{
        AllowedToCreateApps           = $false
        AllowedToCreateSecurityGroups = $false
        AllowedToCreateTenants        = $false
    }
}
Update-MgPolicyAuthorizationPolicy -BodyParameter $params

# Verify
(Get-MgPolicyAuthorizationPolicy).DefaultUserRolePermissions | Format-List

The admin center access restriction is a portal setting under User settings and should be set there. Microsoft 365 group creation is controlled separately through the Group.Unified directory setting.

Monitoring and detection

Hardening settings drift, and exceptions accumulate. In Microsoft Sentinel, watch both for the activity the settings are meant to prevent and for changes to the settings themselves:

AuditLogs
| where TimeGenerated > ago(7d)
| where OperationName in ("Add application", "Add service principal credentials",
    "Consent to application", "Add group", "Update authorization policy")
| extend Actor = coalesce(tostring(InitiatedBy.user.userPrincipalName),
    tostring(InitiatedBy.app.displayName))
| extend Target = tostring(TargetResources[0].displayName)
| project TimeGenerated, OperationName, Actor, Target, Result
| order by TimeGenerated desc

Alert with higher severity on "Update authorization policy" and on membership changes to groups referenced by Conditional Access. For enumeration, look for unusual volumes of directory reads by a single user in MicrosoftGraphActivityLogs, where that table is enabled.

Common mistakes

  • Treating the portal restriction as an access control and assuming the directory is now hidden.
  • Disabling app registrations without reviewing the apps and secrets that already exist.
  • Blocking group creation with no request process, which pushes users to unmanaged alternatives.
  • Leaving Conditional Access exclusion groups owned by the requesters of the exclusion.
  • Applying the changes once and never checking for drift.

Where to start

Disable user app registrations and tenant creation today; both have low business impact. Next, restrict user consent and enable the admin consent workflow, then lock down group creation with a request process. Finally, protect the groups your Conditional Access policies depend on and deploy the audit query above so changes to these settings never go unnoticed.