NPS logs are records of all RADIUS authentication and accounting events processed by the Network Policy Server role on Windows Server. They capture successful and failed network access attempts for VPN, Wi-Fi (802.1X), and wired 802.1X connections, recording the user identity, client device, authentication outcome, and the reason for any denial.
- What are NPS logs
- How to enable NPS logging
- Check NPS logs in Event Viewer
- NPS logging troubleshooting
- Monitoring with ADAudit Plus
- FAQ
What are NPS logs
Network Policy Server (NPS) is Microsoft's RADIUS server implementation for Windows Server. It handles authentication and authorization for network access requests, including VPN connections, wireless (802.1X) access points, and wired 802.1X switches.
NPS logs (sometimes called RADIUS accounting logs) record every authentication decision the server makes. Each entry captures the user identity, client IP address, Network Access Server (NAS) identifier, authentication result (accept or reject), reason code, timestamp, and the network policy that matched.
NPS supports three logging destinations:
- Local log file: A text-based log stored on disk in IAS or DTS-compliant format.
- SQL Server database: Centralized logging for high-volume environments running multiple NPS servers.
- Windows Security event log: NPS authentication events appear as Event IDs in the 6272 to 6279 range when the appropriate audit policy is enabled.
You can configure one or more of these destinations at the same time depending on your environment's scale and compliance requirements.
Where are NPS logs stored
File-based logs are stored, by default, in C:\Windows\System32\LogFiles. The log files use a date-based naming convention (e.g., IN2504.log for April 2025). You can change this path in the NPS console under Accounting > Configure Local File Logging > Log File tab.
NPS supports two file formats. The IAS (legacy) format stores one attribute per line. The DTS-compliant format stores records in a comma-separated layout that is easier to parse programmatically.
When auditing is enabled, NPS authentication events appear in Windows Logs > Security inside Event Viewer. Event IDs 6272 through 6279 cover all NPS authentication outcomes.
If you select SQL Server logging, NPS writes authentication records directly to a SQL database. This is the most scalable option for organizations running multiple NPS servers across different sites.
NPS rotates file-based logs on a configurable schedule (daily, weekly, monthly, or when the file reaches a specified size). One thing to watch out for: if disk space runs out before rotation, NPS stops logging new events without generating an alert. You can lose authentication records silently and not realize it until you go looking for them.
How to enable NPS logging
NPS does not log authentication events to the Security event log by default. You need to configure both RADIUS accounting and the Windows advanced audit policy.
Configure RADIUS accounting in the NPS console
- Open the NPS console by running nps.msc.
- In the left pane, expand Accounting.
- Click Configure Accounting.
- Select your logging destination: Log to a text file on the local computer, Log to a SQL Server database, or both.
- Click Next and configure the log file path (or SQL connection string).
- Under logging properties, select Accounting requests, Authentication requests, and Periodic accounting status.
- Click Next and then Finish.
Enable the advanced audit policy for NPS events
- Open the Group Policy Management Console (gpmc.msc).
- Create a new GPO or edit an existing one linked to the OU containing your NPS server.
- Navigate to Computer Configuration > Policies > Windows Settings > Security Settings > Advanced Audit Policy Configuration > Audit Policies > Logon/Logoff.
- Double-click Audit Network Policy Server and check both Success and Failure.
- Click OK.
- Link the GPO to the appropriate OU if it is not already linked.
- On the NPS server, open Command Prompt and run:
gpupdate /force
- Open Event Viewer and navigate to Windows Logs > Security. Filter for Event IDs 6272 and 6273 to confirm events are now being recorded.
Key NPS Event IDs
| Event ID | Description |
|---|---|
| 6272 | Network Policy Server granted access to a user |
| 6273 | Network Policy Server denied access to a user |
| 6274 | Network Policy Server discarded the request for a user |
| 6278 | Network Policy Server granted full access to a user because the host met the defined health policy |
| 6279 | Network Policy Server locked the user account due to repeated failed authentication attempts |
Understanding the Reason Code field in Event ID 6273
When NPS denies access, the Reason Code field in Event 6273 tells you why. These are the codes you will run into most often:
| Reason Code | Meaning |
|---|---|
| 16 | Authentication failed (bad password or invalid credentials) |
| 23 | Certificate presented by the client is not trusted or is invalid |
| 48 | Network policy conditions do not match the connection request |
| 65 | The NAS does not match the RADIUS client configuration in NPS |
| 66 | An unknown NAS device attempted to authenticate |
A high volume of Reason Code 16 from the same user account usually points to a brute-force attempt. Reason Code 23 popping up across multiple users at the same time often means something went wrong with a certificate deployment in your 802.1X environment, not that individual users are doing anything wrong.
How to check NPS logs in Event Viewer
- Open Event Viewer by running eventvwr.msc.
- In the left pane, navigate to Windows Logs > Security.
- In the right pane, click Filter Current Log.
- In the Event IDs field, enter 6272, 6273, 6274.
- Click OK to apply the filter.
- Double-click any event to view its properties. The fields you care about most:
- Account Name: The user who attempted authentication.
- Client IP Address: The device that sent the RADIUS request.
- NAS Port Type: Whether the connection came through VPN, wireless, or Ethernet.
- Authentication Type: EAP, PEAP, MS-CHAPv2, or whatever protocol was used.
- Reason Code: Why access was denied (for Event ID 6273).
Checking file-based logs
- Open File Explorer and navigate to C:\Windows\System32\LogFiles (or your configured log path).
- Open the most recent .log file in a text editor or import it into a log parser tool.
- For DTS-compliant format, each comma-separated record contains the NAS IP, user name, authentication result, and timestamp. For IAS format, each attribute is on a separate line within the record block, which makes it harder to scan quickly.
NPS logging troubleshooting
If NPS events are not appearing where you expect them, work through these common issues.
NPS not logging to Event Viewer
The most frequent cause is that the "Audit Network Policy Server" advanced audit policy is not enabled or has not been applied to the correct OU. To verify:
- On the NPS server, run gpresult /h report.html and open the HTML report.
- Search for "Network Policy Server" under Advanced Audit Policy Configuration.
- Confirm both Success and Failure are configured.
- If the policy shows "Not configured," check whether a basic audit policy is overriding the advanced policy. Navigate to Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Audit Policy and confirm all entries are set to "Not Defined." Basic audit policies override advanced audit policies when both are configured, and this trips up a lot of people.
NPS stopped logging events
- If the NPS log file directory runs out of disk space, logging stops silently. Check available space on the drive hosting C:\Windows\System32\LogFiles.
- Confirm the Network Policy Server service is running. Open services.msc and verify the service status.
- If you installed the Azure MFA NPS Extension, it can intercept authentication requests before NPS processes them. Check the registry key HKLM\SOFTWARE\Microsoft\AzureMfa for configuration issues. Remove or reconfigure the extension if it was installed but not properly set up.
Missing failed authentication events specifically
If you see Event ID 6272 (success) entries but no 6273 (failure) entries, confirm that "Failure" auditing is enabled in the advanced audit policy. Some administrators enable only Success auditing, which silently drops all denied-access events. This is an easy mistake to make, and you will not realize it until you actually need those failure logs.
Events appearing in the wrong log
NPS events should appear in Windows Logs > Security, not in Applications and Services Logs. If you are looking in the wrong location, you will not find them. NPS accounting log files (the text-based logs) record RADIUS accounting data and may not include the detailed failure reasons that only appear in the Security event log.
Security risks of unmonitored NPS logs
NPS controls network access for your VPN concentrators, wireless access points, and wired 802.1X switches. If you are not monitoring NPS logs, you have a blind spot across your entire network perimeter.
Rogue device connection attempts generate failed RADIUS authentication events from unknown MAC addresses or machine certificates. Without monitoring, these attempts go unnoticed, and a successful rogue connection gives the attacker a foothold inside your network.
Compliance is a practical concern too. HIPAA requires organizations to log and review authentication activity for systems handling protected health information. PCI-DSS Requirement 10 mandates logging all access to network resources and cardholder data environments.
ADAudit Plus captures all NPS authentication events in its RADIUS Logon Failures (NPS) report, giving you visibility into failed RADIUS attempts across all NPS servers from a single console without manual Event Viewer inspection on each server.
Limitations of native NPS logging tools
Native Windows tools leave gaps when you need to monitor NPS authentication at scale. Here is what you are actually working with.
You get no centralized view across multiple NPS servers. If you run two or more NPS servers for redundancy, you have to open Event Viewer on each server individually and cross-reference timestamps by hand to piece together a user's authentication history. This gets old fast.
Event Viewer has no real-time alerting. A password spray attack generating hundreds of Reason Code 16 events would sit unnoticed until someone manually opens the log.
File-based logs are not human-readable at any real volume. The IAS log format requires a parser, and even the DTS-compliant format needs to be imported into a spreadsheet or database before you can make sense of it.
There is no trend analysis or anomaly detection. Event Viewer shows individual events. It cannot tell you that a specific user's failure rate jumped 400% compared to last week, or that failures from a particular subnet started at 2:00 AM and stopped at 4:00 AM.
Log rotation and disk space are constant risks. If you set a maximum file size, older events get overwritten. If you forget to monitor disk space, logging stops entirely.
Either way, you lose evidence during an incident investigation.
There is no correlation with AD account lockouts. When NPS authentication failures trigger an account lockout, Event Viewer cannot automatically link the NPS failure events (6273) to the lockout event (Event ID 4740) on the domain controller. You have to manually search both logs and match timestamps yourself.
You also cannot configure Event Viewer to email a daily summary of NPS failures to your security team or compliance officer. There is no scheduled report delivery.
Monitoring NPS logs with ADAudit Plus
ADAudit Plus collects NPS authentication events from all your NPS servers and presents them in pre-built reports. No manual log parsing, no Event Viewer filtering on each server.
What ADAudit Plus monitors for NPS/RADIUS
ADAudit Plus provides two reports for NPS authentication activity:
- RADIUS Logon Failures (NPS): Located at Active Directory > Logon Audit > User Logon Reports > RADIUS Logon Failures(NPS). This report shows every failed NPS authentication attempt with columns for User, Client IP, NPS Server, Failure Reason, and Time.
- RADIUS Logon History (NPS): Located at Active Directory > Logon Audit > User Logon Reports > RADIUS Logon History (NPS). This report shows all NPS authentication events (both successes and failures) with columns for User, Client IP, NPS Server, Event Type, and Time.
Real-time alerts on NPS failures
You can configure alert profiles in ADAudit Plus to trigger when RADIUS authentication failures exceed a threshold you define. Alerts go out via email and SMS, so your team finds out about a potential brute-force attack or misconfiguration within seconds rather than hours.
UBA-driven anomaly detection
The user behavior analytics engine in ADAudit Plus establishes a baseline of normal NPS logon failure volume per user. When activity deviates from that baseline (say, a user who normally has zero RADIUS failures suddenly generates 50 in an hour), ADAudit Plus flags it as anomalous without requiring you to manually set static thresholds.
Correlation with AD account lockouts
The Account Lockout Analyzer in ADAudit Plus traces account lockouts back to their source. When NPS authentication failures trigger a lockout, the analyzer identifies the NPS server, client IP, and failure reason that caused it. This eliminates the manual cross-referencing that native tools require.
Scheduled reports and compliance
ADAudit Plus delivers NPS authentication reports on a daily, weekly, or monthly schedule directly to the inboxes of your security and compliance teams. Reports export in CSV, PDF, HTML, CSVDE, and XLSX formats.
Native NPS logging vs. ADAudit Plus
| Capability | Native NPS logging | ADAudit Plus |
|---|---|---|
| Centralized view across all NPS servers | No (must check each server) | Yes (single console) |
| Real-time alerts on failures | No | Yes (email and SMS) |
| Failure reason and client IP in reports | Yes (requires manual parsing) | Yes (pre-built report columns) |
| Anomaly detection for unusual failure volume | No | Yes (UBA-driven baselines) |
| Scheduled report delivery | No | Yes (daily, weekly, monthly) |
| Correlation with AD account lockouts | No (separate manual investigation) | Yes (Account Lockout Analyzer) |
| Log retention beyond Event Viewer limits | Only if SQL logging is configured | Yes (archival with compliance retention) |
A one-stop solution for all your IT auditing, compliance, and security needs
Try ADAudit Plus free for 30 days. No credit card required.
FAQ
By default, NPS file-based logs are stored in C:\Windows\System32\LogFiles. NPS can also log to a SQL Server database or to the Windows Security event log (Event IDs 6272 through 6279), depending on how you configure RADIUS accounting.
Open Event Viewer, navigate to Windows Logs > Security, and filter by Event IDs 6272 (access granted) and 6273 (access denied). For file-based logs, open the .log files in C:\Windows\System32\LogFiles with a text editor or import them into a log parser.
The most common cause is that the "Audit Network Policy Server" advanced audit policy is not enabled or not applied to the NPS server's OU. Verify the policy using gpresult /h report.html, confirm both Success and Failure auditing are configured, and run gpupdate /force to reapply.
NPS does not enforce a hard default file size limit. Log files grow until rotation occurs based on your configured schedule (daily, weekly, monthly) or until the disk fills up. You can set a maximum file size in the NPS console under Accounting > Local File Logging > Log File tab, but you have to configure this manually.
Experience
ADAudit Plus for free
With ADAudit Plus, you can:
- Get full visibility into logons
- Monitor employee attendance
- Detect attacks like Kerberoasting
- Generate logon audit trails
- And much more
