Entra ID Tenant Default User Settings Restrict App Registration, Group Creation, and Admin Center Access

Entra ID Tenant Default User Settings Restrict App Registration Only After an Admin Changes Them

Entra ID tenant default user settings restrict app registration, group creation and admin center browsing — but only once an administrator changes them. Until someone does, the documented baseline for an ordinary member user is deliberately generous, and most tenants never revisit it.

Microsoft is explicit about what a plain member user can do. The default permissions reference states that "Member users can register applications, manage their own profile photo and mobile phone number, change their own password, and invite B2B guests. These users can also read all directory information (with a few exceptions)." The same page lists, under Groups, that member users can "Create security groups" and "Create Microsoft 365 groups"; under Applications, that they can "Register (create) new applications" and "Enumerate the list of all applications"; and under Roles and scopes, that they can "Read all administrative roles and memberships" (Default user permissions).

That is the uncomfortable part. The two preconditions that make OAuth consent phishing and directory reconnaissance work are not exotic attacker capabilities — they are tenant settings. Four switches close most of the gap, and none of them requires a licence upgrade.

How It Works: Four Switches, Three Different Objects

The Microsoft Entra admin center presents these as a tidy list under User settings and Group settings. Underneath, they are stored in three unrelated places, which is exactly why partial audits miss them.

The first two live on the tenant-wide authorizationPolicy singleton. Microsoft Graph documents allowedToCreateApps as corresponding to "the Users can register applications setting in the User settings menu", and allowedToCreateSecurityGroups as corresponding to "the Users can create security groups in Microsoft Entra admin centers, API or PowerShell setting" (defaultUserRolePermissions). The same object also carries allowedToCreateTenants, allowedToReadOtherUsers, allowedToReadBitlockerKeysForOwnedDevice and permissionGrantPoliciesAssigned.

Microsoft 365 group creation is somewhere else entirely: the EnableGroupCreation setting inside the Group.Unified template, whose "default setting is true" (Overview of group settings).

The fourth switch is the awkward one, and it is covered in its own section below.

The Attack Chain

Step 1 — Obtain one ordinary account

No role, no admin consent, no privilege escalation. Password spraying, adversary-in-the-middle token theft or device code phishing all end at the same place: a session as a standard member user. Everything below is what that session is entitled to do by default.

Step 2 — Map the directory from the inside

Member users can enumerate all users and contacts, all groups, all devices and all applications, and read all administrative roles and memberships. In practice that means an attacker with one ordinary session can list every Global Administrator in the tenant, identify which accounts are cloud-only, and pick targets — without touching a single admin surface.

Step 3 — Register an application and add a credential

With allowedToCreateApps left at its default, the account creates an app registration. Microsoft documents the consequence: "When a user registers an application, they're automatically added as an owner for the application." Owners can then update applications.credentials, among other properties.

That is the pivot. Adding an attacker-controlled secret or certificate to an application or service principal is catalogued by MITRE ATT&CK as T1098.001 — Account Manipulation: Additional Cloud Credentials, which notes that "adversaries may add credentials for Service Principals and Applications in addition to existing legitimate credentials in Azure / Entra ID. These credentials include both x509 keys and passwords." A credential on an application object is not tied to the compromised user's password, so resetting that password does not evict the attacker.

The app still needs permissions to be useful, and that is where the consent side of the tenant comes in: "By default, all users are allowed to consent to applications for permissions that don't require administrator consent" (Configure how users consent to applications). We cover that half of the problem in detail in OAuth consent phishing: how malicious apps bypass password theft and in Entra app registration dangerous Graph API permissions.

Step 4 — Create a group nobody is governing

Self-service group creation is not, by itself, a privilege escalation — a new group grants access to nothing. The damage is governance. A member user who creates a group is normally added as its owner automatically, with rights over groups.members and groups.owners — with one documented exception: for security groups created in the Azure portal, Microsoft notes that the "owner isn't assigned automatically at group creation." Microsoft further notes that "security groups created by self-service through the My Groups portal are available to join for all users, whether owner-approved or autoapproved" (Set up self-service group management).

The result is a directory with thousands of groups whose ownership means nothing, in which an attacker-owned group is indistinguishable from the rest — until an administrator grants that group access to an application, a site or a Conditional Access exclusion.

Why the Admin Center Toggle Is Friction, Not a Control

This is the switch most often reported as "hardened" and most often misunderstood. Microsoft's own documentation carries a caution above the table: the Restrict access to Microsoft Entra administration portal setting "limits access to a set of commonly visited admin center pages. It is not a security measure."

The detail is worth reading closely. Setting it to Yes "adds a layer of friction to casual browsing" by restricting non-administrators from loading frequently visited pages such as home, tenant overview and the users list. But Microsoft states that it "does not block programmatic access to Microsoft Entra data via PowerShell, Microsoft Graph API, or other tools like Visual Studio", that it "does not apply to users with an administrative role", and that "most pages in the admin center remain reachable if the user has a direct (deep) link."

Every step in the attack chain above runs through Microsoft Graph. None of it is affected by this toggle.

There is a second consequence for auditors: unlike the other three settings, this one has no property on the authorizationPolicy resource. Its documented property list — in v1.0 and in beta — contains defaultUserRolePermissions, guestUserRoleId, allowInvitesFrom, blockMsolPowerShell and friends, and nothing for admin portal access. If your tenant baseline claims to read this setting from Graph, verify what it is really reading.

🚨 Danger: Do not count the portal toggle as a compensating control for open app registration. Microsoft's guidance is to use a Conditional Access policy targeting the Windows Azure Service Management API to block non-admin access to Azure management endpoints.

Detection

Read the real state rather than the admin center rendering. Three of the four are retrievable with read-only scopes; the fourth — the admin center toggle — has no property to read, for the reason given above.

Connect-MgGraph -Scopes "Policy.Read.All","Directory.Read.All"

$policy = Invoke-MgGraphRequest -Method GET -Uri "https://graph.microsoft.com/v1.0/policies/authorizationPolicy"
$policy.defaultUserRolePermissions

$settings = Invoke-MgGraphRequest -Method GET -Uri "https://graph.microsoft.com/v1.0/groupSettings"
$settings.value

A tenant that has never been hardened returns something close to this, with an empty groupSettings collection:

{
  "allowedToCreateApps": true,
  "allowedToCreateSecurityGroups": true,
  "allowedToCreateTenants": true,
  "allowedToReadOtherUsers": true,
  "permissionGrantPoliciesAssigned": ["managePermissionGrantsForSelf.microsoft-user-default-legacy"]
}

Pair the configuration read with the audit log. These activity names are exact, and all of them are reachable in the Microsoft Entra audit log:

Source for every activity name: the Microsoft Entra audit log activity reference.

Two practical detections fall out of this. First, alert on Add application or Add service principal where the initiating principal holds no directory role — in a tenant with a controlled developer population, that should be a short list. Second, alert on Update authorization policy unconditionally; there are very few legitimate reasons for that policy to change, and an attacker who reaches Privileged Role Administrator will use it to re-open what you closed. If your tenant does not retain these logs long enough to investigate, fix that first — see Entra ID logging retention and diagnostic settings.

Remediation

1. Close the default user role permissions. Microsoft's own PowerShell example for disabling application creation is the base; the two additional properties are documented on the same object.

Import-Module Microsoft.Graph.Identity.SignIns
Connect-MgGraph -Scopes "Policy.ReadWrite.Authorization"

$params = @{
    defaultUserRolePermissions = @{
        allowedToCreateApps           = $false
        allowedToCreateSecurityGroups = $false
        allowedToCreateTenants        = $false
    }
}

Update-MgPolicyAuthorizationPolicy -BodyParameter $params

Setting allowedToCreateTenants to $false restricts tenant creation to the Tenant Creator role. This matters more than it looks: Microsoft notes that "by default, the user who creates a Microsoft Entra tenant is automatically assigned the Global Administrator role", and the event is logged as Create Company.

2. Close Microsoft 365 group creation and delegate it. This one needs a groupSettings object created from the Group.Unified template, because a default tenant has none. Read the template id from your own tenant first with GET https://graph.microsoft.com/v1.0/groupSettingTemplates rather than hardcoding it.

{
  "templateId": "62375ab9-6b52-47ed-826b-58e47e0e304b",
  "values": [
    { "name": "EnableGroupCreation", "value": "false" },
    { "name": "GroupCreationAllowedGroupId", "value": "<object-id-of-your-approved-creators-group>" }
  ]
}

GroupCreationAllowedGroupId is documented as the "identifier of the security group for which the members are allowed to create Microsoft 365 groups even when EnableGroupCreation is false" — that is your escape hatch, and it needs no P1 licence.

3. Tighten self-service group management. In the admin center under Groups → General settings, set Users can create security groups in Azure portals, API or PowerShell and Users can create Microsoft 365 groups in Azure portals, API or PowerShell to No. Microsoft is explicit about the escape hatch: "if you want to enable some, but not all, of your users to create groups, you can assign those users a role that can create groups, such as Groups Administrator." Know the limit of the neighbouring toggle before you rely on it — Restrict user ability to access groups features in the Access Panel "only restricts access of group information in My Groups. It doesn't restrict access to group information via other methods like Microsoft Graph API calls or the Microsoft Entra admin center."

4. Replace the admin center toggle with a real control. Set it to Yes if you want the friction, but implement the control Microsoft actually recommends: a Conditional Access policy targeting the Windows Azure Service Management API that blocks non-admin access to Azure management endpoints. Verify it in report-only mode first — see Conditional Access report-only mode and stale exclusions.

5. Verify, and mind the two gotchas. Re-run the detection block above and confirm every value moved. Two documented behaviours will otherwise make you think the change failed or succeeded when it did not:

• Group settings "can take up to 15 minutes to take effect."
• "These settings are for users and don't affect service principals. For example, if you had a service principal with permissions to create groups, even if you set these settings to No, the service principal can still create groups."

That second point is the reason this hardening pass belongs alongside an application inventory. Closing user-side creation while leaving over-permissioned service principals in place moves the problem rather than solving it — see Azure app registrations: over-privileged tenant apps and the broader Azure tenant hardening baseline.

How EtcSec Detects This

EtcSec splits this surface into four distinct findings on every Azure audit rather than folding it into one vague "tenant hardening" score. All four are reported at medium severity.

• AZ_APP_REGISTRATION_OPEN — App Registration Open to All Users: raised when authorizationPolicy → defaultUserRolePermissions.allowedToCreateApps comes back true. This one is read straight from Microsoft Graph.
• AZ_SELF_SERVICE_GROUPS_OPEN — Self-Service Group Creation Open: raised when the tenant carries no group-creation restriction — which is where a default tenant sits, since EnableGroupCreation stays true until a Group.Unified object exists.
• AZ_GROUP_SELF_SERVICE — Self-Service Group Management Unrestricted: the same unrestricted state scored from the groups side — ungoverned groups, and ownership that means nothing.
• AZ_ADMIN_PORTAL_ACCESS_OPEN — Admin Portal Access Not Restricted: raised unless the tenant is recorded as restricting admin center access to administrators. Reported as configuration hygiene, not as a security boundary, in line with Microsoft's own caution.

Keeping them separate matters because the fix differs per finding: one is an authorizationPolicy update, two are a groupSettings object you have to create first, and the fourth is a Conditional Access policy. For the full sequence, see how to audit Microsoft Entra ID security.