在企业网络环境中，交换机端口认证、无线控制器用户接入、VPN 远程拨入这些场景几乎都离不开统一认证。如果每台设备各自维护一套账号体系，管理成本会非常高。Windows Server 自带的 NPS（Network Policy Server，网络策略服务器）就是为解决这个问题而生的，它实现了标准的 RADIUS 协议，可以作为 RADIUS 服务器集中接收并处理来自网络接入设备（NAS，即 RADIUS 客户端）的认证、授权和计费请求。理解 NPS 处理 RADIUS 请求的内部流程，是正确配置和快速排错的前提。本文将从处理链路、实际配置和问题排查三个层面详细展开。
NPS 处理 RADIUS 请求的完整链路
当一台交换机通过 802.1X 收到终端的认证请求后，它会把这个请求封装成 RADIUS 报文，通过 UDP 1812 端口（认证授权）或 1645 端口（旧标准）发送给 NPS 服务器。NPS 收到报文后的第一步不是去查账号，而是验证报文中携带的共享密钥（Shared Secret）。共享密钥是 RADIUS 客户端与服务器之间预先约定的一段字符串，如果密钥不匹配，NPS 会直接静默丢弃报文，不会返回任何应答，这也是很多初学者排错时最容易忽略的一点。
通过密钥校验后，NPS 会依次检查网络策略（Network Policies）列表。策略列表是自上而下匹配的，第一条条件全部吻合的策略即被采用，后面的策略不再评估。策略的条件可以包括 Windows 组、NAS IP 地址、认证协议类型、时间段等。匹配到策略后，NPS 会根据策略中配置的权限（Grant access 或 Deny access）以及约束条件（如认证方法、会话超时、呼叫站 ID 限制）来决定处理方式。
认证环节由 NPS 与 Active Directory 域控制器配合完成。对于 802.1X 场景，常用 PEAP-MS-CHAPv2 或 EAP-TLS：前者依赖服务器证书建立隧道后做密码验证，后者要求客户端持有证书做双向认证。认证通过且策略允许访问后，NPS 会向网络设备返回 Access-Accept 报文，其中可以携带 RADIUS 属性（如 VLAN ID、过滤器 ID、会话超时），网络设备据此把终端划入对应 VLAN。整个过程的计费报文则走 UDP 1813 端口发送到 NPS 的 NPS 记账功能，可落地到本地文件或 SQL Server。
配置 RADIUS 客户端与网络策略的实操步骤
第一步是添加 RADIUS 客户端。打开服务器管理器，依次进入工具、网络策略服务器，在左侧控制台展开 RADIUS 客户端节点，右键选择新建 RADIUS 客户端。友好名称随意填写便于识别，地址栏填入交换机或无线控制器的管理 IP，共享密钥两边必须完全一致。如果网络设备数量多，也可以通过新建 RADIUS 客户端组来批量管理，策略条件里直接引用这个组即可。
第二步创建网络策略。在策略节点下新建策略，向导中先定义条件，最典型的组合是 Windows 组加上策略名称匹配。例如限制只有 Domain Users 组的成员可以接入无线网络，就添加条件 Windows 组等于 Domain Users。接着设置权限为「授予访问权限」，再到约束页面选择认证方法。这里需要特别说明：EAP 类型建议勾选 Microsoft 受保护的 EAP (PEAP)，并确认服务器证书是有效且受客户端信任的，否则 Windows 7 之后的系统默认会拒绝连接。
第三步调整策略的评估顺序。由于策略自上而下匹配，具体的策略要放在前面，宽泛的兜底策略放在后面。可以在策略列表中右键选择「上移」或「下移」调整。另外，事件日志的配置在 NPS 控制台的「网络策略服务器」属性中，建议把被拒绝的认证请求和成功认证的请求都勾选记录，方便后续排错。相关配置也可以通过命令行批量导出导出：
# 导出当前 NPS 配置到 XML 文件，便于备份或迁移 netsh nps export filename="C:\NPSBackup\nps_config.xml" exportPSK=YES # 查看已注册的 RADIUS 客户端数量 netsh nps show client # 重新注册 NPS 到 Active Directory（处理跨域认证问题时常用） netsh ras add registeredserver
上面最后一条命令在排错时非常实用。当 NPS 服务器需要读取用户所属的拨入属性或进行域认证时，必须在 Active Directory 中注册。通常安装 NPS 角色并加入域时会自动完成，但如果服务器改名或域迁移后出现认证失败，手动执行一次往往能解决问题。
RADIUS 请求被拒绝时的排查思路
排错的第一站永远是事件查看器。打开事件查看器，依次展开应用程序和服务日志、Microsoft、Windows、NetworkProfile-Operational 之外，更关键的是自定义视图中 NPS 相关的事件源，路径为 Windows 日志中安全日志里事件来源为 NPS 的记录，也可以直接在 NPS 控制台点击「事件日志」节点查看。常见事件 ID 含义如下：6272 表示请求已授权成功；6273 表示认证失败，原因可能是错误的用户名或密码；6274 表示由于策略不匹配或约束条件不满足导致连接尝试失败；6275 表示计费请求被丢弃。看到 6273 且原因代码为 16 时，通常是证书出了问题，比如服务器证书过期或客户端不信任颁发机构。
第二个常见问题是共享密钥不匹配。这种情况在 NPS 侧不会有任何日志记录（因为报文在解密阶段就被丢弃了），表现为网络设备端反复重试后超时。排查方法是回到 RADIUS 客户端属性里重新输入密钥，再到网络设备上重新配置一遍，注意两端都不能有多余的空格。如果怀疑网络层面不通，可以用以下命令验证端口可达性：
# 测试 NPS 服务器的认证端口是否可达 Test-NetConnection -ComputerName 192.168.10.5 -Port 1812 # 确认 NPS 服务本身处于运行状态 Get-Service -Name IAS # 查看 NPS 监听的 UDP 端口 netstat -anp udp | findstr "1812 1813 1645 1646"
第三类问题是策略匹配不到。如果事件日志里看到原因是「未找到匹配的网络策略」，说明请求的特征没有命中任何一条策略的条件组合。这时要逐项核对：请求方的源 IP 是否就是 RADIUS 客户端列表里登记的地址（多网卡或多 VLAN 场景容易出错）、用户的组成员关系是否符合条件、认证类型是否在策略中被允许。可以在网络策略属性的条件选项卡中逐个编辑条件，用「概述」视图确认逻辑关系。
最后值得一提的是，NPS 的日志数据可以写入本地文件（默认存放在 C:\Windows\System32\LogFiles\ 目录下，以 IN 开头的日志文件）或 SQL 数据库，配合免费的 NPS 日志分析工具可以把计费数据转换成可读的报表，用于审计哪些账号在什么时间通过哪台设备接入网络。对于大型网络，还建议部署多个 NPS 服务器组成 RADIUS 服务器组，在网络设备上配置主备 RADIUS 服务器地址，避免单点故障导致全网无法认证。掌握这些流程与技巧后，NPS 就能成为一套稳定可靠的企业级认证中枢。
NPSRADIUSWindows Server修改时间：2026-09-13 11:08:41