NPS记账与审计实战：RADIUS Accounting日志配置与排错指南

NPS 全称 Network Policy Server，是 Windows Server 自带的 RADIUS 服务器和 RADIUS 代理组件。很多搞网络运维的朋友第一次接触 NPS，是为了给园区无线网络做 802.1X 认证，配置完网络策略、RADIUS 客户端，能连上网就觉得“大功告成”。但真正上线之后才会发现，最容易被忽略的往往是最要命的：领导问“这个月到底谁在用网、用了多久、传了多少流量”，安全工程师问“昨晚那批认证失败是什么时间、来自哪个 NAS、失败原因是什么”，这时候如果没有 NPS 记账和审计，你对着控制台只能干瞪眼。

这篇文章我就从实际运维视角，把 NPS 的记账（RADIUS Accounting）和审计（安全事件与日志）掰开揉碎讲一遍，包括底层原理、存储选型、完整配置、日志分析，以及我踩过的一些坑。适合正在做无线准入、交换机拨号认证、园区网审计的运维和网管同学参考，哪怕你之前完全没碰过 NPS，照着这篇文章也能把记账审计这块补起来。

1. NPS 记账和审计，到底在解决什么问题

1.1 RADIUS 三 A 框架里的“记账”被低估了

RADIUS 协议全称 Remote Authentication Dial-In User Service，典型工作模式是：NAS（网络访问服务器，比如无线控制器、交换机）作为 RADIUS 客户端，把用户认证请求转给 RADIUS 服务器，由服务器完成认证和授权后再返回结果。整个过程通常叫 AAA，很多人只知道 Authentication（认证）和 Authorization（授权），第三个 A 是 Accounting（记账），也是最容易被忽略的。

NPS 记账本质上就是 RADIUS 协议里的 Accounting 流程。用户认证通过后，NAS 会向 NPS 发送 Accounting-Request 报文，NPS 收到后回一个 Accounting-Response。一次完整的接入会话至少包含 Start 和 Stop 两条记录，中间还可以有若干条 Interim-Update 记录，用于汇报用户在线期间的流量、时长等动态数据。

这些记账记录的价值远不止“算钱”。在企业内部网，它回答了三个核心问题：谁？什么时候？做了什么？谁在某个时段通过哪个接入设备上线，会话持续了多久，上传下载了多少字节，最终是怎么断开的。这些数据既可以用来做资源用量统计，也可以作为安全事件调查的基础事实。

1.2 NPS 能记录哪些关键字段

NPS 日志里常见的 RADIUS 属性大概有这么几类，实际记录哪些取决于你在配置日志时勾选的选项和 NAS 发来的属性。

Acct-Status-Type 的值是数字编码，常见的有 Start=1、Interim-Update=3、Stop=2。看日志时如果直接看到数字，不要慌，这不是脏数据，就是 RADIUS 标准枚举值。

1.3 记账和审计，看起来像，实际是两码事

很多朋友容易把 NPS 记账和 Windows 审计混在一起，其实它们解决的问题不同。

记账是业务数据，关心的是“用量”，比如流量、时长、会话状态，主要用来做统计和计费。审计是安全数据，关心的是“谁尝试访问了网络、结果如何”，比如成功认证、拒绝认证、配置被修改、服务启停等。NPS 的审计主要通过 Windows 安全事件日志来完成，事件 ID 6272 表示授权成功，6273 表示拒绝访问。特别是一次大规模认证失败，如果能从安全日志里迅速定位到时间窗口和用户名，排查效率会高很多。

所以一份完整的 NPS 运维方案，应该是“本地文件或 SQL 数据库里的记账日志 + 安全事件日志里的审计事件”两者并存。只开记账不开审计，出安全事件时缺少追责证据；只开审计不开记账，做不了流量和时长统计。后面配置部分我会把两个都讲清楚。

2. 动手前先想清楚：日志往哪存、记什么

2.1 三种存储方式选型对比

NPS 的日志可以写到本地文件、SQL Server 数据库，也可以走 Windows 事件日志。三者在实际项目中的定位差别很大。

本地文件是默认也是最常用的方案。默认路径在C:\Windows\System32\LogFiles，文件以IN开头加日期，例如IN20240601.log。如果你有独立数据盘，强烈建议把日志路径改走。系统盘一旦被日志写满，NPS 服务和整台服务器都会遭殃，这个我在实战里见过不止一次。

SQL Server 方案适合需要集中查询的环境。多台 NPS 分散在几个区域，每台都写本地文件，报表人员就要一台台去拉文件，非常痛苦。接到统一数据库后，一条 SQL 就能统计全网接入情况。但不是所有环境都有条件维护 SQL Server，如果只是几十个 AP 的小园区，老老实实本地文件就够用了。

2.2 记录内容按需勾选，不要无脑全开

在 NPS 的日志配置里，有两个容易让人迷惑的选项：身份验证请求和记账请求。身份验证请求对应 Access-Request、Access-Accept、Access-Reject，记账请求对应 Accounting Start/Interim/Stop。默认情况下两个都勾选，意味着每条认证尝试和每次会话上下线都会被记录。

如果环境压力非常大，比如上千个在线终端，每台终端每隔几分钟发一次 Interim-Update，日志量会爆炸式增长。这时候可以只保留记账请求和失败的身份验证请求，成功认证记录可以不写。但我不建议一上来就为了省空间裁掉成功记录，先把基线跑出来，确认日志量可接受后再调整。

2.3 动手前的三个准备工作别偷懒

第一，确保 NPS 和所有 NAS 时间一致。RADIUS 记账里时间戳是核心，如果 NAS 和 NPS 的时间差超过几秒，日志对不上，排查会话时你会疯掉。最好统一配 NTP，不要依赖设备手动设置的本地时间。

第二，确认 NPS 服务账户对日志目录有读写权限。NPS 服务运行在 Network Service 账户下，如果你手动改了日志路径，一定要给这个账户赋写权限，否则日志文件根本创建不出来。

第三，设计好日志保留周期。按天生成是默认推荐，每天一个文件，再配合一个计划任务做归档压缩，比让一个文件无限膨胀好一万倍。Windows 自带的日志文件大小上限也要预先规划，否则超过上限后 NPS 可能会停止写入，而不是自动滚动。

3. NPS 记账与审计配置完整步骤

3.1 安装角色并打通认证链路

想在 Windows Server 上用 NPS，首先要安装“网络策略和访问服务”角色。图形化方式是在服务器管理器里选择“添加角色和功能”，勾选 Network Policy and Access Services，再勾选 Network Policy Server。命令行更快：

Install-WindowsFeature NPAS -IncludeManagementTools

装完之后打开 NPS 控制台，先把 RADIUS 客户端配好。这里的 RADIUS 客户端不是终端用户，而是你的无线控制器或者交换机等 NAS 设备。在左侧栏“RADIUS 客户端和服务器”下找到“RADIUS 客户端”，右键新建，填写 NAS 的 IP 地址和共享机密。

共享机密相当于 NAS 和 NPS 之间的私有口令，不要用太简单的字符串，也不要跟域管理员密码相同。配置完成后，NAS 端同样要填写 NPS 的 IP 和同样的共享机密。这一步只要有一边不一致，认证和记账都连不过去，日志里会出现大量来自该客户端的事件。

网络策略是认证和授权的核心。在 NPS 控制台左侧“策略”下找到“网络策略”，新建一条策略，先配置条件，比如 Windows 组、认证类型、NAS IPv4 地址，再配置约束，常见是 PEAP 或 MS-CHAPv2。没有策略时 NPS 默认拒绝所有请求，这一点新手最容易踩。策略建好后，可以先用真实终端做一次认证，确认能通，再进入记账配置，否则后面测试日志会因为认证都没通而失败。

3.2 配置本地文件记账

打开 NPS 控制台，左侧有“记账”节点。在中间面板选择“更改记账配置”，或者右键“记账”选择“更改记账配置”，会打开记账配置向导。这里有两个分支：本地文件日志记录和 SQL Server 日志记录。

选择“本地文件日志记录”，然后点击“配置”。关键参数有这么几个：

• 日志文件目录：默认是C:\Windows\System32\LogFiles，建议改成数据盘路径，比如D:\NPSLogs。
• 日志文件格式：有 IAS 格式和 NPS 格式。NPS 格式字段更丰富，新环境一律选 NPS 格式。
• 创建新日志文件：建议选“每天”，这样运维和归档都方便。
• 日志记录选项：勾选“记账请求”和“身份验证请求”。如果日志量太大，至少保留“记账请求”。

配置完确定后，向导会问“如果日志记录失败，是否丢弃网络访问请求”。这个选项默认是不丢弃。我建议在安全要求高的环境启用“丢弃”，这样如果日志写不进去，网络接入直接被拒绝，避免用户绕过审计上了网。但代价是日志系统一故障，全网断网，具体取舍要看业务容忍度。

3.3 将记账写入 SQL Server 数据库

如果选择了 SQL Server 日志记录，系统会要求配置一个 ODBC DSN。NPS 服务是 64 位进程，所以 DSN 必须在 64 位 ODBC 管理器中创建。很多同学装了 32 位数据库驱动后怎么都连不上，问题就出在这里。

配置 SQL Server 日志的基本思路是：在 SQL Server 中创建用于存放 NPS 日志的数据库，然后在 ODBC 里创建指向这个库的数据源，最后在 NPS 的 SQL Server 日志配置里选择这个 DSN，并指定 NPS 服务账户连接数据库时使用的账号。

需要注意，NPS 对数据库表结构有要求。实际项目中我见过两种做法，一种是用官方准备的表结构脚本创建好表，另一种是 NPS 服务自己在连接数据库后动态创建表。不同 Windows Server 版本行为不完全一致，我的建议是：上线前先在一个测试数据库里试点，确认 NPS 能成功写入例数据，再切生产。确认时可以做一次测试认证，然后去库里检查是否多出行记录。如果发现表结构报错，优先检查 DSN 位数、数据库账号权限和默认 Schema 是否匹配。

SQL Server 方案的优势是可以跨 NPS 集中查询，但也会引入数据库侧的故障点。数据库连不上时 NPS 记账就会失败，所以生产环境一定要给 SQL 连接加上监控告警。

3.4 开启安全审计事件

记账日志记录的是业务明细，而安全审计事件用来判断“谁被允许了、谁被拒绝了”。默认情况下，NPS 会把审计事件写到 Windows 安全日志中，但前提是系统审计策略中开启了“网络策略服务器”子类。

用管理员 PowerShell 执行：

auditpol /set /subcategory:"Network Policy Server" /success:enable /failure:enable

执行后可以通过事件查看器查看。比较常用的事件 ID 有这些：

看到 6273 时不要只扫一眼，要展开事件详细信息，里面有 Reason Code。Reason Code 对应 NPS 拒绝的具体原因，比如密码错误、证书不受信任、不满足策略条件。把这个代码和网络策略对照起来，能省很多排查时间。

安全日志默认容量是有限的，默认可能只有 20MB 左右。建议把安全日志大小调到你预期保留周期的上限，比如 200MB，并设置“覆盖最旧事件”策略，否则安全日志写满后 NPS 审计事件会丢失，或者服务受影响。

3.5 配置完成后的验证方法

配置完不要直接收工，至少做三轮验证。

第一轮，开一个无线终端做正常认证，成功后去记账日志目录看有没有生成当天的日志文件，再打开文件确认里面有 User-Name、Acct-Status-Type=Start 等信息。

第二轮，让终端正常下线，再去看日志里是否出现对应的 Stop 记录。如果没有 Stop，说明 NAS 没有把下线事件发给 NPS，问题很可能出在 NAS 的记账配置上，而不是 NPS。

第三轮，去事件查看器确认安全日志里出现了 6272 事件。同时可以故意输错一次密码，确认能出现 6273 事件。这样做完，记账和审计的链路才算全部打通。

4. 日志内容怎么看：从文本到数据库的三种分析姿势

4.1 本地文本日志的结构，别被 # 号吓到

NPS 的本地日志文件看起来像乱码，其实是有规律的文本。文件开头会有若干行#开头的元数据，比如软件版本、日期，关键是一行#Fields:，它定义了后面数据的列名，字段之间用逗号分隔。真正的数据行就是和这个表头对应的逗号分隔值。

举个例子，我简化一下表头：

#Software: Microsoft NPS #Fields: Server,User-Name,NAS-IP-Address,Acct-Status-Type,Acct-Session-Time NPS01,alice,192.168.100.1,1,0 NPS01,alice,192.168.100.1,3,1800 NPS01,alice,192.168.100.1,2,3600

第一行#Software说明本文日志是 NPS 生成的，第二行#Fields是列定义，数据行就是一条条 RADIUS 记录。如果你用的字段更多，表头会更长，但原理一样。用 Excel 打开时，直接把#开头的行删掉，再以逗号分隔解析即可。

4.2 用 PowerShell 快速统计日志

实际运维中不可能天天用 Excel 打开大日志。日志文件动辄几十 MB，Excel 会卡死。这时候用 PowerShell 做一次性统计非常方便。

我先用Get-Content把日志读进来，过滤掉#开头的元信息，然后从#Fields:行提取表头，再借助ConvertFrom-Csv按表头解析数据行：

$path = "C:\Windows\System32\LogFiles\IN20240601.log" $lines = Get-Content $path $headerLine = ($lines | Where-Object { $_ -like "#Fields:*" } | Select-Object -First 1) $header = $headerLine.Substring($headerLine.IndexOf(":") + 1).Trim() -split "," $data = $lines | Where-Object { $_ -notmatch "^#" } | ConvertFrom-Csv -Header $header

拿到$data后，就可以按字段分组统计。比如查收件人 Top 10：

$data | Group-Object User-Name | Sort-Object Count -Descending | Select-Object -First 10

也可以查失败认证次数：

$data | Where-Object { $_."Acct-Status-Type" -eq "2" -and $_."Acct-Terminate-Cause" -ne "0" } | Measure-Object

这里要注意，不同环境的#Fields:表头字段顺序可能不同，所以用列名访问最保险，不要写死[0]、[1]这种下标。

4.3 SQL Server 方案里的查询思路

如果你把 NPS 日志写进了 SQL Server，分析就灵活多了。用一条 SQL 就能统计某用户在某时间段的累计在线时长和流量。我以一个常规表结构为例：

SELECT UserName, SUM(AcctSessionTime) AS TotalSeconds, SUM(AcctInputOctets) AS TotalInputBytes, SUM(AcctOutputOctets) AS TotalOutputBytes FROM NPSAccounting WHERE AcctTime >= '2024-06-01 00:00:00' AND AcctTime < '2024-07-01 00:00:00' GROUP BY UserName ORDER BY TotalSeconds DESC;

实际使用时，字段名和表名要以你环境里的表结构为准。我第一次接 SQL 日志时也以为官方会自动建好一个固定的表，结果发现不同版本差异很大。所以拿到库之后先跑一句SELECT TOP 10 * FROM 表名，把真实字段刷一遍，再写统计 SQL，不要看着文档里的例子照抄。

数据库集中存储的另一个好处是可以做跨服务器汇总。比如你有三台 NPS，本地文件时代你得合并三个日志文件，数据库方案直接按时间字段查全量，省掉很多手工活。但也别把数据库当成无限容量垃圾桶，生产库也要做分区和归档。

5. 高频坑位与问题排查实录

5.1 NPS 记账与审计问题速查表

遇到问题先别急着重启服务，按下面的表对照一下，多半能定位到原因。

5.2 几个我实际踩过的经典案例

第一个案例，有认证没记账。当时环境里无线控制器只配了认证服务器地址，没配记账服务器地址，导致用户能上网但 NPS 上只有认证事件，没有任何 Start/Stop。这个问题光看 NPS 侧很难发现，因为认证事件一切正常。后来我去登录无线控制器，才发现记账页面空空如也。所以 NAS 侧的配置一定要检查完整，三个 A 是一套流程，认证通了不代表记账也通了。

第二个案例，时间不同步导致会话时长异常。某天领导要统计部门上网时长，我发现同一个人同一时段出现了大量重叠会话，而且时长有负数。排查后发现 NAS 系统时间比 NPS 快了一个多小时。NTP 没配，设备上手动时间也漂了。后面统一配了园区 NTP 源，再把历史数据清空重新统计，才恢复正常。时间同步不是小事，尤其在跨设备做日志关联时，时间不统一等于没有日志。

第三个案例，日志路径改到 D 盘后没有生成新文件。我修改了本地日志目录为D:\NPSLogs，但第二天检查发现前一天的文件还在系统盘旧路径，新路径没有文件生成。原因是日志目录权限没有给 Network Service 账户。NPS 服务无法在 D 盘对应目录创建文件，所以只能继续写旧位置。给目录加上 Network Service 的完全控制后，新文件立刻出现。这个坑非常隐蔽，因为控制台上不会报错，只有服务静默失败。

5.3 运维经验：监控比配置更重要

NPS 记账审计这类东西，配置是开始，运维才是大头。我的习惯是上线后把以下几个指标加入监控：NPS 服务状态、日志目录磁盘剩余空间、安全日志是否接近容量上限、SQL 日志连接是否正常。

尤其是日志磁盘空间。本地日志模式下，NPS 单台服务器一天产生几百 MB 日志完全可能。如果日志目录和系统盘放在一起，一次连续写满硬盘，整台服务器都可能拖垮。我现在做项目，只要条件允许就把日志目录放到独立数据盘，并且配置每天滚动，再用计划任务把一周前的日志压缩后转存到冷存储。

另外，安全日志的容量也要提前调。Windows 安全日志默认容量很低，遇到大规模认证风暴时，几小时内就可能填满。建议在系统初始化阶段就调到 200MB 以上并启用覆盖策略，保证 6272/6273 这类审计事件不会被挤掉。有些朋友为了省事把安全日志容量设成无限制，结果日志一满系统直接罢工，反而更危险。

5.4 一个小技巧：用计划任务自动归档 NPS 日志

最后分享一个我长期在用的归档方案。因为 NPS 本地日志按天生成，我直接在 Windows 任务计划程序里加了一个每日任务，把 N 天前的日志文件压缩移动到归档目录。

$logDir = "D:\NPSLogs" $archiveDir = "D:\NPSArchive" $days = 7 $cutoff = (Get-Date).AddDays(-$days) Get-ChildItem $logDir -Filter "IN*.log" | Where-Object { $_.LastWriteTime -lt $cutoff } | ForEach-Object { $dest = Join-Path $archiveDir ($_.BaseName + ".zip") Compress-Archive -Path $_.FullName -DestinationPath $dest -Force Remove-Item $_.FullName -Force }

这个脚本用Compress-Archive把早期日志打包成 zip，再删除原文件，既保留审计数据又不占活动目录空间。归档频率可以根据日志量调整，一周一次对大多数中小环境足够。如果环境特别大，也可以改成每日归档前一天的日志。

我个人做 NPS 运维这几年，最大的体会是：认证通了大家都开心，记账审计却往往是事后才想起来补。等要追溯安全事故或者统计报表的时候，才发现日志没开、字段没记全、日志被覆盖，那是最难受的。所以不要把记账审计当作上线后的附加项，把它当成网络接入服务的核心验收项来对待。先配好日志平台，再放真实用户接入，这样你的 NPS 才真正能用、可查、可审计。