在《阿里云SMB协议文件存储服务支持基于AD域的用户身份认证及权限访问控制介绍》中，我们介绍了文件系统的用户身份认证和访问权限控制的一些基本概念，以及阿里云SMB协议文件存储服务目前支持基于AD域系统的用户身份认证及访问权限控制的实现。在这个支持AD域系统的用户身份认证的实现中，我们采用的是Kerberos网络身份认证协议。那么，为了更好地理解这个基于域的身份认证过程，我们在这里介绍一下Kerberos网络身份认证协议，以及SMB文件系统中是如何支持Kerberos网络身份认证的。

一、Kerberos网络身份认证协议简介

Kerberos是由MIT研发的一种第三方网络身份认证协议，它提供了一种在不安全的网络环境中客户端/服务器模型下的各个实体安全地认证对方身份的协议-即客户和应用服务互相认证对方的身份。Kerberos一般使用共享密钥系统，但是需要一个可信的第三方，称为密钥分配中心KDC（Key Distribution Center）。它定义了客户/服务和第三方认证服务即密钥分配中心之间的安全认证交互过程。
最早的Kerberos是MIT为了保护Athena项目的服务而开发的。前三个版本都只是在MIT内部使用。从1983年开始的第四版本开始为外部使用。我们现在一般使用的是1993年开发的第五版本，即Kerberos 5。

# Kerberos网络身份认证协议的关键实体介绍

密钥分发中心 KDC(Key Distribution Center)。 KDC是Kerberos身份认证协议中最为关键的实体，也就是客户端和应用服务器都信任的第三方实体。它首先提供了传统的密码管理的功能，维护者所有安全主体的账户信息，包括各个安全主体的加密密钥，也就是安全主体的长效密钥，即是由安全主体的密码生成的密钥。另外，KDC还负责Kerberos协议中的密钥分发职责。具体的过程我们会在下面协议交互章节中详细介绍。

基于上面的两个主要功能，KDC由认证服务和票据授权服务组成：

认证服务AS (Authentication Service)：认证服务的主要功能是进行管理安全主体的身份和密钥，对客户的身份进行确认，颁发票据授权票据。

票据授权服务 TGS (Ticket Granting Service) ：票据授权服务主要是进行票据授权票据的确认，确认用户的身份并颁发服务票据。

客户端 Client：要访问某个应用服务的计算机软件实体。在客户端/服务器模型中，客户端也就是服务请求方。在Kerberos认证协议中，一般客户端会以某个在KDC中注册的身份访问特定的服务。
应用服务器 Server ：支持Kerberos第三方认证服务的某个应用服务器，也称为Kerberized Server。在客户端/服务器模型中，应用服务器也就是服务提供方或者请求处理方。在Kerberos认证协议中，应用服务器也需要在KDC中注册相应的服务身份。
票据 Ticket：用于访问某个服务的访问信息，一般包含用户身份，客户端网络信息，票据有效期，会话密钥，并用服务端密钥加密。在Kerberos认证协议的交互中，票据一般有票据授权票据和服务票据。
密钥：用来对交互的信息报文进行加解密的数据流，分为长效密钥（由安全主体的密码哈希而来）和会话密钥（用于加密一个会话的内容，只在一个会话周期内有效）。

# Kerberos网络身份认证交互过程

Kerberos网络身份认证协议主要定义了三个交互过程，即认证服务交互，票据授权服务交互，客户服务器交互。下面的流程描述了Kerberos网络身份认证的整个过程。下面我们首先解释主要的消息以及内容，然后我们对每个具体的交互过程具体说明。
1575165659989_e55ef02a_3898_4ae1_a609_53e2f2742343

# 主要消息及内容：

消息A：用户/客户端密钥加密的票据授权会话密钥
消息B：用票据授权密钥加密的票据授权票据（包括客户端ID，有效期，票据授权会话密钥）
消息C：消息B 加上应用服务端ID
消息D：用票据授权会话密钥加密的用户认证卡
消息E：用应用服务密钥加密的服务票据（包括客户端ID，有效期，服务会话密钥）
消息F：用票据授权会话密钥加密的服务会话密钥
消息G：用服务会话密钥加密的用户认证卡
消息H：用服务会话密钥加密的用户认证卡中的时间戳

# 网络认证交互过程：

认证服务交互（Authentication Service Exchange）：该操作一般在用户登录的时候进行，或者在客户端第一次使用某个KDC管理的身份访问系统资源的时候进行。在上图中，认证服务交互包括1和2 这两个请求和回复过程。在这个过程中，客户端向KDC的认证服务AS发送自己的用户名进行身份认证。认证服务AS首先会在本地数据库中查找该用户，如果存在，则用用户的密码hash作为用户的客户端密钥。同时，认证服务AS会生成票据授权会话密钥，用用户的客户端密钥进行加密后生成消息A，并生成票据授权票据，包含客户端ID，有效期，票据授权会话密钥，用票据授权服务密钥进行加密后生成消息B。客户端收到客户端密钥加密的票据授权会话密钥（消息A）后，用客户端密钥解密得到票据授权会话密钥，并将收到的票据授权票据（消息B）保存在本地的票据缓存中。
票据授权服务交互（Ticket-Granting Service Exchange）：客户端把票据授权票据（消息B）和需要访问的应用服务器的信息生成消息C，以及用票据授权会话密钥加密的用户认证卡信息（包括客户端用户身份和时间戳，即消息D），发给票据授权服务TGS。票据授权服务TGS用它的票据授权服务密钥解密票据授权票据（消息B），得到其中的票据授权会话密钥，然后用票据授权会话解密用户认证卡信息（消息D），进行用户认证身份的匹配以及时间戳和票据有效期的验证。如果通过验证，则根据要访问服务的信息，得到服务端密钥。同时生成客户端和服务器通信的服务会话密钥，以及包含客户端ID，有效期，服务会话密钥的服务票据。服务票据用服务密钥进行加密生成消息E，连同用票据授权会话密钥加密的服务会话密钥（消息F），发送给客户端。当客户端收到上面的消息以后，用票据授权会话密钥解密消息F得到服务会话密钥，把服务会话密钥和收到的服务票据（消息E）都保存在本地的票据缓存里。
客户服务交互（Client/Server Exchange）：这里的服务一般是指某个支持Kerberos认证的应用服务器。客户端给应用服务器发请求，该请求包括之前收到的服务票据（消息E），用服务会话密钥加密的用户认证卡（消息G），是否需要双向验证的标志。应用服务器收到该信息以后，用自己的密钥解密服务票据（消息E），从而拿到服务会话密钥和用户身份信息，然后用服务会话密钥解密用户认证卡（消息G）拿到用户的身份信息和相关的时间戳，并对两个消息中的用户身份信息和时间戳进行核对。如果该请求是合法的，应用服务器进一步检查是否需要双向验证。如果需要，应用服务器用服务会话密钥加密收到的时间戳返回给客户端（消息H）。客户端可以根据收到时间戳确定应用服务器的身份。之后，所有的客户端和服务器的访问就通过服务会话密钥进行加密。

# Kerberos的优缺点：

任何一种协议都有其优缺点。这里简单介绍一下Kerberos网络身份认证协议的优缺点。

# # 优点：

安全的防护多种不同的侵入攻击，比如Impersonation和replay attach等。
使用票据的传输，在认证过程中可以不需要传输任何长效密钥，而且客户端和应用服务器之间可以不需要知道对方的密钥信息
有很好的互操作性，不同的平台可以基于Kerberos认证协议进行广泛的互操作。
可以实现双向验证。其他的类似NTLM的认证协议，都是基于一个假设，即远程的服务是可信的。实际上，仿冒服务器在如今的Internet是一个比较常见的。Kerberos认证协议很好的解决了服务身份认证的问题。

# # 缺点：

存在单点故障。Kerberos身份认证过程需要KDC的持续可用。到KDC出现问题时，用户就不能被认证登录或者使用依赖Kerberos的服务。一般情况下，这种单点故障可以通过部署多台KDC并通过认证过程的Failover机制可以解决。
Kerberos需要各个实体采用相同并且严格的时间戳。这就需要各个实体必须配置相同的时钟或者通过类似NTP的机制进行时钟同步。
如果在Kerberos环境中使用对称密钥则存在很大的安全隐患。黑客一旦控制了KDC，则他可以仿冒所有实体。
需要所有实体在Kerberos KDC中被信任，无法满足网络中非信任实体的访问认证。

# Windows对Kerberos网络身份认证协议的支持

在微软的身份认证体系中，以前使用的都是NTLM（NT Lan Manager）进行认证。在Windows2000以后的版本中引入了对Kerberos网络身份认证的支持，并在有active directory domain的情况下优先用Kerberos作用户身份认证协议。Kerberos的安全性和复杂性都比NTLM的几个协议版本要高的多。微软的实现基于Kerberos v5并有扩展（[RFC4120]，[MS-KILE]， [MS-PAC]），其中主要的扩展是采用了Privilege Attribute Certificate Data Structure这样一种机制来传输Windows身份认证信息，包括SID，组等windows特有的安全主体信息。

# 二、Windows SMB协议文件系统对Kerberos网络身份认证的支持

在《SMB协议小传》中，我们介绍了SMB协议以及SMB2会话的六个生命阶段，即SMB协议协商，建立SMB会话，连接文件共享，文件系统操作，断开文件共享，终止SMB会话六个阶段。其中用户认证是在建立SMB会话（Session Setup）这个阶段来完成的。在协议协商阶段，文件服务会向客户端返回它支持的认证协议，即NTLM或者Kerberos。然后，在Session Setup阶段，客户端根据服务端支持的认证协议和它自身支持的协议来选择一种认证协议完成身份认证。下面流程简单描述了包括和AD域服务器的Kerberos认证交互在内的整个SMB服务请求过程：
1575165660178_6eff2ba9_b27c_4b20_b97a_de6898856351

在SMB2协议Session Setup 请求中嵌入了上面提到的Kerberos认证第三个交互即客户服务交互（Client/Server Exchange）的报文，然后SMB文件服务从Session Setup请求中分解出这个报文后，得到了用票据授权会话密钥加密的服务会话密钥（消息F）和用服务会话密钥加密的用户认证卡（消息G），用自己的密钥解密服务票据（消息E），从而拿到服务会话密钥和用户身份信息，然后用服务会话密钥解密用户认证卡（消息G）拿到用户的身份信息和相关的时间戳，并对两个消息中的用户身份信息和时间戳进行核对。如果该请求是合法的，服务器从传入的PAC中分解出用户SID，组等信息，并返回认证成功。之后所有从这个会话来的请求都会以这个用户SID和组的身份对文件系统进行操作。如果客户端配置了传输加密，那么之后所有的报文都会用会话密钥进行加密。

三、小结：

本文简单介绍了Kerberos网络认证协议，以及SMB文件系统对Kerberos认证的支持。希望本文有助于理解阿里云SMB协议文件存储服务的基于AD域系统的Kerberos用户身份认证。

四、阿里云SMB协议文件存储服务基于AD域系统的用户身份认证及访问控制的相关文章

如果要使用阿里云SMB协议文件存储服务的基于AD域系统的用户身份认证及访问权限控制功能，请在阿里云文件系统控制台打开配置该功能。具体请参考将阿里云SMB协议文件系统挂载点接入AD域。

下面是使用基于AD域系统的用户身份认证及访问权限控制可能需要的相关知识点：

阿里云SMB协议文件存储服务支持基于AD域的用户身份认证及权限访问控制介绍，总体介绍阿里云SMB协议文件存储服务支持基于AD域的用户身份认证及权限访问控制的设计实现。
Kerberos网络身份认证协议介绍及SMB文件系统对其的支持，介绍Kerberos网络身份认证协议以及与SMB协议问系统的交互。
安装并启用Active Directory域服务与DNS服务，介绍如何在VPC中安装并启用AD域服务和DNS服务。
将Windows系统机器加入AD域，介绍如何将windows机器加入AD域。
将阿里云SMB协议文件系统挂载点接入AD域，介绍如何在AD域服务器以及阿里云SMB协议文件系统中进行必要的配置来支持基于AD域的用户身份认证及权限访问控制。
从Windows以AD域用户身份挂载使用阿里云SMB协议文件系统，介绍如何从windows客户端以域用户身份挂载使用阿里云SMB协议文件系统。
Linux客户端以AD域用户身份挂载使用阿里云SMB协议文件系统，介绍如何从Linux客户端以域用户身份挂载使用阿里云SMB协议文件系统。
阿里云SMB协议文件系统ACL权限控制使用指南，介绍如何正确地配置阿里云SMB协议文件系统的ACL以及相应的规则描述。
阿里云SMB协议文件系统AD身份认证和ACL权限控制使用场景 - Home Directory / User Profile，介绍使用权限控制的域用户Home Directory以及User Profile两个场景下的相关配置及实现。
MacOS客户端连接阿里云NAS SMB文件系统，介绍如何从MacOS客户端挂载使用阿里云SMB协议文件系统。
Linux客户端以AD域用户身份挂载使用阿里云SMB协议文件系统, 介绍如何把Linux客户端加入AD域，如何挂载以及自动挂载阿里云SMB协议文件系统。

Kerberos网络身份认证协议介绍及SMB文件系统对其的支持