Microsoft - SC-300: Microsoft Identity and Access Administrator

Sample Questions

Explanation:

The User Access Administrator role allows to create, update, delete, and assign roles to users. The User Access Administrator role has all permission in the Microsoft.Authorization permissions scope.

The Permissions Management controller gives you the choice to determine the level of access you grant to users in Permissions Management.

• Enabling the controller during onboarding grants Permissions Management admin access, or read and write access, so users can right-size permissions and remediate directly through Permissions Management (instead of going to the AWS, Azure, or GCP consoles).?

• Disabling the controller during onboarding, or never enabling it, grants a Permissions Management user read-only access to your environment(s).

Roles are assigned to the Cloud Infrastructure Entitlement Management identity on the subscription level.

References:

Azure built-in roles

User Access Administrator

Quickstart guide to Microsoft Entra Permissions Management

Enable or disable the controller in Azure

Explanation:

When a client application like Outlook connects to a service like Exchange Online, the API requests are authorized using OAuth 2.0 access tokens. By default, access tokens are valid for one hour, when they expire the client is redirected to Microsoft Entra to refresh them. That refresh period provides an opportunity to reevaluate policies for user access. For example: we might choose not to refresh the token because of a Conditional Access policy, or because the user is disabled in the directory.

Customers express concerns about the lag between when conditions change for a user, and when policy changes are enforced. Microsoft experimented with the "blunt object" approach of reduced token lifetimes but found they degrade user experiences and reliability without eliminating risks.

Timely response to policy violations or security issues really requires a "conversation" between the token issuer Microsoft Entra, and the relying party (enlightened app). This two-way conversation gives us two important capabilities. The relying party can see when properties change, like network location, and tell the token issuer. It also gives the token issuer a way to tell the relying party to stop respecting tokens for a given user because of account compromise, disablement, or other concerns. The mechanism for this conversation is continuous access evaluation (CAE), an industry standard based on Open ID Continuous Access Evaluation Profile (CAEP). The goal for critical event evaluation is for response to be near real time, but latency of up to 15 minutes might be observed because of event propagation time; however, IP locations policy enforcement is instant.

The initial implementation of continuous access evaluation focuses on Exchange, Teams, and SharePoint Online.

Reference: Continuous access evaluation

Explanation:

Microsoft Entra ID allows you to grant users just-in-time membership and ownership of groups through Privileged Identity Management (PIM) for Groups. Groups can be used to control access to a variety of scenarios, including Microsoft Entra roles, Azure roles, Azure SQL, Azure Key Vault, Intune, other application roles, and third-party applications.

Any Microsoft Entra security group and any Microsoft 365 group (except dynamic groups and groups synchronized from on-premises environment) can be enabled in PIM for Groups. The group doesn't have to be role-assignable group to be enabled in PIM for Groups.

Reference: Privileged Identity Management (PIM) for Groups

• App1 will be deployed as a registered app in Sub1.
• App1 will access storage1 by using Microsoft Entra authentication.
• App2 will access storage1 by using a single Microsoft Entra identity.
• App2 be hosted on two new virtual machines named VM1 and VM2.

Explanation:

Managed identities provide an automatically managed identity in Microsoft Entra ID for applications to use when connecting to resources that support Microsoft Entra authentication. Applications can use managed identities to obtain Microsoft Entra tokens without having to manage any credentials.

There are two types of managed identities:

• System-assigned. Some Azure resources, such as virtual machines allow you to enable a managed identity directly on the resource. When you enable a system-assigned managed identity:

  • A service principal of a special type is created in Microsoft Entra ID for the identity. The service principal is tied to the lifecycle of that Azure resource. When the Azure resource is deleted, Azure automatically deletes the service principal for you.
  • By design, only that Azure resource can use this identity to request tokens from Microsoft Entra ID.
  • You authorize the managed identity to have access to one or more services.
  • The name of the system-assigned service principal is always the same as the name of the Azure resource it is created for. For a deployment slot, the name of its system-assigned identity is <app-name>/slots/<slot-name>.

• User-assigned. You may also create a managed identity as a standalone Azure resource. You can create a user-assigned managed identity and assign it to one or more Azure Resources. When you enable a user-assigned managed identity:

  • A service principal of a special type is created in Microsoft Entra ID for the identity. The service principal is managed separately from the resources that use it.
  • User-assigned identities can be used by multiple resources.
  • You authorize the managed identity to have access to one or more services.

To minimize administrative effort we should assign a system-assigned managed identity to App1.

App2 will run in more than one instance and thus requires a user-assigned managed identity.

Reference: What are managed identities for Azure resources?

• Disable user consent to apps.
• Configure admin consent workflow for apps.

Explanation:

Before an application can access your organization's data, a user must grant the application permissions to do so. Different permissions allow different levels of access. By default, all users are allowed to consent to applications for permissions that don't require administrator consent. For example, by default, a user can consent to allow an app to access their mailbox but can't consent to allow an app unfettered access to read and write to all files in your organization.

Both, user consent to apps and admin consent workflow for apps, are configured using the Enterprise applications settings from the Microsoft Entra admin center. The Microsoft 365 admin center allows to access the Microsoft Entra admin center but does not provide a built-in option to disable user consent to apps.

References:

Configure how users consent to applications

Configure the admin consent workflow