admin 管理员组

文章数量: 887021

域控

文章目录

    • 一. 域环境搭建
      • 1.1 添加AD功能
      • 1.2 安装
      • 1.3 部署
    • 二. 如何加入域
      • 2.1 加入域
      • 2.2 域中主机登录
      • 2.3 退出域
      • 2.4 添加域用户
    • 三. 域权限
      • 3.1 A-G-DL-P策略
      • 3.2 组
        • 几个比较重要的域本地组
        • 几个比较重要的全局组、通用组的权限
    • 四. 域管理
      • 4.1 域用户账户的管理
      • 4.2 组的管理
      • 4.3 组的作用域
      • 4.4 组织单位OU的管理
      • 4.5 容器与组织单位
      • 4.6 默认的容器和单位组织
      • 4.7 添加额外域控制器（BDC）
      • 4.8 组策略应用
    • 五. Kerberso 协议
      • 5.1 组件
      • 5.2 认证流程
      • 5.3 详细过程
        • AS_REQ & AS_REP
        • TGS_REQ & TGS_REP
        • AP-REQ & AP-REP
        • PAC
      • 5.4 Kerberos 认证中的相关安全问题
        • 黄金票据
        • 白银票据
        • MS14-068
        • 密码喷洒攻击（Password Spraying）
        • AS-REP Roasting

一. 域环境搭建

基于winserver16搭建域环境

1.1 添加AD功能

服务器角色选择“Active Directory域服务”，会弹出“添加Active Directory域服务所需的功能？”，点击“添加功能”


服务器角色选择“Active Directory域服务”之后，点击“下一步”

下一步

1.2 安装

等待安装

1.3 部署

winserver08 运行dcpromo部署，winserver16在 AD DS中部署

添加新林，输入根域名

下一步

完成 AD 部署

在计算机成为域控后，该主机上之前的账号将全部变为域账号，这些账号将不能以本地登录方式登录。成为域控之后新建的用户，必须满足密码规则。如果成为域控后新建的用户不属于administrators组，则这些用户可以登录除域控外的其他域内主机。域控只允许administrators组内的用户以域身份登录，域控不能以本地身份登录。

域控中administrator组内的用户都是域管理员

二. 如何加入域

2.1 加入域

将主机的DNS指向域控服务器的ip，并且确保两者之间能通

输入账户名/密码 等待加入


当计算机加入域后，系统会自动将域管理员组添加到本地系统管理员组中

2.2 域中主机登录

以本地用户登录，通过SAM来进行NTLM认证

以域中用户登录，域名\用户名 或者 用户名@域名，该方式通过Kerberos协议认证

域控上的所有用户均可以登录域中的任意一台主机(域控除外，默认情况下域控只允许域内的Administrator用户才能登陆)，而域中的普通主机上的用户只能以本地身份登录该主机

2.3 退出域

计算机要么是工作组计算机，要么是域中的计算机，不能同时属于域和工作组，如果将计算机加入到工作组，计算机将自动从域中退出。退出时需要输入域管理员账号和密码。

2.4 添加域用户

在域控上添加的用户都是域用户。如果想在其他域成员主机上添加域用户，需要在域成员主机上以域管理员权限登录，然后执行以下命令添加域用户

net user wp 123456 /add /domain            #添加域用户wp，密码为 123456
net group "domain admins" wp /add /domain  #将域用户wp添加到域管理员组domain admins中

三. 域权限

3.1 A-G-DL-P策略

  • A（account）：用户账户
  • G（Global group）：全局组
  • U（Universal group）：通用组
  • DL（Domain local group）：域本地组
  • P（Permission 许可）：资源权限

A-G-DL-P策略是将用户账号添加到全局组中，将全局组添加到域本地组中，然后为域本地组分配资源权限。按照AGDLP的原则对用户进行组织和管理起来更容易。
在AGDLP形成以后,当给一个用户某一个权限的时候,只要把这个用户加入到某一个本地域组就可以了。

3.2 组

几个比较重要的域本地组

  • 管理员组(Administrators)：该组的成员可以不受限制地存取计算机/域内的资源。它不仅是最具权利的一个组，也是在活动目录和域控制器中默认具有管理员权限的组。该组的成员可以更改 Enterprise Admins、Schema Admins 和 Domain Admins 组的成员关系，是域森林中年强大的服务管理组。

  • 远程登录组(Remote Desktop Users)：该组的成员具有远程登录权限。

  • 打印机操作员组(Print Operators)：该组的成员可以管理网络打印机，包括建立，管理及删除网络打印机，并可以在本地登录和关闭域控制器。

  • 账号操作员组(Account Operators)：该组的成员可以创建和管理该域中的用户和组并为其设置权限，也可以在本地登录域控制器。但是，不能更改属于Administrators或Domain Admins组的账号，也不能更改这些组。在默认情况下，该组中没有成员。

  • 服务器操作员组(Server Operators)：该组的成员可以管理域服务器，其权限包括建立、管理、删除任意服务器的共享目录、管理网络打印机、备份任何服务器的文件、格式化服务器硬盘、锁定服务器、变更服务器的系统时间、关闭域控制器等。在默认情况下，该组中没有成员。

  • 备份操作员组(Backup Operators)：该组的成员可以在域控制器中执行备份和还原操作，并可以在本地登录和关闭域控制器。在默认情况下，该组中没有成员。

几个比较重要的全局组、通用组的权限

  • 域管理员组(Domain Admins)：该组的成员在所有加入域的服务器、域控制器和活动目录中均默认拥有完整的管理员权限。因为该组会被添加到自己所在域的Administrators组中，因为可以继承Administrators组的所有权限。同时，该组默认会被添加到每台域成员计算机的本地Administrators组中。这样，Domain Admins组就获得了域中所有计算机的所有权。如果希望某用户成为域系统管理员，建议将该用户添加到Domain Admins组中，而不要直接将该用户添加到Administrators组中。

  • 企业系统管理员组(Enterprise Admins)：该组是域森林根域中的一个组。该组在域森林中的每个域内都是Administrators组的成员，因此对所有域控制器都有完全访问权。

  • 域用户组(Domain Users)：该组是所有的域成员，在默认情况下，任何由我们建立的用户账号都属于Domain Users组，而任何由我们建立的计算机账号都属于Domain Computers组。因此，如果想让所有的账号都获得某种资源存取权限，可以将该权限指定给域用户组，或者让域用户组属于具有该权限的组。域用户组默认是内置域Users组的成员。

  • 架构管理员组(Schema Admins)：该组是域森林根域中的一个组，可以修改活动目录和域森林的模式。该组是为活动目录和域控制器提供完整权限的域用户组，因此，该组成员的资格是非常重要的。

四. 域管理

4.1 域用户账户的管理

  • 创建域用户的账户
  • 配置域用户账户属性
  • 验证用户的身份
  • 授权或拒绝对域资源的访问

4.2 组的管理

组分为安全组和通讯组

  • 安全组：安全组有安全表示（SID），能够给其授权访问本地资源或网络资源。即能授权访问资源，也可以利用其群发电子邮件

  • 通讯组：通迅组没有安全标识（SID），不能授权其访问资源，只能用来群发电子邮件

4.3 组的作用域

组是账户的集合，通过对组分配权限实现对组内用户的权限分配

域本地组，多域用户访问单域资源。可以从任何域添加用户账户、通用组和全局组，只能在其所在域内指派权限。域本地组不能嵌套于其他组中。它主要是用于授予位于本域资源的访问权限。

全局组，单域用户访问多域资源（必须是同一个域里面的用户）。只能在创建该全局组的域上进行添加用户和全局组，可以在域林中的任何域中指派权限，全局组可以嵌套在其他组中。

通用组，通用组成员来自域林中任何域中的用户账户、全局组和其他的通用组，可以在该域林中的任何域中指派权限，可以嵌套于其他域组中。非常适于域林中的跨域访问。

简单理解

  • 域本地组：来自全林用于本域
  • 全局组：来自本域用于全林
  • 通用组：来自全林用于全林

4.4 组织单位OU的管理

  • OU概念
    OU是AD中的容器，可在其中存放用户、组、计算机和其他OU，而且可以设置组策略
  • OU应用
    基于部门，如行政部、人事部；基于地理位置，如北京、上海；基于对象，如用户、计算机

4.5 容器与组织单位

  • 容器（Container）与对象相似，它有自己的名称，也是一些属性的集合，不过容器内可以包含其他对象（例如用户、计算机等对象)，还可以包含其他容器。
  • 组织单位（Organization Units，OU)是一个比较特殊的容器，其中除了可以包含其他对象与组织单位之外，还有组策略（Group Policy）的功能。

4.6 默认的容器和单位组织

  • Builtin容器：Builtin容器是Active Driectory默认创建的第一个容器，主要用于保存域中本地安全组。

  • Computers容器：Computers容器是Active Driectory默认创建的第2个容器，用于存放Windows Server 域内所有成员计算机的计算机账号。

  • Domain Controllers组织单位：Domain Controllers是一个特殊的容器，主要用于保存当前域控制器下创建的所有子域和辅助域。

  • Users容器：Users容器主要用于保存安装Active Driectory时系统自动创建的用户和登录到当前域控制器的所有用户账户。

4.7 添加额外域控制器（BDC）

在一个域中，一般域控服务器至少有2个或者以上。所以，我们得添加额外的域控服务器。在任何一台域控制器上都可以修改AD中的内容，每台域控制器上AD中的内容都是同步的

添加额外域控制器的条件：

  1. 具有域管理权限
  2. 计算机TCP/IP，DNS服务配置正确
  3. 操作系统版本支持

添加额外域控制器的步骤：

  1. 查看当前域功能级别
  2. 将计算机加入当前域
  3. 运行dcpromo命令安装活动目录

4.8 组策略应用

计算机配置成域控服务器后，或计算机加入一个域后，会发现本地的安全策略已经呈灰色的，配置不了了。在一个域中，通过在域控服务器上配置组策略，来对域中的主机或域中的用户去设置策略

组策略功能

  • 账户策略设置
  • 本地策略设置
  • 脚本设置
  • 用户工作环境的设置
  • 软件的安装与删除
  • 限制软件运行
  • 文件夹的重定向
  • 限制访问可移动设备

组策略优点
减小管理成本，只需设置一次，相应的计算机或用户即可应用，减小用户单独配置错误的可能性，可以针对特定对象设置特定的策略

组策略对象

  • GPO（Group Policy Object）的概念：存储组策略的所有配置信息，AD中的一种特殊对象
  • 默认GPO：默认域策略，默认域控制器策略
  • GPO链接：只能链接到站点，域，OU

组策略应用规则

  • 策略继承与阻止：下级容器可以继承或阻止应用其上级容器的GPO设置
  • 策略累加与冲突：多个GPO设置可以累加或发生冲突被覆盖
  • 策略强制生效：使下级容器强制执行其上级容器的GPO设置
  • 筛选：阻止一个容器内的用户或计算机应用其GPO设置

策略继承与阻止

下级容器默认会继承来自上级容器的GPO ，子容器可以阻止继承上级容器的GPO ，右击容器→阻止继承

策略累加与冲突
如果多个组策略设置不冲突，则最终的有效策略是所有组策略设置的累加 如果多个组策略设置冲突，则后应用的组策略覆盖先应用的组策略

组策略应用顺序

  • 首先应用本地组策略
  • 如果有站点组策略，则应用
  • 接着应用域策略
  • 最后应用OU上的策略
  • 如果同一个OU上链接了多个GPO，则按照链接顺序从高到低逐个应用

策略强制生效
强制生效是上级容器强制下级容器执行其GPO设置

筛选
筛选可以阻止一个GPO应用于容器内的特定计算机或用户 委派→权限设置

五. Kerberso 协议

Kerberso 协议是一种计算机网络授权协议，用于在非网络安全中，对个人通信以安全手段进行身份认证。其设计目标是通过密钥系统为客户机与服务器之间提供认证服务。该协议认证无需基于主机地址的信任，不要求网络上的物理安全，并假定网络中的数据包有被篡改读取的情况下，作为一种可信任三方认证服务。
通过传统密码技术（如：共享密钥）执行认证服务。Kerberos 协议在在内网域渗透领域中至关重要，白银票据、黄金票据、攻击域控等都离不开 Kerberos 协议。

5.1 组件

角色作用
Domain Controller（DC）域控制器，简称DC
Key Distribution Center（KDC）密钥分发中心，简称KDC，默认安装在域控里，包括AS 和 TGS
Authentication Service（AS）身份验证服务，简称AS，用于 KDC 对 Client 认证，TGT由AS发放
Ticket Grantng Service（TGS）票据授予服务，简称TGS，用于 KDC 向 Client 和 Service 分发Session Key（临时密钥）和Service Ticket（ST）发放
Active Directory（AD）活动目录，简称AD，用户存放用户，用户组相关信息
Client客户端
Server服务端

5.2 认证流程

.html

  1. 客户端向域控制器DC请求访问 Server，AS 通过去AD活动目录中查找客户端，来判断客户端是否可信。
  2. AS 认证通过后返回 TGT 给 客户端
  3. 客户端得到 TGT 后继续请求TGS 访问 Server，TGS通过客户端提交的 TGT 判断此客户端是否有访问权限
  4. 如果有，就给客户端访问Server权限的 Ticket，也叫ST（Service Ticket）
  5. 客户端得到 ST 后，再去访问 Server，且该 ST只针对这一个Server有效
  6. 最终Server和Client建立通信。

5.3 详细过程

认证过程大致分为三个阶段：

  • AS_REQ & AS_REP
  • TGS_REQ & TGS_REP
  • AP-REQ & AP-REP

AS_REQ & AS_REP

该阶段是 Client 和 AS 的认证，通过认证的客户端获得 TGT

当域内某个客户端用户 Client 试图访问域内的某个服务，于是输入用户名和密码，此时客户端本机的 Kerberos 服务会向 KDC 的 AS 认证服务发送一个AS_REQ认证请求。请求的凭据是 Client 的哈希值 NTLM-Hash 加密的时间戳以及 Client-info、Server-info 等数据，以及一些其他信息。

当 Client 发送身份信息给 AS 后，AS 会先向活动目录 AD 请求，询问是否有此 Client 用户，如果有的话，就会取出它的 NTLM-Hash，并对AS_REQ请求中加密的时间戳进行解密，如果解密成功，则证明客户端提供的密码正确，如果时间戳在五分钟之内，则预认证成功。然后 AS 会生成一个临时秘钥 Session-Key AS，并使用客户端 Client 的 NTLM-Hash 加密 Session-key AS 作为响应包的一部分内容。此 Session-key AS 用于确保客户端和 KGS 之间的通信安全。

还有一部分内容就是 TGT：使用 KDC 一个特定账户的 NTLM-Hash 对 Session-key AS、时间戳、Client-info 进行的加密。这个特定账户就是创建域控时自动生成的 Krbtgt 用户，然后将这两部分以及 PAC 等信息回复给 Client，即AS_REP。PAC 中包含的是用户的 SID、用户所在的组等一些信息。

AS-REP 中最核心的东西就是 Session-key 和 TGT。我们平时用 Mimikatz、kekeo、rubeus 等工具生成的凭据是 .kirbi 后缀，Impacket 生成的凭据的后缀是 .ccache。这两种票据主要包含的都是 Session-key 和 TGT，因此可以相互转化。

至此，Kerberos 认证的第一步完成。

TGS_REQ & TGS_REP

该阶段是 Client 和 TGS 的认证，通过认证的客户端将获得 ST 服务票据。


客户端 Client 收到 AS 的回复AS_REP后分别获得了 TGT 和加密的 Session-Key AS。它会先用自己的 Client NTLM-hash 解密得到原始的 Session-Key AS，然后它会在本地缓存此 TGT 和原始的 Session-Key AS，如果现在它就需要访问某台服务器上的服务，他就需要凭借这张 TGT 认购凭证向 KGS 购买相应的 ST 服务票据（也叫Ticket）。

此时 Client 会使用 Session-Key AS 加密时间戳、Client-info、Server-info 等数据作为一部分。由于 TGT 是用 Krbtgt 账户的 NTLM-Hash 加密的，Client 无法解密，所以 Client 会将 TGT 作为另一部分继续发送给 TGS。两部分组成的请求被称为TGS_REQ。

TGS 收到该请求，用 Krbtgt 用户的 NTLM-hash 先解密 TGT 得到 Session-key AS、时间戳、Client-info 以及 Server-info。再用 Session-key AS 解密第一部分内容，得到 Client-info、时间戳。然后将两部分获取到时间戳进行比较，如果时间戳跟当前时间相差太久，就需要重新认证。TGS 还会将这个 Client 的信息与 TGT 中的 Client 信息进行比较，如果两个相等的话，还会继续判断 Client 有没有权限访问 Server，如果都没有问题，认证成功。认证成功后，KGS 会生成一个 Session-key TGS，并用 Session-key AS 加密 Session-key TGS 作为响应的一部分。此 Session-key TGS 用于确保客户端和服务器之间的通信安全。

另一部分是使用服务器 Server 的 NTLM-Hash 加密 Session-key TGS、时间戳以及 Client-info 等数据生成的 ST。然后 TGS 将这两部分信息回复给 Client，即TGS_REP。

至此，Client 和 KDC 的通信就结束了，然后是和 Server 进行通信。

AP-REQ & AP-REP

该阶段是 Client 和 TGS 的认证，通过认证的客户端将与服务器建立连接。

客户端 Client 收到TGS_REP后，分别获得了 ST 和加密的 Session-Key TGS。它会先使用本地缓存了的 Session-key AS 解密出了原始的 Session-key TGS。然后它会在本地缓存此 ST 和原始的 Session-Key TGS，当客户端需要访问某台服务器上的服务时会向服务器发送请求。它会使用 Session-key TGS 加密 Client-info、时间戳等信息作为一部分内容。ST 因为使用的是 Server NTLM-hash 进行的加密，无法解密，所以会原封不动发送给 Server。两部分一块发送给 Server，这个请求即是AP_REQ。

Server 收到AP_REQ请求后，用自身的 Server NTLM-Hash 解密了 ST，得到 Session-Key TGS，再解密出Client-info、时间戳等数据。然后与 ST 的Client-info、时间戳等进行一一对比。时间戳有效时间一般时间为8小时。通过客户端身份验证后，服务器 Server 会拿着 PAC 去询问 DC 该用户是否有访问权限，DC 拿到 PAC 后进行解密，然后通过 PAC 中的 SID 判断用户的用户组信息、用户权限等信息，然后将结果返回给服务端，服务端再将此信息域用户请求的服务资源的 ACL 进行对比，最后决定是否给用户提供相关的服务。通过认证后 Server 将返回最终的AP-REP并与 Client 建立通信。

至此，Kerberos 认证流程基本结束。

PAC

我们在前面关于 Kerberos 认证流程的介绍中提到了 PAC（Privilege Attribute Certificate）这个东西，这是微软为了访问控制而引进的一个扩展，即特权访问证书。

在上面的认证流程中，如果没有 PAC 的访问控制作用的话，只要用户的身份验证正确，那么就可以拿到 TGT，有了 TGT，就可以拿到 ST，有了 ST ，就可以访问服务了。此时任何一个经过身份验证的用户都可以访问任何服务。像这样的认证只解决了 “Who am i?” 的问题，而没有解决 “What can I do?” 的问题。

为了解决上面的这个问题，微软引进了PAC。即 KDC 向客户端 Client 返回AS_REP时插入了 PAC，PAC 中包含的是用户的 SID、用户所在的组等一些信息。当最后服务端 Server 收到 Client 发来的AP_REQ请求后，首先会对客户端身份验证。通过客户端身份验证后，服务器 Server 会拿着 PAC 去询问 DC 该用户是否有访问权限，DC 拿到 PAC 后进行解密，然后通过 PAC 中的 SID 判断用户的用户组信息、用户权限等信息，然后将结果返回给服务端，服务端再将此信息域用户请求的服务资源的 ACL 进行对比，最后决定是否给用户提供相关的服务。

但是在有些服务中并没有验证 PAC 这一步，这也是白银票据能成功的前提，因为就算拥有用户的 Hash，可以伪造 TGS，但是也不能制作 PAC，PAC 当然也验证不成功，但是有些服务不去验证 PAC，这是白银票据成功的前提。

5.4 Kerberos 认证中的相关安全问题

黄金票据

在 Windows 的kerberos认证过程中，Client 将自己的信息发送给 KDC，然后 KDC 使用 Krbtgt 用户的 NTLM-Hash 作为密钥进行加密，生成 TGT。那么如果获取到了 Krbtgt 的 NTLM-Hash 值，不就可以伪造任意的 TGT 了吗。因为 Krbtgt 只有域控制器上面才有，所以使用黄金凭据意味着你之前拿到过域控制器的权限，黄金凭据可以理解为一个后门。

先假设这么一种情况，原先已拿到的域内所有的账户 Hash，包括 Krbtgt 这个账户，由于有些原因导致你对域管权限丢失，但好在你还有一个普通域用户权限，碰巧管理员在域内加固时忘记重置 Krbtgt 密码，基于此条件，我们还能利用该票据重新获得域管理员权限。利用 Krbtgt 的 Hash 值可以伪造生成任意的 TGT，能够绕过对任意用户的账号策略，让用户成为任意组的成员，可用于 Kerberos 认证的任何服务。

白银票据

白银票据不同于黄金票据，白银票据的利用过程是伪造 TGS，通过已知的授权服务密码生成一张可以访问该服务的 TGT。因为在票据生成过程中不需要使用 KDC，所以可以绕过域控制器，很少留下日志。而黄金票据在利用过程中由 KDC 颁发 TGT，并且在生成伪造的 TGT 得 20 分钟内，TGS不会对该 TGT 的真伪进行效验。

白银票据依赖于服务账号的密码散列值，这不同于黄金票据利用需要使用 Krbtgt 账号的密码哈希值，因此更加隐蔽。

MS14-068

这里便用到了我们之前所讲到的 PAC 这个东西，PAC 是用来验证 Client 的访问权限的，它会被放在 TGT 里发送给 Client，然后由 Client 发送给 TGS。但也恰恰是这个 PAC 造成了MS14-068这个漏洞。

该漏洞是位于 kdcsvc.dll 域控制器的密钥分发中心（KDC）服务中的 Windows 漏洞，它允许经过身份验证的用户在其获得的票证 TGT 中插入任意的 PAC 。普通用户可以通过呈现具有改变了 PAC 的 TGT 来伪造票据获得管理员权限。

密码喷洒攻击（Password Spraying）

在实际渗透中，许多渗透测试人员和攻击者通常都会使用一种被称为 “密码喷洒”（Password Spraying）的技术来进行测试和攻击。对密码进行喷洒式的攻击，这个叫法很形象，因为它属于自动化密码猜测的一种。这种针对所有用户的自动密码猜测通常是为了避免帐户被锁定，因为针对同一个用户的连续密码猜测会导致帐户被锁定。所以只有对所有用户同时执行特定的密码登录尝试，才能增加破解的概率，消除帐户被锁定的概率。普通的爆破就是用户名固定，爆破密码，但是密码喷洒，是用固定的密码去跑用户名。

AS-REP Roasting

我们前文说过，AS_REQ & AS_REP 认证的过程是 Kerberos 身份认证的第一步，该过程又被称为预身份验证。预身份验证主要是为了防止密码脱机爆破。

而如果域用户设置了选项 “Do not require Kerberos preauthentication”（该选项默认没有开启）关闭了预身份验证的话，攻击者可以使用指定的用户去请求票据，向域控制器发送AS_REQ请求，此时域控会不作任何验证便将 TGT 票据和加密的 Session-key 等信息返回。因此攻击者就可以对获取到的加密 Session-key 进行离线破解，如果爆破成功，就能得到该指定用户的明文密码。

这种攻击方式被称作 AS-REP Roasting 攻击。

本文标签： 域控

版权声明：本文标题：域控 内容由网友自发贡献，该文观点仅代表作者本人， 转载请联系作者并注明出处：http://www.freenas.com.cn/jishu/1688108848h180263.html， 本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，一经查实，本站将立刻删除。