Technical Lab: Configure RADIUS Authentication
Questions
Question 1 — Multiple Choice
A company needs to authenticate Point-to-Site (P2S) VPN users in Azure using corporate credentials managed in Microsoft Entra ID, with support for conditional access policies. The VPN gateway must delegate authentication to a centralized server.
Which combination of components correctly meets this requirement?
A) On-premises NPS server with NPS extension for Microsoft Entra ID, integrated to the VPN gateway via RADIUS
B) VPN Gateway configured directly with native Microsoft Entra ID authentication, without intermediaries
C) On-premises NPS server without extension, authenticating against local Active Directory via LDAP
D) Azure VPN Gateway with client certificate authentication, using a corporate root CA
Question 2 — Technical Scenario
An administrator configured the NPS extension for Microsoft Entra ID on a Windows Server 2019 server to support multi-factor authentication (MFA) on VPN connections. After installation, users report they can authenticate with password, but the second factor is never requested.
Event in NPS Log:
Source: IAS
Event ID: 6273
Failure Reason: 66 (Authentication failed due to user credentials mismatch)
What is the most likely cause of this behavior?
A) The NPS extension is not properly registered in the Microsoft Entra ID tenant
B) The NPS Extension for Azure MFA attribute has not been added to the user's security group
C) The user does not have a license that enables Microsoft Entra MFA assigned to their account
D) The NPS server is using PAP protocol instead of MS-CHAPv2, preventing the MFA challenge
Question 3 — True or False
The NPS extension for Microsoft Entra ID can be installed on any domain member server without additional connectivity requirements, as all communication with Microsoft Entra ID occurs synchronously within the RADIUS authentication process itself.
Question 4 — Technical Scenario
An organization uses an Azure VPN Gateway with RADIUS authentication delegated to an on-premises NPS server. The NPS server authenticates users against the local Active Directory. After a network migration, the VPN gateway moved to operate on a different subnet, and users can no longer authenticate.
Topology after migration:
- VPN Gateway: 10.10.2.4 (new GatewaySubnet)
- NPS Server: 10.10.0.5
- RADIUS shared secret: configured as "Corp@2024"
The administrator verifies that the NPS server is accessible via ping from other machines in the same VNet. What is the most likely cause of the failure?
A) The RADIUS shared secret was compromised during migration and needs to be regenerated
B) The RADIUS client on the NPS server is still configured with the old IP address of the VPN gateway
C) The GatewaySubnet firewall is blocking TCP port 1812 between the gateway and NPS
D) The Azure VPN Gateway does not support RADIUS authentication in recreated GatewaySubnets
Question 5 — Multiple Choice
When configuring an NPS server as a RADIUS proxy to forward requests to a group of remote RADIUS servers, which configuration element determines which requests are forwarded and to which remote server group?
A) The Connection Request Policy, which evaluates request attributes and defines the destination remote server group
B) The Network Policy, which defines access conditions and destination server based on user group
C) The Remote RADIUS Server Group, configured directly as a global destination for all received requests
D) The RADIUS Client, which has a forwarding attribute pointing to the remote server group
Answer Key and Explanations
Answer Key — Question 1
Answer: A
Azure VPN Gateway supports RADIUS authentication for P2S but does not have direct integration with Microsoft Entra ID to apply conditional access policies. The correct flow requires an on-premises NPS server that receives RADIUS requests from the gateway and forwards them to Microsoft Entra ID through the NPS extension. This extension is the component that injects the MFA challenge and allows Entra ID to validate credentials.
Alternative B describes native Microsoft Entra ID authentication for P2S, which uses certificates and OpenID Connect, not RADIUS. Alternative C authenticates locally without involving Entra ID. Alternative D uses PKI, not RADIUS, and does not apply Entra ID policies.
Answer Key — Question 2
Answer: A
When the NPS extension is not properly registered in the Microsoft Entra ID tenant, it cannot communicate with the MFA service. The resulting behavior is that first-factor authentication (password via local AD) succeeds, but the extension silently fails when trying to trigger MFA, allowing access without the second factor or generating inconsistent failures.
Alternative C is a common misconception: absence of license would generate a failure at the MFA stage, not a bypass. Alternative D is technically relevant in other contexts, but the PAP protocol, while not recommended, does not prevent MFA triggering by the extension. Alternative B does not represent a real concept in NPS extension configuration.
Answer Key — Question 3
Answer: False
The NPS extension for Microsoft Entra ID requires outbound connectivity to Microsoft's MFA service endpoints on the internet (specifically the login.microsoftonline.com endpoints and Entra ID authentication endpoints). The communication is not internal synchronous to the RADIUS process: the extension intercepts the RADIUS request after password validation and makes an asynchronous call to Microsoft Entra ID to complete the second factor before returning the result to NPS. Blocking this outbound connectivity completely interrupts the MFA flow, regardless of local configuration being correct.
Answer Key — Question 4
Answer: B
The NPS server maintains a list of RADIUS clients identified by IP address. The Azure VPN Gateway identifies itself as a RADIUS client using its IP when sending authentication requests. After migration, the gateway started using the new address 10.10.2.4, but the NPS server still expects requests from the old IP. Since NPS doesn't recognize the new IP as an authorized client, it silently drops the requests.
Alternative C is plausible, but RADIUS uses UDP, not TCP (ports 1812 for authentication and 1813 for accounting). Alternative D is incorrect: Azure VPN Gateway supports RADIUS regardless of the gateway subnet. Alternative A has no causal relationship with IP migration.
Answer Key — Question 5
Answer: A
In NPS operating as a RADIUS proxy, the Connection Request Policy is the mechanism that evaluates conditions of the received request (such as RADIUS client IP address, time, specific attributes) and determines forwarding to a configured Remote RADIUS Server Group. It's the separation between request routing policy and destination group that makes the proxy flexible.
Alternative B describes the Network Policy, which defines access permissions, not forwarding. Alternative C is wrong because the Remote RADIUS Server Group is just the destination; it doesn't contain selection logic. Alternative D doesn't exist as functionality: the RADIUS Client is the definition of who can send requests to NPS, not a forwarding router.