继上文常见AD攻击及预防措施详解一这篇文章之后，我们继续介绍AD的攻击和预防措施的知识。
攻击四：基于过度创建AD对象的DoS攻击
具有管理员权限的用户过度创建新的对象会引发针对AD的拒绝服务（DoS）攻击。例如，授权用户不断创建AD对象，直到耗尽域控制器的磁盘空间，会导致AD服务器崩溃。另一个例子则是授权用户用一个命令将几千个成员添加到一个组中，同样会导致服务器崩溃。
攻击四预防措施
要预防这种攻击，必须对授予AD对象创建权限的人要特别小心。还可以采用在WindowsServer2003中的AD对象配额这个功能，而Windows2000里的对象配额功能有限。
AD对象配额会限定AD命名关联（NamingContext，NC）或根据特定安全项建立的目录分区中可以拥有的对象数量。每个ADNC和目录分区都可以独立设置和管理AD对象配额。不过，在SchemaNC中不能定义AD对象配额。对于每个ADNC和分区，可以定义默认的配额，如果没有特别定义，则配额没有限制。
对于安全项拥有的ADtombstone对象，也计入AD对象配额。tombstone对象是AD对象被删除时创建的临时对象，用于在AD的域控制器之间保持被删除对象数据的一致性。对于每个NC和分区，可以指定tombstone配额参数，确定tombstone对象在配额中的权重。例如，为NC或分区指定tombstone的配额参数是25，即分区中一个tombstone对象被计算为一个普通AD对象的0.25。默认的每个分区中tombstone配额参数是100，也就是说，一个tombstone对象和一个普通AD对象具有相同的权重。
对于每个安全项，都可以分配配额，包括用户、计算机、组和inetOrg-Person。一个安全项可以有多个配额，例如，用户可以被分配独立的配额，他所属的组又具有一个配额，在这种情况下，配额将采用最大的那个设置。域管理员组和企业管理员组成员没有AD对象配额限制。
AD对象配额保存在ADNC或分区的NTDSQuotas容器中，属于msDS-QuotaControl类的对象。在Accounting的域NC中设置用户Joe的AD对象配额为10，可以使用下列Dsadd命令：
- Dsaddquota
- -partDC=Accounting,DC=COM
- -acctAccounting\Joe
- -qlimit10
- -desc"QuotaforJoe"
设置Accounting域NC的tombstone配额参数为25，可以使用下列Dsmod命令：
- Dsmod
- partitionDC=Accounting,DC=COM
- -qtmbstnwt25
将Accounting域NC的默认对象配额设置为0，可以使用下列Dsmod命令：
- Dsmod
- partitionDC=Accounting,DC=COM
- -qdefault0
只有运行WindowsServer2003的域控制器可以强制配额，只能在发起目录操作时强制配额，而不能用于复制操作中。要想在AD域目录分区有效使用AD对象配额，域中所有的域控制器必须运行WindowsServer2003。而在AD配置分区使用AD对象配额，则森林中的所有域控制器都必须运行WindowsServer2003（例如，所有域和森林必须运行WindowsServer2003功能level2）。
AD对象配额功能本身和任何指定的功能级别并没有关系——在任何WindowsServer2003域控制器上都可以使用。如果定义了配额的WindowsServer2003域中有Windows2000域控制器，用户可以继续连接这些域控制器，同时受到配额的限制。
与WindowsServer2003AD的配额系统相比，Windows2000的配额功能十分有限。在Windows2000中，管理员可以限制某个用户帐号创建计算机帐号的数量，必须使用AD域对象中的ms-DS-MachineAccountQuota属性，这个限制并不适用于域管理员组和帐号操作员组的成员。WindowsServer2003支持ms-DS-MachineAccountQuota属性（默认值为10）。如果想禁止添加计算机帐号，可以将该属性值设置为0。
对于认证用户组来说，在用户权限中删除“向域中添加工作站”也可以达到同样的目的。在WindowsServer2003和Windows2000中，认证用户组默认具有该权限。
攻击五：基于MaxTokenSize属性的DoS攻击
微软扩展了基本的Kerberos协议，利用Kerberos认证ticket包含认证数据。WindowsKerberosticket和TicketGrantingTicket（TGT）都包含一个特殊的区域，称之为权限属性验证（PrivilegeAttributeCertificate，PAC），可以利用Kerberos协议传输认证数据，如在Kerberos认证ticket中的用户组成员和用户权限。
Kerberosticket具有固定的大小，间接限制了PAC的大小。如果用户属于很多的组（比如100个或更多），他的ticket大小可能会超出限制，Windows认证和组策略处理就会失败。因此具有AD创建和修改组权限的用户可以利用这个漏洞针对管理员帐号发起拒绝服务攻击（DoS），这种攻击将导致管理员帐号无法登录网络。
攻击五预防措施
为了预防这种攻击，必须相当仔细地为组管理委派AD管理权限，还必须限制管理管理员帐号组成员的权限。因为在森林中，管理员可以管理本地和全局组，添加任何用户帐号并不需要特殊的权限，所以在AD中限制默认权限很困难。因此，必须将企业管理员组或域管理员组的帐号放置在一个特殊的组织单元（OU）中，不给被委派的管理员读取的权限。
此外，可以设置注册表
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters\
MaxTokenSize的值增加Kerberosticket的最大尺寸，
可以参考微软知识库文章“解决用户属于多个组出现问题的新方法”（http://support.microsoft.com/kb/327825）。
对于用户使用Kerberos登录域的所有Windows系统，都需要修改MaxTokenSize（REG_DWORD）的值。在Windows2000中，MaxTokenSize的默认值是8000字节；在Windows2000SP2和后续版本以及WindowsServer2003中，MaxTokenSize的默认值为12000字节。
为了减少PAC的大小，微软在Window2000SP4中还采用了新的方法在PAC中存储认证数据。新的PAC认证数据存储方法如下：
如果是本地组或来自其它域，组的全部SID（例如S-1-5-21-1275210071-789336058-1957994488-3140）将保存在PAC中。
如果用户所属的全局组在用户所属的域的本地，则只存储组的相对识别号（RelativeIdentifier，RID）。
微软在Windows认证过程中采用特殊的处理过程，在客户端和服务器端将RID重新分解成SID格式。需要注意的是，即使采用新的PAC认证数据存储方法，仍然需要修改MaxTokenSize或减少用户所属组的数量。
为了避免Kerberostiket的PAC域的空间浪费，从WindowsNT4.0域迁移到WindowsServer2003域或Windows2000域时，应该删除AD帐号的SIDHistory属性，可以参见微软知识库文章“如何使用VisualBasic脚本清除SidHistory”（http://support.microsoft.com/kb/295758）。
微软发布了Tokensz工具，用于解决Kerberos令牌大小相关的问题，该工具可以从http://www.microsoft.com/downloads/details.aspx?familyid=4a303fa5-cf20-43fb-9483-0f0b0dae265c&displaylang=en下载。下列Tokensz命令列出了当前系统的MaxTokenSize值和当前的令牌大小：
- tokensz/compute_tokensize
- /package:negotiate
- /use_delegation
- /target_server:
关于如何使用Tokensz，可以参见微软的白皮书“解决Kerberos错误”（http://www.microsoft.com/downloads/details.aspx?familyid=7dfeb015-6043-47db-8238-dc7af89c93f1&displaylang=en）。
全方位较量
本文提到的这些攻击手段说明了采用多种措施保护AD架构的重要性。除了技术上的安全措施，还必须考虑物理上和组织上的安全措施。物理上的安全措施包括对Windows域控制器、网络设施和公司建筑物的物理安全访问；组织上的安全措施包括建立安全规则和操作步骤，定期对AD架构进行外部安全审计，不断培训管理员和用户的安全风险知识和操作实践。在公司内，保护AD的安全是一项重要的工作，应该列为高优先级，应该从技术上、物理上和组织上建立联合的团队共同完成。
希望系统管理员通过本文对AD的攻击和预防措施的介绍能够引起对AD安全的重视。
【编辑推荐】
