历史包袱：存量弱口令清理的三种策略与实战脚本

说实话，每次做口令合规项目，最头疼的不是新系统怎么设策略，而是那些已经跑了好几年的老系统。我见过一个金融客户，光AD域里就有三千多个账号，密码从来没改过。你想想看，这种历史包袱怎么处理？

直接全量重置？业务肯定炸。不处理？合规过不去。所以这一章，我把自己踩过的坑和总结出来的三种策略，一次性讲清楚。

策略一：渐进式强制重置（温和派）

这个策略适合业务连续性要求高的场景。说白了，就是给用户一个缓冲期，但最终必须改。

实施步骤

1. 扫描标记：用脚本批量检测所有账号的口令强度，把弱口令账号打上标签。
2. 分批次通知：按部门或安全等级，每周通知一批用户，要求7天内修改。
3. 到期强制：到期未改的账号，自动禁用或强制下次登录修改。

策略二：基于风险等级的差异化处理（务实派）

这个策略我比较推荐。不是所有弱口令都同等危险，你得区分对待。

风险等级	判定标准	处理方式	时间窗口
高危	口令为默认密码、与用户名相同、在Top100弱口令库中	立即强制重置，通知管理员	24小时内
中危	口令长度不足8位、仅含数字或字母	发送警告邮件，要求7天内修改	7天
低危	口令符合长度要求但未启用复杂性	建议修改，下次登录时提示	30天

为什么要这么分？我遇到过一家公司，把所有弱口令账号一刀切全部强制重置，结果CEO的账号也被锁了，当天就打电话骂IT总监。你想想看，这种事儿一次就够了。

策略三：批量重置+事后审计（激进派）

这个策略适合新系统上线、或者合规检查前的紧急整改。说白了，就是快刀斩乱麻。

实战脚本：批量检测并重置弱口令（PowerShell）

# 批量检测AD域中弱口令账号并重置
# 作者：资深工程师老王
# 使用前请确保有足够的权限

# 定义弱口令列表（示例）
$weakPasswords = @(
    "Password123",
    "12345678",
    "Admin@123",
    "P@ssw0rd",
    "Welcome1"
)

# 获取所有用户
$users = Get-ADUser -Filter {Enabled -eq $true} -Properties SamAccountName, PasswordLastSet

$weakAccounts = @()

foreach ($user in $users) {
    $sam = $user.SamAccountName
    
    # 这里用模拟检测，实际项目中需要调用密码验证接口
    foreach ($pwd in $weakPasswords) {
        try {
            # 模拟验证（实际项目用DirectoryEntry或API）
            $isWeak = Test-ADPassword -Identity $sam -Password $pwd
            if ($isWeak) {
                $weakAccounts += [PSCustomObject]@{
                    Username = $sam
                    WeakPassword = $pwd
                    LastSet = $user.PasswordLastSet
                }
                break
            }
        }
        catch {
            Write-Warning "检测 $sam 时出错: $_"
        }
    }
}

# 输出检测结果
$weakAccounts | Export-Csv -Path "weak_accounts.csv" -NoTypeInformation

# 高危账号立即重置（谨慎使用！）
# foreach ($account in $weakAccounts) {
#     $newPassword = Generate-RandomPassword -Length 16
#     Set-ADAccountPassword -Identity $account.Username -NewPassword (ConvertTo-SecureString $newPassword -AsPlainText -Force)
#     Set-ADUser -Identity $account.Username -ChangePasswordAtLogon $true
#     Write-Host "已重置: $($account.Username) -> 新密码已记录"
# }

三种策略对比

策略	适用场景	风险等级	用户影响	实施周期
渐进式强制重置	业务连续性要求高	低	中等	2-4周
基于风险等级差异化处理	大多数企业	中	低	1-2周
批量重置+事后审计	紧急整改、新系统上线	高	高	1-3天

核心逻辑流程图

实战中的几个关键点

• 先备份再操作：不管用哪种策略，一定要先导出所有账号的当前状态。我习惯用Get-ADUser -Filter * -Properties * | Export-Csv backup.csv做全量备份。
• 分批执行：别一次性搞所有账号。先拿测试账号试水，再逐步扩大范围。
• 通知要到位：邮件、短信、企业，能用的渠道都用上。我见过最惨的情况是，通知发到旧邮箱，用户根本收不到。
• 留好回滚方案：万一出问题，能在30分钟内恢复原状。这个时间窗口是我自己定的，超过30分钟，业务部门就要投诉了。