Windows域认证（笔记）

标签：TGS CLIENT Windows 笔记认证 Client 密钥 Server

Windows 的认证包括三个部分：

本地认证：用户直接操作计算机登录账户
网络认证：远程连接到工作组中的某个设备
域认证：登陆到域环境中的某个设备

域内认证即采用了 Kerberos 协议的认证机制，与前两者相比最大的区别是有一个可信的第三方机构 KDC 的参与

活动目录

活动目录：Active Diretory，AD，是指域环境中提供目录服务的组件。目录用于存储有关网络对象(例如用户、组、共享资源计算机、、打印机和联系人等)的信息。能够快速、准确的从目录中找到其所需的信息的服务，为企业提供了网络环境集中式管理的机制。活动目录主要的功能：

账号集中管理：所有的账户都存储在服务器中，可以方便快捷的执行命令和管理密码等。

软件集中管理：能够统一推送软件，安装网络打印机等服务器
环境集中管理：统一客户端桌面、IE等
增强安全性：统一部署杀软，统一执行病毒扫描任务、集中管理用户的计算机权限，统一指定密码策略。

更加的可靠更短的宕机时间在域中，网络对象可以相互访问，但是在真实情况中，需要对某些部门的计算机进行限制，例如：销售部门不能访问技术部门的服务器。这个中间就需要 Kerberos 认证协议来验证网络对象间的权限。

Kerberos协议简介

Kerberos 是一种网络认证协议，其设计目标是通过密钥系统为客户机/服务器应用程序提供强大的认证服务。
该认证过程的实现不依赖于主机操作系统的认证，无需基于主机地址的信任，不要求网络上所有主机的物理安全，并假定网络上传送的数据包可以被任意地读取、修改和插入数据。
在以上情况下， Kerberos 作为一种可信任的第三方认证服务，是通过传统的密码技术(如:共享密钥)执行认证服务的。

参与域认证的三个角色：

访问服务的Client（用户）
提供服务的Server（服务）
KDC(Key Distribution Center)密钥分发中心

在Kerberos中Client是否有权限访问Server端的服务由KDC发放的票据来决定。

Kerberos认证协议基础

票据(Ticket):

是网络对象互相访问的凭证。

AD(Account Database):

存储域中所有用户的用户名和对应的 NTLM Hash ，可以理解为域中的 SAM 数据库， KDC可以从AD中提取域中所有用户的 NTLM Hash ，这是 Kerberos 协议能够成功实现的基础。

KDC(Key Distribution Center):

密钥分发中心，负责管理票据、认证票据、分发票据，里面包含两个服务： AS 和 TGSKDC(Key Distribution Center) = DC(Domain Controller) = AD（Account Database）+AS（Authenication Service）+ TGS（Ticket Granting Service）从物理层面看，AD 与 AS，TGS，KDC均为域控制器(Domain Controller)

AS(Authentication Server):

身份认证服务，为 Client 生成 TGT 的服务，也用来完成对 Client 的身份验证

TGS(Ticket Granting Server):

票据授予服务,为 Client 生成允许对某个服务访问的 ticket ，就是Client从AS那里拿到TGT之后，来TGS这里再申请对某个特定服务或服务器访问的Ticket，只有获取到这个Ticket，Client才有权限去访问对应的服务，该服务提供的票据也称为 TGS 或者叫白银票据

TGT(Ticket Granting Ticket):

看英文名就知道，用来生成 Ticket 的 Ticket ，由身份认证服务授予的票据(黄金票据)，用于身份认证，存储在内存，默认有效期为10小时

注意：
Client 密钥、 TGS 密钥和 Service 密钥均为对应用户的 NTLM Hash

TGS 密钥 == KDC Hash == krbtgt 用户的 NTLM Hash

Server 和 Service 可以当作一个东西，就是 Client 想要访问的服务器或者服务

Client/(TGS/Server) Sessionkey 可以看作客户端与 TGS 服务和尝试登陆的Server 之间会话时用来加密的密钥，而 (Client/TGS/Service) 密钥(上面提到的三个实际为 NTLM Hash 的密钥)是用来加密会话密钥的密钥，为了保证会话密钥的传输安全，这些加密方式均为对称加密

参与认证的三个角色的 NTLM Hash 是三个密钥，这三个 NTLM Hash 的唯一作用是确保会话密钥 Sessionkey 的安全传输

Kerbreros认证流程

Client向KDC发起服务请求，希望获取访问Server的权限。 KDC得到了这个消息，首先得判断Client是否是可信赖的，也就是从AD数据库中寻找该用户是否可用来登录。这就是AS服务完成的工作，成功后，AS返回TGT给Client。

Client得到了TGT后，继续向KDC请求，希望获取访问Server的权限。KDC又得到了这个消息，这时候通过Client 消息中的TGT，判断出了Client拥有了这个权限，给了Client访问Server的权限Ticket。（TGS服务的任务）

Client得到Ticket后便可以使用这个Ticket成功访问Server。但是这个Ticket只能用来访问这个Server，如果要访问其他Server需要向KDC重新申请。

1. 用户登录

用户输入 [用户名] 和 [密码] 信息
在客户端，用户输入的 [密码] 通过计算生成 NTLM 哈希作做为 [CLIENT密钥]

2. 请求身份认证

2.1 客户端向AS(身份认证服务)发送认证请求

客户端向AS发送认证请求，请求中带有明文的 [用户名] 信息（此时并未发送[密码]或[密钥]信息）

2.2 AS确认Client端登录者用户身份

1. AS 收到用户认证请求之后，根据请求中的用户名信息，从数据库中查找该用户名是否存在。

2. 如果用户名存在，则根据该用户名提取 NTLM Hash 做为AS生成的 CLIENT 密钥，如果第1步中用户提供的密码信息正确，该秘钥与用户登录中的 CLIENT密钥是相等的。

3. AS为Client响应如下消息：

Msg A 使用 KDC 生成的 CLIENT 密钥加密的 CLIENT/TGS SESSIONKEY
Msg B 使用 TGS 密钥加密的 TGT(TICKET-GRANTING-TICKET) ，客户端没有KDC NTLM Hash 因此 Client 无法解密 TGT 。
TGT中包含如下信息：
1.[Client/TGS SessionKey]
2.Client ID
3.Ticket有效时间
4.CLient 地址

4. Client收到AS的响应消息以后，利用自身的 CLIENT 密钥可以对 Msg A 进行解密，这样可以获取到 CLIENT/TGS SESSIONKEY 。但由于 Msg B 是使用 TGS 密钥加密的， Client 无法对其解密。

AS响应的消息中有一条是属于Client的，但另外一条却属于TGS。
Client/TGS SessionKey 出现了两个Copy，一个给Client端，一个给TGS端。
认证过程中的加密除哈希外均采用的是对称加密算法。

3. 请求服务授权

3.1 客户端向TGS发送请求服务授权请求

客户端发送的请求中包含如下两个消息：

Msg C:

1. 要请求的服务ID, 即 [Service ID]
2. 上一步2.2中由AS为 Client 提供的TGT。

Msg D

使用 CLIENT/TGS SESSIONKEY 加密的 Authenticator 1 {Client ID,Timestamp} 。

KDC接收到TGT与其他内容后，会首先使用KDC 的 NTLM Hash 解密 TGT ，只有 KDC 可以解密TGT，从TGT中提取到 CLIENT/TGS SESSIONKEY ，再使用 CLIENT/TGSSESSIONKEY 解密 Authenticator 1 ，获取到 {Client ID, Timestamp} 并与通过解密TGT获取到的 {Client ID, 有效时间} 进行对比

3.2 TGS为Client响应服务授权票据

TGS为Client响应的消息包括：Msg E 使用 SERVICE 密钥(服务器的 NTLM HASH ) 加密的 CLIENT-TO-SERVERTICKET , 该Ticket中包含了如下信息:

[Client/Server SessionKey]
Client网络地址
Ticket有效时间
Client ID

Msg F 使用 CLIENT/TGS SESSIONKEY 加密的 CLIENT/SERVER SESSIONKEY

Msg F 使用了 CLIENT/TGS SESSIONKEY 加密，因此，该消息对Client可见。 Client对其解密以后可获取到 CLIENT/SERVER SESSIONKEY 。

而 Msg E 使用了 [SERVICE密钥] 加密，该消息可视作是 TGS 给 Service Server 的消息，只不过由 Client 一起携带发送给 Service Server

4.发送服务请求

4.1 Client向Service Server发送服务请求

发送的消息中包括：

Msg E 上一步3.2中，TGS为Client响应的消息Msg E。该消息可以理解为由Client携带的消息。
Msg G 由 [Client/Server SessionKey] 加密的 Authenticator 2 ，包含 {ClientID, Timestamp} 信息。
- CLIENT/SERVER SESSIONKEY 并非直接传输，而是被包含在使用[Service密钥]加密的 Msg E 中。
- 既然 [CLIENT/SERVER SESSIONKEY] 并不直接明文传输， Client需要向Service Server 证明自己拥有正确的 CLIENT/SERVER SESSIONKEY ，所以， Authenticator 2 使用了 CLIENT/SERVER SESSIONKEY 加密。

4.2 Service Server响应Client

1. SS收到客户端的服务请求之后，先利用自身的 [SERVICE密钥] 对 Msg E 进行解密，提取出Client-To-Server Ticket, 在3.2步骤中，提到了该Ticket中包含了CLIENT/SERVER SESSIONKEY 以及 Client ID 信息。

2. SS使用 CLIENT/SERVER SESSIONKEY 解密 Msg G ，提取 Client ID 信息，而后将该 Client ID 与 Client-To-Server Ticket 中的 Client ID 进行比对，如果匹配则说明Client拥有正确的 CLIENT/SERVER SESSIONKEY 。

3. 而后， SS 向 Client 响应 Msg H (包含使用 CLIENT/SERVER SESSIONKEY 加密的Timestamp 信息)。

4. Client 收到SS的响应消息 Msg H 之后，再使用 CLIENT/SERVER SESSIONKEY 对其解密，提取 Timestamp 信息，然后确认该信息与 Client 发送的 Authenticator2 中的 Timestamp 信息一致。

如上信息可以看出来，该交互过程起到了Client与SS之间的“双向认证”作用。

标签：TGS,CLIENT,Windows,笔记,认证,Client,密钥,Server
From： https://www.cnblogs.com/WhatHowie/p/17498484.html