1. Connecting without Prompt (SSO)
To enable users to sign in to an application using their Azure Active Directory (Azure AD) accounts, the application must first be registered in an Azure AD tenant. This app registration process creates an identity configuration for your application, allowing it to integrate with Azure AD.
For users on Azure AD-joined Windows devices, this registration enables a Single Sign-On (SSO) experience. When a user signs into their device, they receive a Primary Refresh Token (PRT). This token is then used to silently acquire access tokens for other Azure AD-registered applications, like App1, without requiring the user to re-enter their credentials.
An Azure AD managed identity is incorrect as it provides an identity for applications to authenticate to other Azure services, not for user sign-in. Azure AD Application Proxy is used for publishing on-premises applications, which is not the case here.
2. Access from Company-Owned Computers
A conditional access policy is the specific Azure AD tool designed to enforce access rules based on various conditions, or "signals." To meet the requirement of allowing access only from company-owned computers, an administrator would create a Conditional Access policy that applies to App1. This policy would be configured with a "grant control" that requires the user's device to be Hybrid Azure AD joined or marked as compliant. Since the company computers are Azure AD joined, this policy effectively restricts access to only those managed devices.
The other options are incorrect as they serve different purposes:
- Administrative units scope administrative permissions.
- Azure Application Gateway is a load balancer.
- Azure Blueprints and Azure Policy are used for governing Azure resources, not for controlling user access to applications based on device state.