域账号密码改不了这事在AD环境里几乎每周都能遇到。用户一脸茫然地跑过来说“密码明明没错就是改不动”Helpdesk查了一圈也不知道卡在哪。问题看起来简单但背后的原因可以排出一长串——账户属性勾错了、策略不达标、复制没同步、时间偏差、Kerberos票据异常任何一个环节都能让密码修改请求被域控拒掉。这篇就把我处理这类工单时的完整排查思路、常用命令和踩坑记录整理出来给同样被这事折磨的AD管理员和IT支持同学做个参考。1. 先搞清楚域环境里用户改密码的机制是什么样的1.1 你看到的“改密码”只是表面背后依赖一堆组件很多刚接触AD的同学容易把“改密码”当成一个简单的数据库更新操作实际上在域环境里用户按完CtrlAltDel点“更改密码”填完旧密码和新密码之后这串操作会走一条挺长的链路。客户端会先向域控发起一个Kerberos密码修改请求域控上的KDC服务收到后会验证旧密码是否正确、新密码是否符合域的密码策略、账户是否有权限修改自己的密码全部通过后才会把新密码哈希写入AD数据库。任何一个环节失败用户看到的都是“无法更新密码”之类的报错。这里关键要理解域用户密码不是存在本机的所以哪怕你在本机改密码本质上还是在跟域控“要权限”。这个机制也解释了为什么故障范围经常不一样。有时候是单个人改不了有时候是整个部门都改不了有时候是只有网页端能改、Windows登录界面不能改。链路里的每个节点都可能成为瓶颈排查时不能只盯着其中一个环节。1.2 为什么你天天改密码没事唯独这个用户不行我在处理工单时第一件事永远是判断问题范围是“个别用户”还是“全局故障”。这两种情况的排查方向完全不同。如果只有一个人报障优先检查这个用户的账户属性、ACL权限、当前锁定状态以及是不是刚好赶上强制改密后复制延迟。如果是很多人同时报障那就得先看密码策略、DC健康状态、链路连通性甚至可能是批量误操作改了用户属性。有个非常典型的案例某公司IT部门为了临时禁止一批离职风险员工改密码在ADUC里批量勾选了“用户不能更改密码”结果后来有几个员工正常在职勾选也忘了取消密码到期后想改根本改不了工单积压了一大堆。像这种情况光靠Helpdesk在界面上点来点去效率极低用PowerShell批量扫描账户属性几分钟就能全捞出来。2. 逐个排查域用户无法修改密码的常见原因清单2.1 最容易踩的坑ADUC里勾了“用户不能更改密码”这是我在实际环境里碰到频率最高的原因。这个选项藏在AD用户和计算机的属性对话框里位置是“账户”选项卡下面的“账户选项”列表。可能是有意设置、也可能是第三方同步工具批量改的反正一旦勾上这个用户自己改密码的权限就被ACL从底层拿掉了。这个复选框本质上是修改用户对象的访问控制列表给用户自身的ChangePassword权限加了一条拒绝Deny规则。所以你从任何渠道尝试自行修改密码都会被拒只有管理员强制重置可行。检查方法很简单在ADUC里双击用户找到“账户”选项卡就能看到。批量检查的话用PowerShell效率高得多Get-ADUser -Filter * -Properties CannotChangePassword | Where-Object {$_.CannotChangePassword -eq $true} | Select-Object SamAccountName, Name, CannotChangePassword | Format-Table -AutoSize解除勾选或者用命令批量清除Set-ADUser -Identity username -CannotChangePassword $false注意PowerShell里的属性名是CannotChangePassword含义正好跟界面上的“用户不能更改密码”一致方向上别搞反。2.2 “密码永不过期”与“用户必须在下一次登录时更改密码”的坑“密码永不过期”这个选项很常见我见过不少管理员误以为它会导致用户无法改密码。实际上它只是让账户密码不设置过期时间并不会禁止用户主动修改。但这里有个连环坑如果用户习惯长时间不换密码一旦某天系统强制要求修改比如安全合规检查后临时改了策略立刻就会遇到“密码过期”“无法登录”“改不了密码”等一系列问题用户根本分不清是哪个开关造成的。另一个容易踩的是“用户必须在下一次登录时更改密码”。运维人员重置密码后很多人会顺手把这个勾上让用户首次登录时强制改密。结果有时候勾了之后用户登录却没有任何提示后续也就一直用着初始密码。这种情况多半是GPO里启用了“交互式登录: 不要求按 CtrlAltDel”或者在特定登录场景比如远程桌面、自助服务终端下强制改密的触发机制没生效。排查思路是先确认ADUC里ChangePasswordAtLogon是否为True再看用户实际用的是什么登录方式。2.3 密码策略不达标复杂度、长度、历史记录、最短使用期限这算是另一种高频原因但特征更明显用户设置新密码后系统直接提示“不符合域的长度、复杂度或历史要求”。很多用户会反复试好几次都失败最后才来报障。域密码策略一般由默认域策略或细粒度密码策略控制默认情况下要求密码最少7位且符合复杂性要求这说的是“至少满足四类字符中的三类”。在实际加固过的环境里管理员可能把最小长度调高到10位甚至12位同时启用了密码历史记录记住最近24个密码和最短密码使用期限1天。历史记录的存在意味着你不能反复用同一批旧密码来回切。最短密码使用期限的存在意味着你当天改过一次密码后不能立即再改一次——即使新密码满足所有要求。有人戏称这个组合是“把人逼疯策略”。用户改密码前往往不知道这些限制我们做的第一件事就是帮他们对照策略规则构建一个合规的密码而不是让他们盲猜。查看当前策略的命令很直接Get-ADDefaultDomainPasswordPolicy注意密码策略是配置在域控上的如果策略刚修改过需要等复制完成后才能在所有DC上生效。2.4 账号锁定、禁用、过期、时间同步等问题有些用户改不了密码根本原因是账户状态已经不正常。比如连续多次输错旧密码触发了账户锁定阈值虽然界面上没明确告诉你“账户锁定”但密码修改请求就是不通过。还有账户被禁用、账户过期或者密码本身已经过期且“用户必须在下次登录时更改密码”没有生效这几种情况都可能导致改密流程卡住。比较隐蔽的是客户端和域控之间的时间偏差。Kerberos协议对时间同步比较敏感如果客户端机器时间跟域控相差太大密码修改请求可能直接在认证阶段失败用户看到的报错非常模糊比如“没有足够的系统资源”或“域控制器无法连接”。排查时可以手动调整客户端时间校准后再试一次。这个问题在频繁休眠、手动调过时间、虚拟机时钟漂移的机器上更容易出现。3. 一步步实操从接到工单到解决问题的完整流程3.1 第一步收集信息缩小排查范围接到工单时我建议先花几分钟确认几个关键信息报错截图、涉及账号、涉及终端类型Windows登录界面/远程桌面/网页/OA、其他人是否正常、密码过期时间是什么时候。这个阶段的核心逻辑是区分“账号问题”“策略问题”还是“网络/终端问题”。如果是网页或OA能正常改只有Windows登录界面不能改问题更可能出在客户端或Kerberos票据上。如果所有渠道都不能改优先看账户属性和密码策略。一个实用的小技巧让用户尝试用“域控所在网段”的机器操作一次如果换了一台机器就能改那基本能排除账户本身的问题把注意力放到原客户端环境上。3.2 第二步检查账户属性和密码策略先查账户状态和属性Get-ADUser -Identity username -Properties PasswordNeverExpires, CannotChangePassword, PasswordLastSet, LockedOut, Enabled, AccountExpirationDate | Format-List SamAccountName, PasswordNeverExpires, CannotChangePassword, PasswordLastSet, LockedOut, Enabled, AccountExpirationDate输出结果里PasswordLastSet如果是0显示为1/1/1601说明账户被设置成了“必须在下次登录时修改密码”如果 LockedOut 为 True说明账户被锁Enabled为False则账户被禁用CannotChangePassword为True就是最前面说的那个坑。再看密码策略Get-ADDefaultDomainPasswordPolicy如果启用了细粒度密码策略可以用Get-ADFineGrainedPasswordPolicy -Filter *查看。关键参数一般就看这几个MinPasswordLength、ComplexityEnabled、PasswordHistoryCount、MaxPasswordAge、MinPasswordAge。对照用户想设置的新密码一眼就能判断是不是策略卡住了。3.3 第三步按原因修复如果发现“用户不能更改密码”被勾选清除即可Set-ADUser -Identity username -CannotChangePassword $false如果密码已经过期管理员可以重置密码并设置下次登录强制改密这是最常用的操作$newPassword ConvertTo-SecureString -String TemporaryPass#2025 -AsPlainText -Force Set-ADUser -Identity username -ChangePasswordAtLogon $true Set-ADAccountPassword -Identity username -NewPassword $newPassword -Reset这里要特别注意Set-ADAccountPassword -Reset是管理员重置行为不需要旧密码执行后账户密码会立即变为临时密码-ChangePasswordAtLogon $true会把 pwdLastSet 设为0强制用户下次登录时修改。实际上执行顺序上可以先重置密码再开强制改密也可以反过来系统都能正确标记。如果是因为最短密码使用期限导致“改完一次不能立刻再改”直接说明无法绕过只能等期限到。但有一种场景是全新创建的用户第一次登录就被要求改密码如果在ADUC里勾了“用户必须在下一次登录时更改密码”但系统没弹窗可以把该选项取消然后再勾上有时能触发重新标记。3.4 第四步验证结果并查看安全日志修改完成后建议找用户实测一次而不是只看命令返回成功就关工单。让用户在测试终端上按CtrlAltDel进行一次改密看是否成功、是否收到警告。如果还不行去域控安全日志里查事件ID4723用户自己发起了修改密码操作无论是否成功都会记录尝试4724管理员执行了重置密码操作4740账户被锁定日志能看到具体是哪个账号、哪台设备、哪个DC处理的请求对判断问题出在哪个环节很有帮助。比如4723事件出现在某个DC上但另一个DC上没有那大概率是复制延迟或者最近站点DC路由问题。4. 从根上杜绝批量管理改密权限与策略的进阶做法4.1 为什么别随便勾“用户不能更改密码”聊几个实操中比较常见的场景。很多企业为了管控员工密码会在根属性上直接勾掉用户的改密权限但这本质上是一个“一锤子买卖”式的操作后续非常难跟踪。我处理过一个客户运维团队为了临时冻结一批关键岗位员工的密码修改权限用脚本批量把CannotChangePassword设为True结果三个月后这批员工的密码全部到期但大家完全想不起来当初设了这项规则。更麻烦的是安全合规要求员工必须每90天改一次密码最后只能靠批量脚本再清一遍属性中间还夹杂着离职、转岗等人员变动非常混乱。所以我的建议是不要在普通用户账户上长期启用“用户不能更改密码”。如果你真想管控某类账户的密码修改行为优先考虑组策略配合受限委派或者用AD的细粒度密码策略来约束而不是一刀切地把权限掐死。只有服务账户或特定系统账户才建议勾选“用户不能更改密码”“密码永不过期”这类属性。4.2 密码策略应该怎么配才科学域环境的密码策略不是越严格越好而是要在安全性和可用性之间找到平衡。我见过有企业把密码策略设成最小长度16位、四类字符全要、还要强制历史24个密码结果员工只能把密码写在便利贴上。密码复杂度再高一旦变成纸质张贴安全等级直接归零。比较务实的做法是区分账户类型用细粒度密码策略管理不同用户组普通用户最小长度10-12位复杂度启用历史记录12-24个最长有效期90天最短有效期1天管理员账户最小长度14-16位复杂度启用历史记录24个最长有效期60天最短有效期1天服务账户建议用组托管服务账户gMSA密码自动轮换不依赖人工改密细粒度密码策略是AD林功能级别Windows Server 2008以上才能用的功能。如果还没使用建议在测试环境先验证好再逐步推广。改了密码策略之后记得给DC组策略刷新留出时间必要时手动gpupdate /force不要指望改完配置的下一秒用户就能立刻用新规则改密。4.3 给自助服务留后路SSPR和改密门户如果企业经常出现“密码过期后用户才报障”的情况一个很有效的止损办法是部署自助密码重置平台。微软云端的SSPR已经支持向本地AD写回密码很多第三方产品也支持对接AD让用户通过网页或钉钉/企业微信完成身份验证后自行改密。这类方案能在很大程度上缓解Helpdesk压力但部署时要注意和AD账户属性的兼容性。我见过有第三方平台在“重置密码”和“用户自行修改密码”之间的逻辑处理不当导致很多账户的CannotChangePassword属性被意外勾选结果自助平台自己成了无法改密的来源。搭配自助平台时建议定期运行一下本文里的扫描命令检查是否有异常属性变更这一点很重要。5. 实际问题排查速查表5.1 报错信息与解决对照整理一个我经常用的小速查表遇到报错直接对着查常见提示可能原因处理方式无法更新密码。为新密码提供的值不符合域的长度、复杂性或历史要求密码策略不满足查看策略构造合规新密码用户不能更改密码ADUC中启用了“用户不能更改密码”清除CannotChangePassword属性没有足够的权限当前账号权限不足使用管理员账号操作或申请委派权限不能立即修改密码最短密码使用期限未到等待期限满足后再修改域控制器拒绝密码更改请求账户锁定、禁用、过期检查账户锁定/禁用/过期状态系统资源不足客户端与DC时间偏差较大校准时间后重试必须在下次登录时更改密码账户被标记为ChangePasswordAtLogon首次登录时正常改密5.2 我从实战里踩过的几个坑第一个坑是批量操作时天真的以为“不勾选用户不能更改密码”只需重新清空复选框就行。实际上如果你用的是ADUC的“属性编辑器”要找到msDS-User-Account-Control-Computed之类派生属性容易眼花。用PowerShell的-CannotChangePassword $false反而最直观。第二个坑是修改默认域策略里的密码策略后以为马上生效。有一次我改了最小密码长度用户立刻去试新密码就是不通过排查了半天才发现是另一台DC的GPO复制没完成。密码策略这种GPO的刷新周期本身就比普通组策略长而且到期生效不是即时的建议改完策略后手动在域控上gpupdate /force再查看Get-ADDefaultDomainPasswordPolicy是否已更新。第三个坑是忽略时间同步。有个分公司反馈大量用户改不了密码报错五花八门最后发现是分公司的PDC仿真器时间漂移了几分钟所有客户端的Kerberos请求都受影响校准时间后恢复正常。域内时间同步看起来不起眼但绝对值得纳入改密问题排查清单。6. 最后再分享一个我常用的批量排查小技巧处理“无法修改密码”这类问题最烦的就是一个个点开用户属性检查。我后来把扫描命令做成了一个快速诊断脚本每次接到批量工单就直接跑一趟把所有异常账户捞出来Get-ADUser -Filter * -Properties * | Where-Object {$_.CannotChangePassword -eq $true} | Select-Object SamAccountName, CannotChangePassword | Export-Csv -Path CannotChange.csv -NoTypeInformation -Encoding UTF8 Get-ADUser -Filter * -Properties * | Where-Object {$_.PasswordNeverExpires -eq $true} | Select-Object SamAccountName, PasswordNeverExpires | Export-Csv -Path NeverExpires.csv -NoTypeInformation -Encoding UTF8这两条命令能把“用户不能更改密码”和“密码永不过期”的账户全部导出来适合定期的账号合规检查和问题账户梳理。说句实在的这类问题的排查思路比操作本身重要得多——先在脑子里过一遍“账户属性、策略、时间/DC状态、客户端环境”这几个维度再动手大概率能少走很多弯路。
AD域用户无法改密码？账户属性与密码策略排查指南
域账号密码改不了这事在AD环境里几乎每周都能遇到。用户一脸茫然地跑过来说“密码明明没错就是改不动”Helpdesk查了一圈也不知道卡在哪。问题看起来简单但背后的原因可以排出一长串——账户属性勾错了、策略不达标、复制没同步、时间偏差、Kerberos票据异常任何一个环节都能让密码修改请求被域控拒掉。这篇就把我处理这类工单时的完整排查思路、常用命令和踩坑记录整理出来给同样被这事折磨的AD管理员和IT支持同学做个参考。1. 先搞清楚域环境里用户改密码的机制是什么样的1.1 你看到的“改密码”只是表面背后依赖一堆组件很多刚接触AD的同学容易把“改密码”当成一个简单的数据库更新操作实际上在域环境里用户按完CtrlAltDel点“更改密码”填完旧密码和新密码之后这串操作会走一条挺长的链路。客户端会先向域控发起一个Kerberos密码修改请求域控上的KDC服务收到后会验证旧密码是否正确、新密码是否符合域的密码策略、账户是否有权限修改自己的密码全部通过后才会把新密码哈希写入AD数据库。任何一个环节失败用户看到的都是“无法更新密码”之类的报错。这里关键要理解域用户密码不是存在本机的所以哪怕你在本机改密码本质上还是在跟域控“要权限”。这个机制也解释了为什么故障范围经常不一样。有时候是单个人改不了有时候是整个部门都改不了有时候是只有网页端能改、Windows登录界面不能改。链路里的每个节点都可能成为瓶颈排查时不能只盯着其中一个环节。1.2 为什么你天天改密码没事唯独这个用户不行我在处理工单时第一件事永远是判断问题范围是“个别用户”还是“全局故障”。这两种情况的排查方向完全不同。如果只有一个人报障优先检查这个用户的账户属性、ACL权限、当前锁定状态以及是不是刚好赶上强制改密后复制延迟。如果是很多人同时报障那就得先看密码策略、DC健康状态、链路连通性甚至可能是批量误操作改了用户属性。有个非常典型的案例某公司IT部门为了临时禁止一批离职风险员工改密码在ADUC里批量勾选了“用户不能更改密码”结果后来有几个员工正常在职勾选也忘了取消密码到期后想改根本改不了工单积压了一大堆。像这种情况光靠Helpdesk在界面上点来点去效率极低用PowerShell批量扫描账户属性几分钟就能全捞出来。2. 逐个排查域用户无法修改密码的常见原因清单2.1 最容易踩的坑ADUC里勾了“用户不能更改密码”这是我在实际环境里碰到频率最高的原因。这个选项藏在AD用户和计算机的属性对话框里位置是“账户”选项卡下面的“账户选项”列表。可能是有意设置、也可能是第三方同步工具批量改的反正一旦勾上这个用户自己改密码的权限就被ACL从底层拿掉了。这个复选框本质上是修改用户对象的访问控制列表给用户自身的ChangePassword权限加了一条拒绝Deny规则。所以你从任何渠道尝试自行修改密码都会被拒只有管理员强制重置可行。检查方法很简单在ADUC里双击用户找到“账户”选项卡就能看到。批量检查的话用PowerShell效率高得多Get-ADUser -Filter * -Properties CannotChangePassword | Where-Object {$_.CannotChangePassword -eq $true} | Select-Object SamAccountName, Name, CannotChangePassword | Format-Table -AutoSize解除勾选或者用命令批量清除Set-ADUser -Identity username -CannotChangePassword $false注意PowerShell里的属性名是CannotChangePassword含义正好跟界面上的“用户不能更改密码”一致方向上别搞反。2.2 “密码永不过期”与“用户必须在下一次登录时更改密码”的坑“密码永不过期”这个选项很常见我见过不少管理员误以为它会导致用户无法改密码。实际上它只是让账户密码不设置过期时间并不会禁止用户主动修改。但这里有个连环坑如果用户习惯长时间不换密码一旦某天系统强制要求修改比如安全合规检查后临时改了策略立刻就会遇到“密码过期”“无法登录”“改不了密码”等一系列问题用户根本分不清是哪个开关造成的。另一个容易踩的是“用户必须在下一次登录时更改密码”。运维人员重置密码后很多人会顺手把这个勾上让用户首次登录时强制改密。结果有时候勾了之后用户登录却没有任何提示后续也就一直用着初始密码。这种情况多半是GPO里启用了“交互式登录: 不要求按 CtrlAltDel”或者在特定登录场景比如远程桌面、自助服务终端下强制改密的触发机制没生效。排查思路是先确认ADUC里ChangePasswordAtLogon是否为True再看用户实际用的是什么登录方式。2.3 密码策略不达标复杂度、长度、历史记录、最短使用期限这算是另一种高频原因但特征更明显用户设置新密码后系统直接提示“不符合域的长度、复杂度或历史要求”。很多用户会反复试好几次都失败最后才来报障。域密码策略一般由默认域策略或细粒度密码策略控制默认情况下要求密码最少7位且符合复杂性要求这说的是“至少满足四类字符中的三类”。在实际加固过的环境里管理员可能把最小长度调高到10位甚至12位同时启用了密码历史记录记住最近24个密码和最短密码使用期限1天。历史记录的存在意味着你不能反复用同一批旧密码来回切。最短密码使用期限的存在意味着你当天改过一次密码后不能立即再改一次——即使新密码满足所有要求。有人戏称这个组合是“把人逼疯策略”。用户改密码前往往不知道这些限制我们做的第一件事就是帮他们对照策略规则构建一个合规的密码而不是让他们盲猜。查看当前策略的命令很直接Get-ADDefaultDomainPasswordPolicy注意密码策略是配置在域控上的如果策略刚修改过需要等复制完成后才能在所有DC上生效。2.4 账号锁定、禁用、过期、时间同步等问题有些用户改不了密码根本原因是账户状态已经不正常。比如连续多次输错旧密码触发了账户锁定阈值虽然界面上没明确告诉你“账户锁定”但密码修改请求就是不通过。还有账户被禁用、账户过期或者密码本身已经过期且“用户必须在下次登录时更改密码”没有生效这几种情况都可能导致改密流程卡住。比较隐蔽的是客户端和域控之间的时间偏差。Kerberos协议对时间同步比较敏感如果客户端机器时间跟域控相差太大密码修改请求可能直接在认证阶段失败用户看到的报错非常模糊比如“没有足够的系统资源”或“域控制器无法连接”。排查时可以手动调整客户端时间校准后再试一次。这个问题在频繁休眠、手动调过时间、虚拟机时钟漂移的机器上更容易出现。3. 一步步实操从接到工单到解决问题的完整流程3.1 第一步收集信息缩小排查范围接到工单时我建议先花几分钟确认几个关键信息报错截图、涉及账号、涉及终端类型Windows登录界面/远程桌面/网页/OA、其他人是否正常、密码过期时间是什么时候。这个阶段的核心逻辑是区分“账号问题”“策略问题”还是“网络/终端问题”。如果是网页或OA能正常改只有Windows登录界面不能改问题更可能出在客户端或Kerberos票据上。如果所有渠道都不能改优先看账户属性和密码策略。一个实用的小技巧让用户尝试用“域控所在网段”的机器操作一次如果换了一台机器就能改那基本能排除账户本身的问题把注意力放到原客户端环境上。3.2 第二步检查账户属性和密码策略先查账户状态和属性Get-ADUser -Identity username -Properties PasswordNeverExpires, CannotChangePassword, PasswordLastSet, LockedOut, Enabled, AccountExpirationDate | Format-List SamAccountName, PasswordNeverExpires, CannotChangePassword, PasswordLastSet, LockedOut, Enabled, AccountExpirationDate输出结果里PasswordLastSet如果是0显示为1/1/1601说明账户被设置成了“必须在下次登录时修改密码”如果 LockedOut 为 True说明账户被锁Enabled为False则账户被禁用CannotChangePassword为True就是最前面说的那个坑。再看密码策略Get-ADDefaultDomainPasswordPolicy如果启用了细粒度密码策略可以用Get-ADFineGrainedPasswordPolicy -Filter *查看。关键参数一般就看这几个MinPasswordLength、ComplexityEnabled、PasswordHistoryCount、MaxPasswordAge、MinPasswordAge。对照用户想设置的新密码一眼就能判断是不是策略卡住了。3.3 第三步按原因修复如果发现“用户不能更改密码”被勾选清除即可Set-ADUser -Identity username -CannotChangePassword $false如果密码已经过期管理员可以重置密码并设置下次登录强制改密这是最常用的操作$newPassword ConvertTo-SecureString -String TemporaryPass#2025 -AsPlainText -Force Set-ADUser -Identity username -ChangePasswordAtLogon $true Set-ADAccountPassword -Identity username -NewPassword $newPassword -Reset这里要特别注意Set-ADAccountPassword -Reset是管理员重置行为不需要旧密码执行后账户密码会立即变为临时密码-ChangePasswordAtLogon $true会把 pwdLastSet 设为0强制用户下次登录时修改。实际上执行顺序上可以先重置密码再开强制改密也可以反过来系统都能正确标记。如果是因为最短密码使用期限导致“改完一次不能立刻再改”直接说明无法绕过只能等期限到。但有一种场景是全新创建的用户第一次登录就被要求改密码如果在ADUC里勾了“用户必须在下一次登录时更改密码”但系统没弹窗可以把该选项取消然后再勾上有时能触发重新标记。3.4 第四步验证结果并查看安全日志修改完成后建议找用户实测一次而不是只看命令返回成功就关工单。让用户在测试终端上按CtrlAltDel进行一次改密看是否成功、是否收到警告。如果还不行去域控安全日志里查事件ID4723用户自己发起了修改密码操作无论是否成功都会记录尝试4724管理员执行了重置密码操作4740账户被锁定日志能看到具体是哪个账号、哪台设备、哪个DC处理的请求对判断问题出在哪个环节很有帮助。比如4723事件出现在某个DC上但另一个DC上没有那大概率是复制延迟或者最近站点DC路由问题。4. 从根上杜绝批量管理改密权限与策略的进阶做法4.1 为什么别随便勾“用户不能更改密码”聊几个实操中比较常见的场景。很多企业为了管控员工密码会在根属性上直接勾掉用户的改密权限但这本质上是一个“一锤子买卖”式的操作后续非常难跟踪。我处理过一个客户运维团队为了临时冻结一批关键岗位员工的密码修改权限用脚本批量把CannotChangePassword设为True结果三个月后这批员工的密码全部到期但大家完全想不起来当初设了这项规则。更麻烦的是安全合规要求员工必须每90天改一次密码最后只能靠批量脚本再清一遍属性中间还夹杂着离职、转岗等人员变动非常混乱。所以我的建议是不要在普通用户账户上长期启用“用户不能更改密码”。如果你真想管控某类账户的密码修改行为优先考虑组策略配合受限委派或者用AD的细粒度密码策略来约束而不是一刀切地把权限掐死。只有服务账户或特定系统账户才建议勾选“用户不能更改密码”“密码永不过期”这类属性。4.2 密码策略应该怎么配才科学域环境的密码策略不是越严格越好而是要在安全性和可用性之间找到平衡。我见过有企业把密码策略设成最小长度16位、四类字符全要、还要强制历史24个密码结果员工只能把密码写在便利贴上。密码复杂度再高一旦变成纸质张贴安全等级直接归零。比较务实的做法是区分账户类型用细粒度密码策略管理不同用户组普通用户最小长度10-12位复杂度启用历史记录12-24个最长有效期90天最短有效期1天管理员账户最小长度14-16位复杂度启用历史记录24个最长有效期60天最短有效期1天服务账户建议用组托管服务账户gMSA密码自动轮换不依赖人工改密细粒度密码策略是AD林功能级别Windows Server 2008以上才能用的功能。如果还没使用建议在测试环境先验证好再逐步推广。改了密码策略之后记得给DC组策略刷新留出时间必要时手动gpupdate /force不要指望改完配置的下一秒用户就能立刻用新规则改密。4.3 给自助服务留后路SSPR和改密门户如果企业经常出现“密码过期后用户才报障”的情况一个很有效的止损办法是部署自助密码重置平台。微软云端的SSPR已经支持向本地AD写回密码很多第三方产品也支持对接AD让用户通过网页或钉钉/企业微信完成身份验证后自行改密。这类方案能在很大程度上缓解Helpdesk压力但部署时要注意和AD账户属性的兼容性。我见过有第三方平台在“重置密码”和“用户自行修改密码”之间的逻辑处理不当导致很多账户的CannotChangePassword属性被意外勾选结果自助平台自己成了无法改密的来源。搭配自助平台时建议定期运行一下本文里的扫描命令检查是否有异常属性变更这一点很重要。5. 实际问题排查速查表5.1 报错信息与解决对照整理一个我经常用的小速查表遇到报错直接对着查常见提示可能原因处理方式无法更新密码。为新密码提供的值不符合域的长度、复杂性或历史要求密码策略不满足查看策略构造合规新密码用户不能更改密码ADUC中启用了“用户不能更改密码”清除CannotChangePassword属性没有足够的权限当前账号权限不足使用管理员账号操作或申请委派权限不能立即修改密码最短密码使用期限未到等待期限满足后再修改域控制器拒绝密码更改请求账户锁定、禁用、过期检查账户锁定/禁用/过期状态系统资源不足客户端与DC时间偏差较大校准时间后重试必须在下次登录时更改密码账户被标记为ChangePasswordAtLogon首次登录时正常改密5.2 我从实战里踩过的几个坑第一个坑是批量操作时天真的以为“不勾选用户不能更改密码”只需重新清空复选框就行。实际上如果你用的是ADUC的“属性编辑器”要找到msDS-User-Account-Control-Computed之类派生属性容易眼花。用PowerShell的-CannotChangePassword $false反而最直观。第二个坑是修改默认域策略里的密码策略后以为马上生效。有一次我改了最小密码长度用户立刻去试新密码就是不通过排查了半天才发现是另一台DC的GPO复制没完成。密码策略这种GPO的刷新周期本身就比普通组策略长而且到期生效不是即时的建议改完策略后手动在域控上gpupdate /force再查看Get-ADDefaultDomainPasswordPolicy是否已更新。第三个坑是忽略时间同步。有个分公司反馈大量用户改不了密码报错五花八门最后发现是分公司的PDC仿真器时间漂移了几分钟所有客户端的Kerberos请求都受影响校准时间后恢复正常。域内时间同步看起来不起眼但绝对值得纳入改密问题排查清单。6. 最后再分享一个我常用的批量排查小技巧处理“无法修改密码”这类问题最烦的就是一个个点开用户属性检查。我后来把扫描命令做成了一个快速诊断脚本每次接到批量工单就直接跑一趟把所有异常账户捞出来Get-ADUser -Filter * -Properties * | Where-Object {$_.CannotChangePassword -eq $true} | Select-Object SamAccountName, CannotChangePassword | Export-Csv -Path CannotChange.csv -NoTypeInformation -Encoding UTF8 Get-ADUser -Filter * -Properties * | Where-Object {$_.PasswordNeverExpires -eq $true} | Select-Object SamAccountName, PasswordNeverExpires | Export-Csv -Path NeverExpires.csv -NoTypeInformation -Encoding UTF8这两条命令能把“用户不能更改密码”和“密码永不过期”的账户全部导出来适合定期的账号合规检查和问题账户梳理。说句实在的这类问题的排查思路比操作本身重要得多——先在脑子里过一遍“账户属性、策略、时间/DC状态、客户端环境”这几个维度再动手大概率能少走很多弯路。
