我办公室里有一台独立的台式电脑，我每周都会在上面进行安全审计。我检查日志中是否有异常行为，然后将其导出并清除。
日志是填充出现“审核失败 Microsoft Windows 安全审核事件 ID 4673”
一项特权服务被称为
主题：
Security ID: System Account Name: Standalone_System_2$ Account Domain: WORKGROUP Logon ID: 0x307服务：
Server: Security Account Manager Service Name: Security Account Manager过程：
Process ID: 0x208 Process Name: C:\Windows\System32\lsass.ese服务请求信息：
Privileges: SeTcbPrivilege
我发现这篇 Technet 帖子建议我关闭“审计特权使用”......这不是我需要采取的路线。
有人认为可能是杀毒软件导致了这些日志条目……我不确定如何识别有问题的帐户或服务。我检查了系统上的服务，发现一个名为“安全帐户经理”，但这项服务不是名为“安全帐户经理”。
不知道去哪里，但我想控制这个审计日志！所有这些无用的条目几乎使查找实际事件变得不可能。
答案1
该线程的最后一篇文章讨论了使用特定工具来确定出现此错误的用户（登录 ID 自启动后是唯一的，但重新启动后会发生变化，因此您需要查看与此请求相关的帐户）并验证他们是否应该有权执行他们正在尝试的操作： http://answers.microsoft.com/en-us/windows/forum/windows_xp-security/577-many-failures-pertaining-to-setcbprivilege-in/3944f31c-dda4-46d9-adbf-74a9953dedeb
由于论坛内容有点难以阅读，因此在此转载：
我注意到我从 LSASS 获得了一大堆这样的信息。（大约 2 小时内收到了 17k 条信息... 无法弄清楚为什么事件记录器需要这么多的 I/O...（它记录了很多失败）...SeTCBPriv 失败了。
我使用了‘process hacker2’，（process explorer 的增强版，现在 procexp 由 MS 控制，（有点像让狐狸拥有你的工具来观察你鸡舍里的狐狸！）..
然后我可以查看 lsass（samss）正在使用哪个帐户运行。（无论是在服务中还是在 hacker2 进程中——在 sourceforge.net 上，顺便说一下）。
然后使用管理工具中的本地安全策略面板，并查看“用户权限分配”，我可以确保运行所需的所有必需权限（如服务 ACL 上所述，允许（如果不允许，它将不会运行，所以这通常不是问题），但是，还要确保运行 LSASS 的帐户具有“充当操作系统的一部分”（可信计算基/tcb）权限。
任何其他服务也是如此——它会产生大量审计失败...验证它在其 ACL 上是否具有所需的权限（使用 GUI 执行的操作非常神秘...）。如果您不确定....请在网上研究它，看看它是否应该具有该权限。如果它由 MS 签名和认证，那么您的系统可能配置错误（至少从该服务的角度来看 ;-)）然后您只需为其提供所需的权限 - PH2 中还有一个巧妙的功能，您只需单击一个选项即可选择该服务是否与一堆其他服务一起运行。到目前为止，已经能够将交互式内容（音频/视频/桌面）从后台服务中分离出来，因此我可以有效地对它们进行优先级排序 - 在最近发现之前，没有办法在不影响音频和/或桌面的情况下降低某些较低优先级服务的优先级...
无论如何，在确保 LSASS 具有 tcb 权限后，消息就消失了……
答案2
我知道这已经过时了，但是如果您使用任何带 IPSec 的域隔离，您将从 lsass.exe 获得数十万个成功的 4673 事件。我不明白 MS 为什么这样做。他们建议在高安全性环境中同时启用“审核敏感特权使用”以记录失败和成功，并使用 IPSec。如果您希望任何类型的安全日志持续超过一天，即使最大安全日志大小为 4gb，也不能同时使用两者。
有人为此给 MS 打了一巴掌。
答案3
多年来，我一直在尝试解决这个问题。MS Learn 文章说要监控成功/失败，但同时又说不要监控，因为数量太多。我在 Carvey 的《Windows Forensics》中找到了有关 SePrivileges 的详细信息。ChatGPT 对此进行了很好的讨论。我在下面找到了几篇新文章。ProcessHacker 对请求的令牌给出了一些见解。TMX 可能会有所帮助。wininternals 的其他工具如下：
“SeTcbPrivilege 的来源是对 ImportantFileWriter::WriteFileAtomically 的调用，这会导致对 Windows ReplaceFile 的调用，进而调用 NtSetSecurityObject，从而导致权限检查。”
我使用所有浏览器都得到 4673。沙盒、更新、遥测？检查系统级权限是有道理的。VirusTotal 将显示站点的权限请求。我使用 procmon 来过滤进程，但没有成功的条目。-browser | 使用 chrome taskmgr 获取进程 ID 并链接到阻止扩展。-onedrive | 可能来自重新映像的旧 SID。
看来微软在当时做了一个毫无价值的特权审计。我认为 Dave's Garage 在 YT 上说微软只打算将事件日志用于系统参考，而 Randy Smith 说事件查看器并不是一个真正的解决方案。由于 Chromium 开发人员也对此不屑一顾，我认为大家的共识是不要对其进行审计，除非您身处需要保留它的关键组织。我认为最好在事件发生后获取基线并启用监控。
https://learn.microsoft.com/en-us/archive/msdn-technet-forums/38c1ce35-7d90-4cd7-991a-eaafee6f748d