Technical Lab: Configure authentication by using Microsoft Entra ID
Questions
Question 1 — Multiple Choice
A network team needs to ensure that only devices that are registered and compliant with organizational policies can establish point-to-site (P2S) VPN connections in Azure. The VPN gateway is already configured with Microsoft Entra ID based authentication.
What additional configuration is needed to enforce the device compliance requirement in this scenario?
A) Configure a root certificate on the VPN gateway to validate the client device before user authentication.
B) Create a Microsoft Entra Conditional Access policy linked to the VPN gateway application that requires device compliance.
C) Enable Multi-Factor Authentication directly in the VPN gateway settings, in the Entra ID authentication section.
D) Manually register the MAC addresses of authorized devices in the Microsoft Entra ID security group associated with the gateway.
Question 2 — Technical Scenario
An engineer configures authentication with Microsoft Entra ID on a P2S VPN gateway and registers the application in the Microsoft Entra ID portal. When trying to connect, users receive the error below:
AADSTS650051: Using application 'Azure VPN' is not supported for your organization.
Contact your administrator.
The engineer verifies that the application was created correctly in the tenant and that users belong to the authorized group. What was likely omitted during configuration?
A) The application client secret was not generated, preventing the gateway from authenticating against the Entra ID endpoint.
B) Administrator consent for the Azure VPN application was not granted in the organization tenant.
C) The application redirect URL was not configured with the VPN gateway public IP address.
D) The application was registered as a Web platform instead of a mobile and desktop application platform, invalidating the P2S authentication flow.
Question 3 — True or False
When configuring a point-to-site VPN gateway with Microsoft Entra ID authentication, it is possible to simultaneously combine Entra ID authentication and certificate authentication in the same VPN client profile, allowing different users to use different methods in the same gateway configuration.
Question 4 — Technical Scenario
An organization uses a P2S VPN gateway configured with Microsoft Entra ID for authentication. The administrator needs to restrict VPN access to only a subset of users in the tenant, without modifying the gateway or reissuing client profiles.
What is the correct approach to implement this restriction?
A) Create a firewall rule in Azure that blocks authentication tokens from users outside the authorized group.
B) Modify the Azure VPN application manifest in Entra ID to include a list of allowed UPNs in the allowedMemberTypes field.
C) Enable the "User assignment required" option in the corresponding enterprise application in Entra ID and assign only authorized users or groups.
D) Configure a conditional access policy that blocks all users and then create an exception for the authorized group using a Named Location.
Question 5 — Multiple Choice
When registering the VPN gateway application in Microsoft Entra ID to support P2S authentication, the administrator must configure API permissions. Which permission is required for the VPN client to authenticate users correctly?
A) Application.ReadWrite.All delegated to Microsoft Graph, so the gateway can read and modify its own application registration at runtime.
B) user_impersonation on the Azure VPN API, a delegated permission that allows the client to act on behalf of the authenticated user.
C) Directory.Read.All delegated to Microsoft Graph, so the gateway can query user attributes during tunnel establishment.
D) openid and profile as delegated permissions to Microsoft Graph, sufficient to issue access tokens to the gateway endpoint.
Answer Key and Explanations
Answer Key — Question 1
Answer: B
Microsoft Entra Conditional Access is the correct mechanism to enforce requirements such as device compliance on applications registered in Entra ID, including the VPN gateway application. When the user attempts to authenticate, Conditional Access evaluates compliance before issuing the token.
Alternative A confuses certificate-based authentication (a different method) with compliance verification. Alternative C is incorrect because MFA is configured in Entra ID or via Conditional Access, not within gateway settings. Alternative D is operationally unfeasible and not supported by the platform: Entra ID does not use MAC addresses for access control.
Answer Key — Question 2
Answer: B
The error AADSTS650051 specifically indicates that the application does not have administrator consent granted in the tenant. For the Azure VPN application to work, the tenant administrator needs to perform explicit administrative consent, authorizing the necessary permissions for all users in the organization.
Alternative A is irrelevant because the P2S flow with Entra ID uses authorization code flow (PKCE), which does not depend on client secret. Alternative C is not a P2S configuration requirement; the gateway does not receive redirect callbacks. Alternative D describes a real impact in other scenarios, but is not the cause of this specific error with this code.
Answer Key — Question 3
Answer: True
The P2S VPN gateway in Azure supports multiple simultaneous authentication types in the same configuration. It is possible to enable both certificate authentication and Microsoft Entra ID authentication at the same time. In this case, the generated client profile allows each user to use the method available to them.
This behavior is non-obvious because many professionals assume exclusivity between methods. Understanding that methods coexist is important for gradual migration strategies and for hybrid environments where not all devices support Entra ID modern authentication flow.
Answer Key — Question 4
Answer: C
Enabling "User assignment required" in the enterprise application in Entra ID ensures that only users or groups explicitly assigned can obtain tokens for that application. This restricts access without requiring changes to the gateway or client profiles.
Alternative A does not exist as a token control mechanism in Azure. Alternative B uses a field that does not exist for this purpose in the application manifest. Alternative D would achieve the functional objective, but involves more complex Conditional Access logic, with greater misconfiguration risk, and is not the recommended approach for this specific case, in addition to modifying behavior for all tenant applications if not carefully scoped.
Answer Key — Question 5
Answer: B
The user_impersonation permission on the Azure VPN API is the specific and mandatory delegated permission for the VPN client to authenticate the user and obtain a valid access token for the gateway. It represents the delegated flow where the client acts on behalf of the user.
Alternative A grants excessive and unnecessary scope for this flow. Alternative C is also broader than necessary and not required by the P2S authentication process. Alternative D describes OpenID Connect authentication scopes (user identity), but without the user_impersonation permission, the issued token is not accepted by the VPN gateway as resource access authorization.