返回

AD账户创建后出现4726事件?原因及解决(非误报)

windows

新建 AD 账户后迅速出现 4726 事件?别慌!

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

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

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

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

  1. 创建操作: 假设你在 DC1 上创建了一个用户。 这时候会产生一个 4720 事件。

  2. 复制到其他 DC: DC1 会将这个“创建”操作复制到其他 DC。

  3. “逻辑删除” (Tombstone): 当一个 DC 收到这个变更时,为了确保所有属性正确同步, 并协调可能存在的冲突, 有可能 会首先在本地将对象标记为 "逻辑删除"状态 (设置一个叫 isDeleted 的属性), 生成4726。随后DC会紧接着立刻用新同步的信息去"复活"这个对象。 这虽然看着像是删除了,其实只是一种中间状态,相当于给对象打了个“删除”的标记, 用户其实没有消失。 这整个"逻辑删除-立刻复活"发生时间极短,几分钟之内都有可能发生。

  4. “复活”: 然后,该 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
    }
    
    • 进阶使用: 可以将这个脚本做成一个服务。或者,更高级的,对接你们现有的监控平台(如果存在)。
    • 安全建议 :运行此类监控脚本, 应该使用低权限账户. 防止密钥/密码等在脚本里硬编码, 将凭据安全保存(例如使用 Get-Credential) 。

小结

新创建 AD 账户后几分钟出现 4726 事件,大多数情况下是正常现象。 理解了背后 AD 的逻辑删除和复制原理, 就可以有的放矢进行处理, 而不是看到4726就觉得恐慌。具体选择用哪些办法, 取决于你们对于环境掌控程度, 还有审核的精度要求.

希望上面的各种思路能帮到你!