Troubleshooting Lab: Configure RADIUS Authentication
Diagnostic Scenarios
Scenario 1 — Root Cause
A network team reports that Point-to-Site VPN users started receiving authentication failures after a maintenance window performed the previous night. During maintenance, two activities were executed: VPN gateway certificate renewal and NPS server operating system update. Before maintenance, everything was working normally.
The administrator collects the following event on the NPS server:
Log: Security
Source: Microsoft Windows security auditing
Event ID: 6273
Network Policy Server denied access to a user.
Contact the Network Policy Server administrator for more information.
User:
Security ID: CORP\jsilva
Account Name: CORP\jsilva
Client Machine:
Fully Qualified Name: -
Called Station Identifier: -
Authentication Details:
Connection Request Policy Name: VPN RADIUS Policy
Network Policy Name: -
Authentication Type: MS-CHAPv2
EAP Type: -
Account Session Identifier: -
Reason Code: 16
Reason: Authentication failed due to a user credentials mismatch.
Either the user name provided does not map to an existing user account
or the password was incorrect.
The administrator confirms that:
- User
jsilvaexists in Active Directory and the password is correct - The NPS service is running
- The gateway certificate was successfully renewed and is valid
- The Network Policy associated with the Connection Request Policy is active and unchanged
- The NPS server was not restarted after the operating system update
What is the root cause of the authentication failure?
A) The VPN gateway certificate renewal invalidated the RADIUS shared secret configured on the NPS server
B) The NPS server operating system update corrupted the user entries in the local authentication cache
C) The NPS service is using an outdated authentication driver after the update, requiring a restart
D) MS-CHAPv2 authentication channels depend on a component loaded at service initialization that was not reloaded after the operating system update without restart
Scenario 2 — Action Decision
The security team identified that the RADIUS shared secret configured between the Azure VPN Gateway and NPS server is stored in plain text in an internal automation script that was accidentally committed to a corporate Git repository with broad access. The cause is confirmed and the repository has already been made private.
The production environment currently serves 340 active VPN users. The time is 2 PM on a Tuesday. There is no maintenance window scheduled for today. Changing the shared secret requires that the VPN gateway and NPS server be reconfigured in a coordinated manner, and all VPN authentication will be interrupted during the process, estimated at 12 minutes.
The security team classifies the incident as high severity due to credential exposure, but there is no evidence of malicious use so far.
What is the correct action to take at this time?
A) Wait for the next scheduled maintenance window to perform the shared secret change with controlled impact
B) Immediately start changing the shared secret, accepting the 12-minute interruption as necessary given the high severity classification
C) Revoke Git repository access for all users who are not part of the network team, without changing the shared secret yet
D) Notify the incident management team and wait for formal authorization before any technical action
Scenario 3 — Root Cause
A network administrator configures a new NPS server to support RADIUS authentication with MFA via NPS extension for Microsoft Entra ID. After completing the installation and extension registration, the administrator tests with a pilot user and observes the following behavior: the password is accepted normally, but the process hangs for approximately 30 seconds and then returns failure, without any MFA prompt being sent to the user's phone.
The administrator collects the following information:
Log: Application and Services Logs > Microsoft > AzureMfa > AuthZ > AuthZOperational
Event ID: 1001
Description: Request for user [email protected] failed.
Error: The request was blocked because it could not connect to the
Microsoft Entra ID MFA service endpoint.
Inner Exception: System.Net.WebException: Unable to connect to the remote server.
The administrator verifies:
- The NPS extension is successfully registered with the Microsoft Entra ID tenant
- The user has Microsoft Entra ID P1 license assigned
- The user's MFA method is configured as authenticator app
- The NPS server has no outbound route to the internet via corporate firewall
- The NPS server can resolve DNS for
login.microsoftonline.com
What is the root cause of the observed behavior?
A) Microsoft Entra ID P1 license is not sufficient to enable MFA via NPS extension; P2 license is required
B) Successful DNS resolution indicates the problem is in the TLS certificate used by the extension to authenticate with the MFA service
C) The absence of outbound connectivity prevents the NPS extension from reaching Microsoft Entra ID MFA service endpoints
D) The MFA method configured as authenticator app is incompatible with RADIUS flow and requires replacement with SMS
Scenario 4 — Diagnostic Sequence
A user reports that their P2S VPN connection failed after working correctly for weeks. No changes were made to the VPN gateway or NPS server configuration. The administrator decides to investigate the problem systematically.
The following investigation steps are available:
- Check NPS server event log (Event ID 6273) to identify the failure reason code
- Confirm that the user exists in Active Directory and that the account is not locked or expired
- Test UDP connectivity between the VPN gateway and NPS server on ports 1812 and 1813
- Validate that the RADIUS client corresponding to the gateway IP is registered in the NPS server
- Ask the user to attempt authentication again and collect the exact timestamp of the failure
What is the correct progressive diagnostic sequence?
A) 5 → 1 → 2 → 4 → 3
B) 1 → 2 → 3 → 4 → 5
C) 3 → 4 → 1 → 2 → 5
D) 2 → 5 → 1 → 3 → 4
Answer Key and Explanations
Answer Key — Scenario 1
Answer: D
The decisive clue in the statement is that the NPS server was not restarted after the operating system update. The NPS extension for Microsoft Entra ID and critical components of the MS-CHAPv2 authentication pipeline are loaded at service or system initialization. An OS update that replaces binaries on disk does not automatically reload modules already in memory. The result is an inconsistent state where the service continues running, but without the updated components necessary to process authentication correctly, producing Reason Code 16 (invalid credentials), which is a generic symptom of validation failure.
The gateway certificate renewal (alternative A) is irrelevant information included purposely. Gateway certificates have no relation to the RADIUS shared secret or user credential validation flow. The administrator who focuses on this information makes the error of correlating temporality with causality.
Alternative B describes non-existent behavior: NPS does not maintain local authentication cache of AD users. Alternative C is not technically accurate; the problem is not a driver, but process memory state.
The most dangerous distractor is A: an administrator who proceeds to reconfigure the shared secret loses time investigating something functional while the real problem remains unsolved.
Answer Key — Scenario 2
Answer: B
The statement explicitly declares the cause (shared secret exposed in repository with broad access) and classifies the incident as high severity. The determining variable is that exposure has already occurred and the repository remained accessible for an indeterminate time. Given a compromised credential of high severity, the incident response principle determines that remediation must be immediate, even with operational impact.
Alternative A ignores the severity classification and treats an active security incident as routine maintenance. Alternative C is insufficient: making the repository private does not invalidate the credential already exposed to those who had prior access. Alternative D represents a correct step in the incident management process, but does not replace immediate technical action when the cause and solution are already identified and the impact is acceptable (12 minutes).
The most dangerous distractor is D: waiting for formal authorization in a high severity incident with simple and short-duration remediation unnecessarily increases the exposure window.
Answer Key — Scenario 3
Answer: C
Event log 1001 with the message Unable to connect to the remote server points directly to network connectivity failure, not a logical configuration problem. The statement confirms that the NPS server has no outbound route to the internet, which prevents the NPS extension from reaching the Microsoft Entra ID endpoints necessary to complete the MFA challenge. Successful DNS resolution is irrelevant information included purposely: resolving a name does not imply TCP/TLS connectivity to the resolved address.
Alternative A is a common diagnostic error, but incorrect: P1 license is sufficient for MFA via NPS extension. The P2 requirement applies to features like Microsoft Entra Privileged Identity Management or risk-based conditional access.
Alternative B represents incorrect reasoning of associating DNS resolution with TLS certificate validity. Alternative D is technically false: the authenticator app is compatible with RADIUS flow via NPS extension.
The most dangerous distractor is A: an administrator who proceeds to change licenses loses time and resources without solving the real cause.
Answer Key — Scenario 4
Answer: A
The correct sequence is: 5 → 1 → 2 → 4 → 3.
Progressive diagnostic reasoning should start from the point of lowest cost and highest information amplitude:
- Step 5 establishes precise temporal context, allowing correlation of the failure with system events and efficient log filtering.
- Step 1 uses the NPS log to obtain the exact reason code, which guides all subsequent steps. Without the code, investigation is guided by assumption.
- Step 2 validates the authentication object (the user), which is the most likely element to have changed in an environment without infrastructure changes.
- Step 4 validates RADIUS client configuration, which may have been affected by IP changes or silent reconfigurations.
- Step 3 is the highest operational cost step (requires network testing tools) and is only necessary if previous steps do not reveal the cause.
Alternative B (1 → 2 → 3 → 4 → 5) reverses logic by executing network testing before validating the user, and collects the timestamp at the end, when it no longer serves to filter logs. Alternative C starts with the network layer without any context. Alternative D starts with user validation without first establishing temporal context or consulting logs.
Troubleshooting Tree: Configure RADIUS Authentication
Color legend:
| Color | Node type |
|---|---|
| Dark blue | Initial symptom (root) |
| Medium blue | Diagnostic question |
| Red | Identified cause |
| Green | Recommended action or resolution |
| Orange | Intermediate validation or verification |
To use this tree when facing a real problem, start with the root node identifying that there is a VPN authentication failure via RADIUS. The first question checks if the NPS server is logging Event ID 6273: if yes, the Reason Code from the event immediately directs to the correct branch (credentials, unknown client, or MFA failure), eliminating irrelevant hypotheses from the start. If NPS logs no events, the problem is in the transport layer, and the service and UDP connectivity validation branch is activated. At each level, answer only the current node's question before advancing: this prevents hasty actions and ensures that the identified cause is indeed the root cause.