Kerberos认证协议介绍
概述
官网：https://www.kerberos.org/
官方文档：http://web.mit.edu/kerberos/krb5-current/doc/
为TCP/IP网络系统设计的可信的第三方身份认证协议。网络上的Keberos服务基于DES对称加密算法，但也可以用其他算法替代。因此，Keberos是一个在许多系统（尤其是大数据生态）中获得广泛应用的身份认证协议。
适用场景：
Kerberos采用客户端/服务器（CS）结构与DES加密技术，并且能够进行相互认证，即客户端和服务器端均可对对方进行身份认证，是一种应用对称密钥体制进行密钥管理的系统。可以用于防止窃听、防止replay攻击、保护数据完整性等场合。
特性
- 安全性：Kerberos提供双向认证，不仅Server可以对Client 进行认证，Client也能对Server进行认证。Server对Client认证成功之后，通过返回Client发送的时间戳，向Client提供验证自己身份的手段
- 可靠性：认证服务是其他服务的基础，服务认证过程有助于提升整个系统的可用性和高可靠性
- 可扩展性：KDC是秘钥体系的重要部分，旨在减少密钥体制所固有的交换密钥时所面临的风险。用户可根据需要扩展多个KDC
- 开放性：Kerberos已经成为计算机领域一个被广泛接受的标准，使用Kerberos可以轻松实现不同平台之间的互操作
原理
Kerberos是一种基于加密Ticket的身份认证协议，主要由三个部分组成：即KDC、Client和Service。
概念
KDC，Key Distribution Center，主要由三个部分组成：
- Kerberos Database：包含一个Realm中所有的principal、密码与其他信息。（默认Berkeley DB）
- Authentication Service：AS，进行用户信息认证，为客户端提供Ticket Granting Tickets，TGT
- Ticket Granting Service：TGS，验证TGT与Authenticator，为客户端提供Service Tickets。
Realm：Kerberos管理领域的标识
principal：Kerberos下的用户，当每添加一个用户或服务时，都需要向KDC添加一条principal，形式为：主名称/实例名@领域名。
主名称：可以是用户名或服务名，表示是用于提供各种网络服务(如HDFS、yarn、hive）的主体。
实例名：简单理解为主机名
keytab文件：存储用户的加密密码。常用这种方式认证。
Ticket分两种：
- Ticket Granting Ticket：TGT，这是KDC中的AS产生的，TGT是向TGS用于表明自己真实身份的东西
- Service Ticket：ST，这是KDC中的TGS产生的，Service Ticket用于向应用服务器表明自己身份的东西
principal有两类：
-
用户principal：形如
Name[/Instance]@REALM
其中Instance是可选的，通常用于更好地限定用户的类型。比如，一个管理员用户通常会有admin instance，即Name/admin@REALM。 -
服务principal：形如
Service/Hostname@REALM
第一部分是service的名字，如imap，AFS，FTP。通常host这个名字被用于指明对一台机器的通用的访问（telnet，rsh，ssh）。
第二个component是提供这个服务的机器的全限定域名(FQDN)。这个component跟DNS对应用服务器的IP地址进行逆向解析后得到的主机名。
理论
关于Kerberos的一些理论知识储备：
- Kerberos基于Ticket实现身份认证，而非密码。如果客户端无法利用本地密钥，解密出KDC返回的加密Ticket，认证将无法通过
- 客户端将依次与Authentication Service，Ticket Granting Service以及目标Service进行交互，共三次交互
- 客户端与其他组件交互时，都将获取到两条信息，其中一条可以通过本地密钥解密出，另外一条将无法解密出
- 客户端想要访问的目标服务，将不会直接与KDC交互，而是通过能否正确解密出客户端的请求来进行认证
- KDC Database包含有所有principal对应的密码
- Kerberos中信息加密方式一般是对称加密，支持配置成非对称加密
步骤
客户端会先访问两次KDC，然后再访问目标Service，如：HTTP服务。
大体来说是3次请求与响应：
- AS_REQ：在初始化一个用户（kinit）时发出的用户认证请求，这个请求是发给KDC中的AS；
- AS_REP：AS回复给client的信息，其中包括TGT（用TGS secret key加密过的）and the session key（用发请求的用户的secret key加密过的）
- TGS_REQ：client为了一个service ticket向Ticket Granting Server (TGS)的信息. 其中包括上一条信息中获得的TGT (用TGS secret key加密过的) ，一个客户端产生的一个authenticator(用session key加密过的）
- TGS_REP：TGS回复给TGS_REQ的信息，其中包括service ticket（用appservice的secret key加密过），和一个TGS产生的service sessinon key（之前AS产生的一条session key给加密过的）
- AP_REQ：一条客户端发给appServer的访问服务的请求，其中包括service ticket和一个authenticator（使用TGS产生的service session key 加密过的）
- AP_REP：appServer回复给client的一条信息，证明这个appServer确实是客户端希望访问的server。不过这条信息也不一定总是要回复的。如当客户端和appServer需要相互认证时，客户端向appServer发出请求，这个时候就不需要回复信息。
Authentication Service Exchange
通过这个Sub-protocol，KDC中的Authentication Service实现对Client身份的确认，并颁发给该Client一个TGT
Client向KDC的AS发送Authentication Service Request（AS_REQ），为了确保AS_REQ仅限于自己和KDC知道，Client使用自己的Master Key对AS_REQ的主体部分进行加密（KDC可以通过Domain的Account Database获得该Client的Master Key）。AS_REQ的大体包含以下的内容：
- Pre-authentication data：包含用以证明自己身份的信息。就是证明自己知道自己声称的那个account的Password。一般地，它的内容是一个被Client的Master key加密过的Timestamp。
- Client name & realm：即Domain name\Client
- Server Name：这里的Server Name并不是Client真正要访问的Server的名称，TGT是和Server无关的（Client只能使用Ticket，而不是TGT去访问Server）。这里的Server Name实际上是KDC的TGS的Server Name。
AS通过它接收到的AS_REQ验证发送方的是否是在Client name & realm中声称的那个人，也就是说要验证发送放是否知道Client的Password。所以AS只需从Account Database中提取Client对应的Master Key对Pre-authentication data进行解密，如果是一个合法的Timestamp，则可以证明发送放提供的是正确无误的密码。验证通过之后，AS将一份Authentication Service Response（AS_REP）发送给Client。AS_REQ主要包含两个部分：本Client的Master Key加密过的Session Key（SKDC-Client：Logon Session Key）和被自己（KDC）加密的TGT。而TGT大体又包含以下的内容：
- Session Key：SKDC-Client：Logon Session Key
- Client name & realm：即Domain name\Client
- End time：TGT到期时间。
Client通过自己的Master Key对第一部分解密获得Session Key（SKDC-Client：Logon Session Key）之后，携带着TGT便可以进入下一步：TGS Exchange。
Ticket Granting Service Exchange
TGS Exchange通过Client向KDC中的TGS发送TGS Request（TGS_REQ）开始。TGS_REQ大体包含以下的内容：
- TGT：Client通过AS Exchange获得的Ticket Granting Ticket，TGT被KDC的Master Key进行加密。
- Authenticator：用以证明当初TGT的拥有者是否就是自己，所以它必须以TGT的颁发方（KDC）和自己（Client）的Session Key（SKDC-Client：Logon Session Key）来进行加密。
- Client name & realm：即Domain name\Client。
- Server name & realm：即Domain name\Server，这回是Client试图访问的那个Server。
TGS收到TGS_REQ在发给Client真正的Ticket之前，先得整个Client提供的那个TGT是否是AS颁发给它的。于是它不得不通过Client提供的Authenticator来证明。但是Authentication是通过Logon Session Key进行加密的，而自己并没有保存这个Session Key。所以TGS先得通过自己的Master Key对Client提供的TGT进行解密，从而获得这个Logon Session Key，再通过这个Logon Session Key解密Authenticator进行验证。验证通过向对方发送Ticket Granting Service Response（TGS_REP）。TGS_REP有两部分组成：使用Logon Session Key加密过用于Client和Server的Session Key（SServer-Client）和使用Server的Master Key进行加密的Ticket。该Ticket大体包含以下一些内容：
- Session Key：SServer-Client。
- Client name & realm: 即Domain name\Client。
- End time: Ticket的到期时间。
Client收到TGS_REP，使用Logon Session Key解密第一部分后获得Session Key（SServer-Client）。有了Session Key和Ticket，Client就可以之间和Server进行交互，而无须在通过KDC作中间人。因此Kerberos是一种高效的认证方式，它可以直接通过Client和Server双方来完成，不像Windows NT 4下的NTLM认证方式，每次认证都要通过一个双方信任的第3方来完成。
Authenticator - 为有效的证明自己提供证据
通过上面的过程，Client实际上获得两组信息：一个通过自己Master Key加密的Session Key，另一个被Sever的Master Key加密的数据包，包含Session Key和关于自己的一些确认信息。一般而言，只要通过一个双方知晓的Key就可以对对方进行有效的认证，但是在一个网络的环境中，这种简单的做法是具有安全漏洞，为此,Client需要提供更多的证明信息，我们把这种证明信息称为Authenticator，在Kerberos的Authenticator实际上就是关于Client的一些信息和当前时间的一个Timestamp。
Client/Server Exchange
Client通过TGS Exchange获得Client和Server的Session Key（SServer-Client），随后创建用于证明自己就是Ticket的真正所有者的Authenticator，并使用Session Key进行加密。最后将这个被加密过的Authenticator和Ticket作为Application Service Request（AP_REQ）发送给Server。AP_REQ还包含一个Flag用于表示Client是否需要进行双向验证（Mutual Authentication）。
Server接收到AP_REQ之后，通过自己的Master Key解密Ticket，从而获得Session Key。通过Session Key解密Authenticator，进而验证对方的身份。验证成功，让Client访问需要访问的资源，否则直接拒绝对方的请求。
对于需要进行双向验证，Server从Authenticator提取Timestamp，使用Session Key进行加密，并将其发送给Client用于Client验证Server的身份。
为何要用Timestamp
试想这样的现象：Client向Server发送的数据包被某个恶意网络监听者截获，该监听者随后将数据包座位自己的Credential冒充该Client对Server进行访问，在这种情况下，依然可以很顺利地获得Server的成功认证。为了解决这个问题，Client在Authenticator中会加入一个当前时间的Timestamp。
在Server对Authenticator中的Client Info和Session Ticket中的Client Info进行比较之前，会先提取Authenticator中的Timestamp，并同当前时间进行比较，如果他们之间的偏差超出一个可以接受的时间范围（如5min），Server会直接拒绝该Client的请求。Server维护着一个列表，这个列表记录着在这个可接受的时间范围内所有进行认证的Client和认证的时间。对于时间偏差在这个可接受的范围中的Client，Server会从这个这个列表中获得最近一个该Client的认证时间，只有当Authenticator中的Timestamp晚于通过一个Client的最近的认证时间的情况下，Server采用进行后续的认证流程。
总结
整个认证过程时序图
实战
安装
分为Server和Client安装：
Server：
- krb5-server：Kerberos服务端程序，KDC所在节点
- krb5-workstation： 包含一些基本Kerberos程序，如(kinit, klist, kdestroy,kpasswd)，使用Kerberos的所有节点都应该部署
- krb5-libs：包含Kerberos程序的各种支持类库等。
配置文件：
- krb5.conf：客户端根据该文件中的信息取访问KDC
- kdc.conf：kdc的专属配置，可根据自己的需求修改kdc数据库的存放目录。
- kadm5.acl：权限相关配置，
client
- krb5-workstation：同上
- krb5-devel：包含编译Kerberos程序的头文件和一些类库。
配置文件：
参考
- https://www.cnblogs.com/liugp/p/16468514.html