谁能拨入？VPN 访问前审计 msNPAllowDialin

密码正确，账户也在 VPN 组里，连接却仍被拒绝，返回的消息对策略只字未提。当这种情况发生在 Windows 远程访问服务器上时，我第一个查看的不是 NPS 规则，而是一个没人会打开的 Active Directory 属性：msNPAllowDialin，也就是“拨入”选项卡背后的值。它有三种状态，第三种会悄悄把决定权交给别处。多数时候并没有人故意改过它：账户是从模板克隆的，或者由多年前写入显式拒绝、此后再没复核过的脚本创建。

拒绝可能发生在策略被读取之前

Windows 在构建授权决定时会检查账户的拨入权限，所以显式拒绝会让对话提前结束。客户端看到的只是普通的身份验证失败，有时发生在证书交换完成之后，于是人们花一下午去测试那些从来不是问题的凭据。

反过来同样令人费解。从未设置过该标志的账户可能因为策略允许而连接成功，随后又因为有人因无关原因修改了 NPS 规则而连不上。这两种情况从外部看都不像拨入权限发生了变化。

三种状态，第三种是看不见的

TRUE允许拨入，FALSE拒绝拨入，而NULL表示账户从远程访问策略或 NPS 授权继承答案。图形界面把第三种状态显示为“Control access through NPS Network Policy”，读起来像未勾选的复选框，而不是一个决定。

所以从控制台清点允许的用户几乎说明不了什么。继承而来的账户可能在账户本身未被改动的情况下今天允许、明天拒绝，而FALSE账户仍可能在被配置为忽略用户拨入属性的策略的服务器上连接成功。把属性和策略放在一起读，否则你只审计了一半的决定。

导出标志时不要漏掉继承账户

在域控制器或装有 Active Directory 模块的工作站上运行导出，并把原始文件留作证据，而不是重新誊写一份摘要：

Get-ADUser -Filter * -Properties msNPAllowDialin, LastLogonDate |
  Select-Object SamAccountName, Enabled, msNPAllowDialin, LastLogonDate |
  Sort-Object SamAccountName |
  Export-Csv -NoTypeInformation .\dialin.csv

单个 LDAP 过滤器更容易粘进变更记录。这一条只返回显式允许：

dsquery * -Filter "(&(objectCategory=person)(objectClass=user)(msNPAllowDialin=TRUE))" -Attr sAMAccountName

然后去掉拨入子句再查一次，找出值为空的账户。这些就是继承账户，通常是域里最大的一组；跳过它们，审计就变成少数几个被某人记得手工配置过的人的名单。

把标志与组访问、账户健康状况分开

这个属性只回答一个问题：该账户能否拨入。它不说明此人是否还在职、账户是否启用，也不说明帮助台记录里是否躺着共享密码。请把导出结果与启用状态、最后登录时间以及授予服务器访问权限的组成员关系配在一起看。

真正要据以行动的是组合。停用账户带TRUE只是噪声。启用账户带TRUE且一年未登录，属于应清理的对象。而 VPN 组里没人能解释清楚的继承账户才是关键发现，因为没有任何单一设置记录它当初为何被授予。

要从 VPN 服务器实际用于认证的域控制器上读取。复制延迟可能显示服务器已经替换过的值，而引用过时 DC 值的审计在别人复核的那一刻就会被质疑。

改一个账户，并证明改动确实生效

要收回访问权，请把属性设为FALSE，而不是清除它。清除会让账户回到策略继承状态，下次连接时可能又被允许，这种改动看起来像修复，实际却是另一个决定：

dsmod user "CN=Jane Doe,OU=Staff,DC=corp,DC=example" -allowDialin no
Set-ADUser -Identity jdoe -Clear msNPAllowDialin

第二行是继承重置，特意单独列出，以免把两种操作混为一谈。随后从另一个会话确认，重新读取属性，并检查 NPS 计费事件中的拒绝记录，而不是相信控制台的刷新。

最后，写下每项远程访问服务的决定权归哪个机制。如果策略忽略用户拨入属性，那么组条件才是权威，该属性只对该服务有参考意义。同一域内的两项服务可以合法地给出不同答案，复核记录应当为每项服务各写一行。

经得起审计的产物很短：谁可以连接、依据哪个机制、何时复核、由谁复核。拨入标志提供前两个答案，其余只能由策略复核提供。