深入理解组策略一：组策略处理流程

概述：
    组策略是Win2003操作系统提供的一种重要的更新和配置管理技术，用来批量控制计算机和用户的环境，包括控制应用程序、系统设置和管理模板的一种机制。在AD域环境中，通过组策略可以对计算机和用户组进行高效集中化的管理。组策略是AD域环境最有吸引力的基础架构应用之一，正确高效组策略应用可以最大化提高工作效率，节约大量时间和精力。但如果部署了不正确的组策略，排错过程往往会使人抓狂。本文不涉及具体组策略部署方法以及如何排错案例，仅就AD域环境中客户机处理组策略的流程做一详细分析。相信正确理解和掌握组策略内部处理流程，会对组策略部署以及组策略排错有相当大的帮助和参考。

 

一：简述客户端计算机处理组策略流程
    简单的说，客户机应用组策略的流程有以下几个步骤：
       1：客户机启动，执行本地安全策略。
       2：客户机连接到网络，查询DC获取要应用的GPO列表。
       3：客户机根据GPO列表连接到Sysvol文件夹定位对应的组策略模板。
       4：客户机根据组策略模板中信息执行相应的操作。
       5：计算机策略执行完成后，出现登录界面，用户登录。
       6：用户验证通过后，用户查询DC获取要应用的GPO列表。下面执行步骤与计算机执行步骤类似。   

     客户机组策略处理基本流程如上所述，其中忽略了某些可能性如：环回设置，同步/异步处理，安全组筛选，WMI筛选等，因对基本流程影响不大，此处略过。有兴趣请见后续文章。
     上述流程并不复杂，但其中存在一些细节需要深入了解，也是自己当初学习组策略时一直存在的疑问。比如：
        1：客户机如何从DC上获取要应用的GPO列表
        2：客户机如何可以根据GPO列表，定位到Sysvol文件夹定位对应的组策略模板。

        3：客户机如何可以正确的处理每个组策略设置
        4：按MS说法,客户机与DC失去联系，客户机会使用本机缓存的组策略，那么组策略本地缓存保存在客户机什么位置？
    下面就上述疑问做尽可能的分析，希望能给其他朋友带来参考，因有些结论是实验测试结果，可能会存在某些不当之处，如有异议，欢迎讨论!

 

二：客户机如何获取应用的GPO列表
    我们知道,DC启动时，会向DNS宣告自己的角色，DNS服务器接受宣告后，更新DNS数据库中DC对应的资源记录。客户机登录时会联系DNS服务器，寻找适当的DC进行身份验证。验证通过后，DC告诉客户机所属的站点信息，域信息，以及OU信息。客户机获取到这些信息后，就可以查询到正确的GPO列表。之所以拥有站点，域，OU信息后就可以获取GPO列表信息，主要是因为站点，域和OU对象的gPlink属性中保存有GPO链接信息。
    获取GPO列表的顺序是从所属OU往上查找每一层存在的GPO对象，直至域级。然后再查找站点所链接的GPO对象，生成完整的GPO列表。
    考虑到组策略执行时处理顺序是：本地->站点->域->OU。与组策略生成GPO列表的顺序相反，所以猜想组策略GPO列表应该是一个栈结构，采取的是先进后出的执行原则。
    如果希望能对客户机获取组策略列表有一个感性认识，建议大家阅读userenv日志文件，该文件详细记载用户登录过程信息。
    要想查看完整的日志文件，需要先激活userenv日志完整模式。方法是：
    打开注册表编辑器，定位至HKEY_LOCAL_MACHINE\Software\ Microsoft\Windows NT\ CurrentVersion\Winlogon。
    新建dword值:UserEnvDebugLevel，数据为10002 (Windows 2000/XP)，Windows 2003改为30002。
    重新启动后在%SystemRoot%\Debug\UserMode\下可找到Userenv.log 文件。重点观察与GPO相关的各条记录。
   
三：客户机如何根据GPO列表，定位到sysvol文件夹并查找对应的组策略模板文件
    客户机获取到GPO列表后，接下来就需要根据每个GPO信息，定位到DC中的sysvol文件夹，查找对应的组策略模板文件。
    在了解如何正确定位和查找到对应的组策略模板文件之前，有必要解释一下几个相关概念。
    1：组策略对象GPO
       在组策略编辑器中生成一个组策略后，就会对应生成一个组策略对象GPO。
       但GPO是域中一个虚拟对象，在AD数据库中并不存在真实的GPO对象。实际上，GPO对象由两部分组成,分别是保存在AD数据库中组策略容器GPC和保存在Sysvol共享文件夹中的对象组策略模板GPT。
       两者之间通过组策略对象的GUID保持关联,并且GPC通过AD复制引擎复制到当前域的所有DC中，而GPT则是通过文件复制服务(FRS)复制到当前域的所有DC中。基本结构如下图：

    

      注：因为AD复制与FRS复制机制不同，导致存在GPT与GPC可能不一致的可能性。

 

    2：组策略模板GPT
       GPT是实现了一系列组策略设置的指令集，包含具体组策略的相关设置参数。
           大多数GPT都采用文件形式，存放在sysvol共享文件夹中，以便于客户端下载和处理。 除软件部署使用的是二进制.aas文件外，其它GPT文件都是简单的文本文件，客户端下载GPT文件后，按照文件指令进行相应的操作和设置。GPT的版本号存储在Gpt.ini文件中，用于与GPC保持同步。

 

    3：组策略容器GPC
       GPC是一个目录服务对象，主要包含有如下重要属性：
          versionNumber：版本号属性的主要目的是为了确保GPC与GPT信息保持同步。
          gPCFileSysPath：提供客户端查找和定位对应组策略模板文件的路径。
          gPCMachineExtensionNames：指定客户端处理计算机策略GPT文件时需要使用的客户端扩展的ClassID。
          gPCUserExtensionNames：指定客户端处理用户策略GPT文件时需要使用的客户端扩展的ClassID
          gPCWQLFilter：指定应用于组策略对象的任何WMI筛选器。
       GPC对象存储在AD数据库Domain分区中，可以通过AdsiEdit或LDP工具查看某个GPC对象属性，增加感性认识。LDP工具查看到的属性如下图

 

    理解了上述三个概念后，很容易理解为什么客户机可以根据GPO列表，定位到sysvol文件夹并查找对应的组策略模板文件：
    GPC与GPT之间由GPO的GUID保持关联，由GPC的gPCFileSysPath记载对应组策略模板具体位置，指示客户机下载组策略模板文件!
 
四：客户机如何正确处理每个组策略设置
    客户机根据GPO列表，查找到对应的组策略模板信息，通过比较缓存的GPO版本号与GPT中版本号，确定该组策略是否已经更新，如果组策略已经更新，下载GPT文件，并执行相应的操作和设置。客户机之所以可以正确执行组策略指令集，是由于在客户机系统中有客户端扩展的存在。
    在Windows系统共有11种功能可以由组策略来管理，每个功能都有一个相应的服务在客户端运行，服务负责处理相应的组策略。
    这些服务称之为CSE(客户端扩展)，每个CSE都作为动态链接库dll的方式存在，在客户机启动时，由winlogon服务动态加载。
    详细的每个功能和对应的CSE扩展如下图：

 

    可以在客户机注册表中查看详细的客户端扩展列表，具体注册表位置在：
   HKLM\Software\Microsoft\WindowsNT\CurrentVersion\Winlogon\GPExtensions。

         

 

     列表中每一项代表一个具体的服务，以ClassID来标识，与GPC中gPCMachineExtensionNames/gPCUserExtensionNames保持一致。
     客户机执行某一个GPO时，由GPC的gPCMachineExtensionNames/gPCUserExtensionNames属性定位出该组策略具体由哪一个CSE来执行。每个CSE扩展知道如何正确处理所对应的组策略设置。

 

五：了解缓存登录的客户机组策略设置
    上述几个步骤把正常情况下客户机处理组策略流程做了分析，现在我们考虑一个特殊情况：当客户机联系不上DC时，组策略如何处理？
    MS给出的说法是客户机上保存有组策略缓存，客户机联系不上DC，客户机使用域帐号登录系统，会使用组策略缓存继续处理，
    也就是已经执行的组策略继续有效。那么组策略缓存保存在客户机什么位置呢，结论是缓存在注册表中，并不存在一个实际的缓存文件。
    可以通过一个具体的实验来测试缓存文件存在与否，测试方案如下：
    1：在GPMC中新建一个禁止修改网络属性的组策略，并链接给测试域帐号所在OU。禁止修改网络属性的设置如下：

       

      2：配置测试域用户在客户机为管理员级别，在能联系DC情况下域用户在客户机正确登录，无法修改网络属性。

        

 

      3：断开客户机网络，重启客户机，通过缓存登录后，还是无法修改网络属性，与上图情况相同。
         此时我们查看当前客户机注册表中的的组策略缓存设置情况，具体位置在：
         HKCU\Software\Policies\Microsoft\Windows\Network Connetions。

        

 

           手动将上图中各个值为0的键值修改为1，再次重启客户机，此时仍然在联系不上DC，但却可以修改网络属性。

          

 

 

           通过这个实验，可以得知在客户机中并不存在实际的组策略缓存文件，因为如果存在某个组策略缓存文件，那么在客户机修改注册表重启过程中，会重新加载该组策略缓存信息，从而覆盖修改后的注册表情况。如同DC在线时客户机执行组策略会覆盖修改的注册表信息一样。

        但实验证明类似情况没发生，从而可以测试出组策略缓存实际上就保存在注册表上述路径中。同时也得出当DC不在线时，有权限用户可以通过修改注册表实现取消组策略设置的管理和控制。

 

六：参考资料
    本文对组策略处理流程进行了稍深入的分析，通过了解组策略流程，我们可以看到，组策略正确处理依赖于多个因素，如DNS，AD数据，AD复制与FRS复制，还包括安全性设置以及sysvol文件夹目录权限以及客户端扩展等。当组策略不能正确执行时，可以从上述因素中查找与定位原因。
    参考资料：[url]http://technet.microsoft.com/en-us/library/cc779838.aspx[/url]

本文出自 “我儿子真帅!” 博客，转载请与作者联系！