Active Directory 与 Kerberos 认证详解

Active Directory (AD)

Windows域也叫活动目录(Active Directory)，是微软开发的应用于Windows域环境的目录服务(AD DS - Active Directory Domain Services)，中央集权式管理域内所有资源，包括域内的用户、用户组、计算机、共享目录、打印机、策略等。

域(Domain)是相对工作组(Workgroup)的概念，通过 Kerberos 或者 NTLM 认证实现了企业级的单点登录，方便用户访问企业内部资源，包括打印机、文件共享服务、Web应用等。

一切资源皆对象

分为容器型和叶子型：

• 容器型：用户组这种能包含其他对象的对象
• 叶子型：无法包含其他对象，比如某个用户、某台计算机这种

DNS & LDAP & Kerberos

AD要正常工作，就需要通过DNS(Domain Name System)来解析主机名与IP地址的对应关系，或者定位某些服务，比如客户端可以通过DNS的SRV记录获取主域控服务器的地址。

要通过Kerberos认证访问域内某个服务，需要知道运行该服务的主机域名，也就是FQDN(fully qualified domain name)，如果仅指定目标服务的IP地址进行访问，则会转为NTLM认证。

1
2

dir \\pdc.domain.com\c$ -- Kerberos认证
dir \\10.10.10.10\c$ -- NTLM认证

Active Directory & LDAP

AD是微软实现的目录服务(Directory Service)，通过LDAP(Lightweight Directory Access Protocol)协议对域内对象进行读写操作。这种关系就像是WEB服务需要通过HTTP协议访问一样。

Kerberos Overview

Kerberos协议设计的初衷的是在不安全的网络环境下，基于加密实现安全高效的认证，避免中间人攻击(比如密码泄露或重放攻击)。Kerberos协议通过可信的第三方(域控)实现了用户对目标服务(资源)访问权限的认证。域控服务器存储了域内所有用户(user and computer account)的密码信息，目标服务本身不需要存储或访问用户的密码信息，通过可信第三方即可对用户的身份进行认证，相对传统的NTLM认证更安全，并且高效。

微软对Kerberos做了一些功能扩展，比如PAC、S4U子协议(后文会有详细介绍)。

Kerberos认证的基本流程

大体上分六个步骤(三个来回)：

1. 域用户登录时 → 向域控的AS(Authentication Service)服务发送一段用自身密码(变种)加密的时间戳，证明其知道该用户的密码，[预认证]

2. 域控的AS服务验证用户的密码是否正确(域控存储了域内所有用户的密码信息)，验证通过后返回给用户一个TGT票据(Ticket Granting Ticket)，也叫”登录票据”(Login Ticket) [验证&产生TGT]

   TGT解释：

   • 该票据经过域控的krbtgt帐号密码加密，也就是说除了域控，理论上没有人能解密该票据里面的数据，更无法伪造
   • 该票据作为用户的凭证，内部包含了该用户的用户名、用户ID、所属组ID等信息[PAC]
   • 之后用户申请其它服务的资源访问票据(Resource Access Ticket)时，需要再次提供该TGT给域控，向域控表明身份，而无需再次重复上一步的预认证过程

3. 用户申请服务票据 → 用户此时希望访问某共享目录服务，需要向域控的票据授予服务(TGS-Ticket Granting Service)申请目标服务的资源访问票据(Resource Access Ticket)。此时用户将TGT转交给TGS完成申请，TGT是用户的身份凭证，由KDC颁发，只有域控自身可解密，无人可伪造。

4. TGS服务返回给用户对应目标服务的服务票据(Service Ticket)，用户同样无法解密或伪造该票据。

5. 用户将服务票据发送给目标服务(这里是CIFS/fileserver.domain.com)。

6. 目标服务验证 → 用户将上一步收到的资源访问票据ST发送给目标服务，目标服务收到该票据，用运行该服务的帐户密码解密该票据，验证该用户的身份及权限，决定认证成功或失败。

TGT & TGS

可以得出前面四步是关键步骤，都是围绕着用户向域控的AS申请TGT，后续使用TGT向域控申请服务票据，进而访问目标服务展开的。

TGT可以看作域内的身份证，有这个身份证你可以向TGS也就是官方申请，浏览在你权限范围内的任意服务，官方校验通过后给你发身份证复印件也就是服务票据，让你通过服务的验证。

TGT本身不是用来访问服务的，就像身份证原本的职能就只是向官方表明你本人身份的真实性，而不是用来做游戏实名认证的。服务票据则承担了这个职能，本质就是你预认证后产生的TGT和TGS沟通，TGS认可TGT的真实性并发放服务票据，允许你通过这个访问其他服务。

Kerberos & PAC

由于原生Kerberos协议仅对用户身份有效性进行验证(即证明该用户确是其声称的用户)，目标服务无从判断用户对自身服务具有哪些访问权限，所以微软对Kerberos做了扩展。

=> 服务访问权限

票据中增加了PAC(Privilege Attribute Certificate)数据块，包含了该用户的用户名、用户ID、所属用户组ID等信息。为了确保这些敏感信息不被非法篡改，分别用域控krbtgt帐户密码及目标服务帐户密码对其进行签名(TGT票据比较特殊，目标服务帐户即为krbtgt帐户)。

MS14-068

也许正因为PAC是微软对Kerberos做的扩展，所以用户在认证的第一步，即发起预认证请求(AS-REQ)时，设置PA-PAC-REQUEST=False，认证服务会生成一个不包含PAC的有效TGT – MS14-068。

Kerberos & SPN

=== 服务自身的标识符 ===

域用户和计算机帐户包含各种属性，比如名字、描述等，其中一个属性叫服务主体名(Service Principal Name)，是提供服务所必须的一条属性。服务主体名(后称为SPN)在一个林(forest，林内可包含多个域)内必须是唯一的，不然Kerberos认证会失败。

SPN是由服务实例注册的林内唯一标识符，客户端想要访问某个服务，必须指定该服务实例的SPN。

SPN的两种类型

1. 基于主机的SPN - 计算机帐户创建时，内置服务会自动创建该种类型的SPN

   1	<service class>/<host>:[port]/[service name]

   例如：MSSQLSvc/server1.domain.com:1433

2. 任意的SPN - 通常情况下，以域用户身份运行的服务采用此类SPN，其中服务类型和服务名可任意指定

   1	<service class>/<service name>

   例如：AcmeService/GlobalBank

Kerberos Delegation

Delegation(委派)是Kerberos相对传统的NTLM认证所独有的特性。

用户向某服务发起认证后，该服务可以代理/假冒(impersonate)该用户，以其身份访问其它服务，比如用户访问Web服务，Web服务以用户的身份向域控申请数据库服务的访问权限。也就是说该Web服务具有被用户委派的权限。

这个就很简单了，就类似用户将学生证托管给学校，学校凭你的学生证帮你申请其他主办方举办的大型考试权限。

委派分类

1. Unconstrained Delegation/非约束委派

• TrustedForDelegation=True(Kerberos Only)
• 没有任何限制的TGT票据转发
• Since Windows Server 2000

ServiceA具有非约束委派的权限时，当用户向域控申请ServiceA的ST时，域控将该用户的TGT附加到生成的ST中，之后用户向ServiceA提供该ST，ServiceA可以从ST中把用户的TGT提取出来，放入自身的LSASS进程中，”假冒”该用户向域控申请ServiceB的ST。

这就是某个服务作为用户的代理人调用其他服务。

2. Constrained Delegation/约束委派(基于S4U协议扩展)

• S4U2Proxy/msDS-AllowedToDelegateTo=NotNULL(生成的ST总是具有Forwardable属性)
• 有限制的TGS票据转发
• Since Windows Server 2003

ServiceA具有约束委派权限时(msDS-AllowedToDelegateTo=ServiceB)，用户向域控申请ServiceA的ST时，域控将生成的ST(for User to ServiceA)标记为可转发(Forwardable)，ServiceA利用该ST执行S4U2Proxy，”代理”用户向域控申请ServiceB的ST，之后ServiceA使用域控返回的ST(for User to ServiceB)访问ServiceB。

这里就是需要经过域控认可给ST发放可转发标记，让ServiceA能够利用S4U2Proxy向域控申请ServiceB的ST访问B。

3. S4U2Self/协议过渡(Protocol Transition)

帮助不支持Kerberos认证(比如仅支持NTLM)的客户端生成对自身服务可用的TGS票据。

• TrustedToAuthForDelegation=True：生成的ST具有Forwardable属性
• TrustedToAuthForDelegation=False：生成的ST没有Forwardable属性

也就是说S4U2Self子协议对于任意具有SPN的帐户都是可用的，无论该帐户TrustedToAuthForDelegation属性被设置为真或假。为假时，S4U2Self生成的ST不可被转发，只能访问其自身。只有为真时，S4U2Self生成的ST才具有转发属性(Forwardable)，可被S4U2Proxy用来转发(即转发至域控的TGS服务)生成访问另外一个服务的ST。对于传统的约束委派来说是这样。

但是对于下面介绍的基于资源的委派而言，无论S4U2Self生成的ST是否具有转发属性，均可被S4U2Proxy用来转发生成访问另外一个服务的ST(Service Ticket)。

4. Resource-Based Constrained Delegation/基于资源的约束委派

• 属性：AllowedToActOnBehalfOfOtherIdentity
• Since Windows Server 2012

AllowedToActOnBehalfOfOtherIdentity翻译过来就是允许以某个服务的身份执行某事，一般指向的就是某个服务主体。

不需要域控，任何计算机对象都可以设置这个属性。

基于资源的约束委派是由ServiceB设定允许ServiceA代理用户访问ServiceB(from ServiceA to ServiceB setting on ServiceB)，此时并不需要ServiceA帐户具有任何特殊权限，即不需要ServiceA帐户具有任何以下属性：TrustedForDelegation、msDS-AllowedToDelegateTo、TrustedToAuthForDelegation。只需要两个服务之间互相认可就行。