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 的默认审核策略可能不会区分“逻辑删除”和真正的“物理删除”。高级审核策略可以更精细地控制事件日志记录。
- 操作:
- 打开组策略管理编辑器 (gpedit.msc)。
- 定位到“计算机配置” -> “Windows 设置” -> “安全设置” -> “高级审核策略配置” -> “系统审核策略 - 本地组策略对象” -> “帐户管理”。
- 启用“审核用户帐户管理”成功和失败的审核。
- 重要提示 : 配置高级审核后, 需要配合审核工具或者脚本进行细致过滤和区分. 通过分析更多的字段信息 (例如对象属性), 判断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
#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><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>
这个范例,是通过排查 "发起删除的计算机名"、"被删除的用户名",来尽量定位"假删除"。实际用的时候,换成你环境里的值。
- 提示 :这样,我们就可以排除大部分已知的 "误报",重点关注真实的帐户删除操作。
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就觉得恐慌。具体选择用哪些办法, 取决于你们对于环境掌控程度, 还有审核的精度要求.
希望上面的各种思路能帮到你!