在组策略中，我们Deny logon through Remote Desktop为该Domain Computers组启用了设置。我将属于该组的一台计算机提升为域控制器。提升后，计算机当然不再是该组的成员Domain Computers，但是：
- 该
Deny logon through Remote Desktop设置仍然有效 - 组策略结果中未列出该设置
我最终发现您可以在Local Security PolicyMMC 中编辑设置，但现在我很担心，因为：
- 您无法轻松确定该值是否已从默认值更改，因为本地安全策略中的设置没有
Define these policy settings框 - 远程审核很困难，因为设置不会显示在组策略结果中
有人知道这种行为的解决方法吗？如果没有可用的解决方法，是否有一种简单的方法来审核这些设置？
答案1
域控制器有自己的本地安全策略，就像普通域成员一样。组策略也将优先/覆盖本地安全策略，就像对普通域成员一样。
正如您所见，即使 GPO 不再适用于计算机，许多组策略设置也能够“标记”或留下系统的本地安全策略的痕迹。不是在 GPO 不再适用后对系统进行修改，通常会修改 Windows 注册表中特殊“策略”子项下的设置。大多数组策略都表现良好并遵循此模式，但并非所有组策略都如此。
在域环境中管理配置设置的第一个明显的解决方案是，如果您关心某个设置，请在组策略中设置它，以便它将覆盖任何本地策略设置。
另一个可能的解决方案是使用安全配置和分析工具 (mmc snap-in) 创建和应用安全模板。我认为这样做与简单地通过组策略定义基线配置设置相比没有优势，但如果您想将一致的模板应用于当地的许多机器的安全策略。
大多数管理员只会将具有已知良好安全配置的计算机提升为域控制器，因此您的问题并不常见。
对于审核，运行gpresult /h policy.html将生成一份 HTML 报告，其中列出所有有效的策略设置，包括组策略和本地策略的合并。因此，如果计算机修改了本地策略设置，并且没有组策略覆盖它，它会出现在那里：
从科技网：
通过本地策略或组策略对象应用的所有设置都存储在计算机上的本地数据库中。每当修改安全设置时，计算机都会将安全设置值保存到本地数据库，该数据库保留已应用于计算机的所有设置的历史记录。如果策略首先定义安全设置，然后不再定义该设置，则该设置将采用数据库中的先前值。如果数据库中不存在先前值，则该设置不会恢复为任何值，并保持原样定义。这种行为有时称为“纹身”。