Restrict Access To Azure Portal

Restrict Access To Azure Portal.

Settings this baseline controls

Setting	What it does
Policy name	Specifies a display name for the Conditional Access Policy Learn more
Enable policy	Specifies the state of the conditional Access Policy. Possible values are: enabled, disabled, enabledForReportingButNotEnforced. Required. Learn more
Included users	User IDs in scope of policy Learn more
Included roles	Role IDs in scope of policy Learn more
Included groups	Group IDs in scope of policy Learn more
Included guest types	Guest or external user types in scope of policy Learn more
Excluded users	User IDs excluded from scope of policy Learn more
Excluded roles	Role IDs excluded from scope of policy Learn more

5 more settings

Setting	What it does
Excluded groups	Group IDs excluded from scope of policy Learn more
Excluded guest types	Guest or external user types excluded from scope of policy Learn more
Grant controls	List of values of built-in controls required by the policy. Possible values: block, mfa, compliantDevice, domainJoinedDevice, approvedApplication, compliantApplication, passwordChange, unknownFutureValue Learn more
Included device platforms	Possible values are: android, iOS, windows, windowsPhone, macOS, linux, all, unknownFutureValue. Learn more
Included applications	The list of client IDs (appId) the policy applies to, unless explicitly excluded (in excludeApplications) All, Office365 - For the list of apps included in Office365. Learn more

Adding a baselineAdd, configure or remove a single baseline on a tenant, a user or a group, without deploying a whole scheme.→

Configure it

Add this baseline when access to the Azure portal should be closed to everyone except the roles or groups that manage Azure resources for the tenant.

1. Add the baseline to the tenant directly (see Adding a baseline), or carry it in a scheme you deploy to every tenant you manage (see Deploying a scheme).

2. Leave Included users empty. This baseline scopes who’s affected through Included roles or Included groups instead of a user list, so set one of those to whoever needs Azure access.

3. Use Excluded users, Excluded roles or Excluded groups for anyone who always needs to reach the Azure portal, such as break-glass accounts.

4. Leave Grant controls set to block. The baseline denies Azure portal access outright to anyone in scope rather than adding a second factor.

5. Save.

   Turn on Auto-remediation if you want Octiga to reapply the policy whenever it’s changed in Microsoft 365. End users outside the roles or groups you scoped it to see no change, since they were never meant to reach the Azure portal.

Caution

Anyone caught by the block loses access to the Azure portal, with no second-factor fallback. Check the roles and groups you’ve included and excluded before you switch Enable policy on.

Licence: Entra ID P1 or P2

This baseline needs Entra ID P1 or P2 on the tenant. Without it, Octiga excludes the baseline rather than reporting it as deviated — see Licence requirements.

Check it worked

After the next sync, this baseline shows Passing once a policy with state set to enabled, the block grant control, and the Azure portal as its target resource exists in Microsoft Entra. You can confirm it in the Microsoft Entra admin centre under Entra ID > Conditional Access > Policies. Anyone in scope who isn’t excluded is refused sign-in to the Azure portal; everyone else notices nothing.

Standards this addresses

CISM365 5.2.2.xv8 6.8

NISTPR.AC-4AC-3AC-6

ISO 27001A.8.2A.8.3

Doing this for every tenant?

Step through the deploy wizard to apply a scheme to a tenant, groups or users, and see what Managed and Direct do at deploy time.

Deploying a scheme→