AD账户创建后出现4726事件？原因及解决（非误报）

2025-03-14 10:50:02

新建 AD 账户后迅速出现 4726 事件？别慌！

最近在排查问题的时候，我发现一个奇怪的现象：新创建的 AD 用户账户，在出现 4720（账户已创建）事件后，几分钟内竟然跟着一个 4726（账户已删除）事件！但实际上，这个账户并没有被删除，而且在 AD 中仍然是活动状态。这到底是怎么回事？

问题根源：AD 复制与逻辑删除

一番调查下来，发现这事儿跟 AD 复制的机制，以及一种特殊的删除方式——“逻辑删除”有关。

在多域控制器环境下，AD 使用一种多主复制模型。当你在一个域控制器上创建用户时，这个更改不会立即同步到所有其他域控制器。各个 DC 会根据配置的复制拓扑和计划进行同步。问题就出在这个同步过程中：

创建操作： 假设你在 DC1 上创建了一个用户。这时候会产生一个 4720 事件。
复制到其他 DC： DC1 会将这个“创建”操作复制到其他 DC。
“逻辑删除” (Tombstone)： 当一个 DC 收到这个变更时，为了确保所有属性正确同步, 并协调可能存在的冲突, 有可能 会首先在本地将对象标记为 "逻辑删除"状态 (设置一个叫 isDeleted 的属性), 生成4726。随后DC会紧接着立刻用新同步的信息去"复活"这个对象。这虽然看着像是删除了，其实只是一种中间状态，相当于给对象打了个“删除”的标记, 用户其实没有消失。这整个"逻辑删除-立刻复活"发生时间极短，几分钟之内都有可能发生。
“复活”： 然后，该 DC 会立刻应用“创建”操作，同步账户的各种属性，把账户“复活”。这个过程很快，用户在其他 DC 上就可以用了。

所以，虽然你看到了 4726 事件，但账户并没有真正被永久删除。逻辑删除，是一种内置的、确保 AD 复制过程中数据一致性的内部机制。

解决办法：能解决吗？还需要解决吗？

说实话, 严格来说这可能都算不上"问题", 更像是 AD 复制的一种底层行为表现. 一般来说, 我们无需做什么额外操作. 因为账户最终还是创建成功的，功能也是正常的。

但是！如果你实在很在意日志里的这个 4726，或者出于审计的需要，想要更精确的事件记录，我还是提供几个可以尝试的方向：

1. 检查复制健康状况

原理： 确保所有域控制器之间的复制正常工作，减少潜在的冲突和延迟。延迟过大，可能会让逻辑删除和复活的过程被拖长。
操作：
- 使用 repadmin /showrepl 命令检查复制状态。
- 使用 repadmin /replsummary 查看复制摘要。
- 使用 dcdiag 命令诊断域控制器健康状况。
```
repadmin /showrepl * /csv > repl.csv  # 把结果输出到 CSV，方便查看
repadmin /replsummary
dcdiag /v
```
注意： 如果有复制错误，优先解决复制问题。

2. 调整全局编录（如果使用了）

原理：全局编录服务器（GC）保存着域林中所有对象的副本。如果GC 复制的优先级、速度高于域分区(Domain Partition)复制，那这种短暂的4726-紧跟立刻复活的情况或许可以减轻。因为这样同步会快一点，来回拉扯变少。
操作：使用“Active Directory 站点和服务”管理单元 (dssite.msc)。
- 审查你现有的GC部署，按需增加或修改服务器。
- 可以尝试调整复制计划和连接的优先级, 让GC相关的更新可以快点同步过去.
进阶： GC 的复制不同于普通域复制。它有一套自己需要优化的方案. 具体配置方式复杂, 建议查看官方文档.

3. 使用高级审核策略 (区分物理/逻辑删除)

原理： Windows Server 的默认审核策略可能不会区分“逻辑删除”和真正的“物理删除”。高级审核策略可以更精细地控制事件日志记录。
操作：
1. 打开组策略管理编辑器 (gpedit.msc)。
2. 定位到“计算机配置” -> “Windows 设置” -> “安全设置” -> “高级审核策略配置” -> “系统审核策略 - 本地组策略对象” -> “帐户管理”。
3. 启用“审核用户帐户管理”成功和失败的审核。
重要提示 : 配置高级审核后, 需要配合审核工具或者脚本进行细致过滤和区分. 通过分析更多的字段信息 (例如对象属性), 判断4726事件发生的前后, 用户对象的状态到底有没有变化.
安全建议： 过度详细的审核日志可能会影响性能。根据实际需求调整审核级别。

4. 使用事件查看器的筛选功能

原理：如果我们无法或者不想从根本上消除这种4726，至少可以在查看日志时将其排除掉。

操作：在Windows 事件查看器中.

找到安全事件日志.
找到你想看的4720创建事件, 看看创建时间和用户名.
在筛选当前日志里面，手动设置一些条件过滤，排除紧跟的那个 4726事件. 可以基于时间，基于用户 SID，或者某些其他信息。
*例如, 可以按需自定义排除包含以下特定属性和内容的日志(举例，实际值需要自己从4726 日志获得)：

 <QueryList>
  <Query Id="0" Path="Security">
   <Select Path="Security">*[System[EventID=4726]]</Select>
   <Suppress Path="Security">
    *[EventData[Data[@Name='TargetUserName'] and (Data='NewlyCreatedUser <QueryList>
  <Query Id="0" Path="Security">
   <Select Path="Security">*[System[EventID=4726]]</Select>
   <Suppress Path="Security">
    *[EventData[Data[@Name='TargetUserName'] and (Data='NewlyCreatedUser$')]]
    and
    *[EventData[Data[@Name='SubjectUserName'] and (Data='DCComputerName$')]]
    </Suppress>
 </Query>
</QueryList>
#x27;)]]
    and
    *[EventData[Data[@Name='SubjectUserName'] and (Data='DCComputerName <QueryList>
  <Query Id="0" Path="Security">
   <Select Path="Security">*[System[EventID=4726]]</Select>
   <Suppress Path="Security">
    *[EventData[Data[@Name='TargetUserName'] and (Data='NewlyCreatedUser$')]]
    and
    *[EventData[Data[@Name='SubjectUserName'] and (Data='DCComputerName$')]]
    </Suppress>
 </Query>
</QueryList>
#x27;)]]
    </Suppress>
 </Query>
</QueryList>

这个范例，是通过排查 "发起删除的计算机名"、"被删除的用户名"，来尽量定位"假删除"。实际用的时候，换成你环境里的值。

提示：这样，我们就可以排除大部分已知的 "误报"，重点关注真实的帐户删除操作。

5. (终极方案，如果前述全部无效) 使用 PowerShell 监控与区分

原理：通过 PowerShell 脚本，主动、高频率的轮询用户对象的状态变更，尤其是对isDeleted 这个关键属性进行监视, 我们就有能力去识别出: 哪些 4726 是逻辑删除, 哪些是真正的删号。

代码示例 ：

# 高频监控 AD 用户，精准判断删除类型。

$UserSAM = "TestUser"  # 要监控的用户的 sAMAccountName
$Interval = 5         # 检查间隔（秒）

Write-Host "开始监控用户: $UserSAM"

while ($true) {
  try {
        $UserObject = Get-ADUser $UserSAM -Properties isDeleted, whenCreated, whenChanged

        if ($UserObject) {
          #用户存在
          if ($UserObject.isDeleted -eq $true)
           {
                Write-Warning "警告: 用户 '$UserSAM' 被逻辑删除 (isDeleted=True)!"
                # 此处，可以结合 whenCreated, whenChanged 进一步分析判断.
           }

           else{

                 Write-Host "用户 '$UserSAM' 当前正常 (isDeleted=False) 创建于$($UserObject.whenCreated), 最后修改:$($UserObject.whenChanged)"
           }
       }

       else
        {
          Write-Error "错误: 找不到用户 '$UserSAM' . 可能是被彻底删除了。"
          #可补充: 获取安全日志，检查4726。

        }
   }
 catch {
         #用户不存在的错误，一般是已经被彻底删除了。
         #记录错误，方便回溯分析。
        Write-Host $_
       }
 Start-Sleep -Seconds $Interval
}