Entra Admin Center: What Search Still Reveals

I’ve already written about why the Restrict access to Microsoft Entra admin center toggle isn’t a security boundary on its own — that post covers what it blocks and why Conditional Access on the Windows Azure Service Management API is the control that actually matters. This one picks up where that left off: even after you’ve flipped the toggle and layered on a Conditional Access block, what can a standard, unprivileged user still find just by typing into the search bar?

Key takeaways

The admin center restriction and a Conditional Access block on Microsoft Admin Portals stop a standard user from loading the portal UI — they don’t stop the global search bar from returning group names and device records the user has no business seeing. Before you treat either control as sufficient, check what a real non-admin account can actually find through search in your own tenant. And know the difference between the two Conditional Access targets: Microsoft Admin Portals covers interactive sign-in to the admin center UI; Windows Azure Service Management API covers the broader management plane, including PowerShell, CLI, and ARM — they overlap but aren’t the same control, and which one you need depends on what you’re actually trying to stop.

Step 1: the restriction toggle, enabled

Same setting as my last post, same place — Entra ID > Users > User settings > Administration center > Restrict access to Microsoft Entra admin center, set to Yes.

Microsoft Entra admin center User settings page with Restrict access to Microsoft Entra admin center toggled to Yes — Entra ID → Users → User settings → Administration center. The restriction is on — that alone isn’t the boundary.

What the search bar still hands over

With the restriction active, sign in as a standard user and try the global search bar anyway. Searching a partial group name is enough to surface it — no admin role required, no portal page to navigate to, just the search box in the header.

Microsoft Entra admin center global search for 'R_adm' returning the R_AdminUsers group as a result — A standard user’s search for a partial group name still resolves to the real group — the access-denied banner on the page behind it doesn’t stop the search index.

Open that result and the membership list is right there — who’s in the group that, by its name, is almost certainly the tenant’s admin population.

Group membership is visible to the standard user who found it through search — this is exactly the kind of directory mapping an attacker with a phished standard account would want first.

Devices work the same way. A search for a device type returns a live match from the directory:

Microsoft Entra admin center global search for 'iphone' returning an iPhone 15 device result — Device records surface through search the same way group records do — the admin-center restriction doesn’t scope what the search index returns.

None of this requires bypassing the restriction toggle or the Conditional Access policy. Search isn’t a portal page the policy was built to gate — it’s a different surface, and it’s worth confirming that directly in your own tenant rather than assuming a UI restriction scopes everything a user can type into a search box.

Microsoft Admin Portals vs. Windows Azure Service Management API

If you’re building the Conditional Access side of this (see my prior post for the full policy walkthrough), it matters which cloud app you target. Microsoft Admin Portals governs interactive sign-in to the Microsoft 365, Entra, Intune, and Teams admin center UIs specifically. Windows Azure Service Management API is the broader management-plane target — it covers the Azure portal (which includes the Entra admin center), Azure PowerShell, the Azure CLI, and direct ARM API calls. They overlap, but a policy scoped only to Admin Portals won’t stop someone from reaching the same data through PowerShell or Graph, which is exactly the gap my last post walked through. If your goal is to close the API/PowerShell path, Admin Portals alone isn’t it — you need Windows Azure Service Management API in the policy too.

Validating the block

Whichever target you use, build it in report-only first, confirm the sign-in logs show what you expect, then switch it on and test with both a standard account and an authorized admin account. A real denial looks like this:

Microsoft sign-in page showing 'You don't have access to this' after a Conditional Access block — Successful sign-in, blocked resource access — the Conditional Access denial a correctly scoped policy produces.

Bottom line

Two controls, two different jobs, and neither one covers search. The admin center restriction and a Conditional Access block on Microsoft Admin Portals stop a standard user from loading admin pages directly — they don’t stop the directory search index from handing over group membership and device records to anyone who thinks to look. Test what your own tenant’s search bar actually returns to a standard account before deciding your admin surface is covered, and remember that Admin Portals and Windows Azure Service Management API are closing two different doors, not one.