简单地说，Kerberos提供单点登录(SSO)方法。考虑到这样的场景，网络中有不同的服务器，如打印服务器、电子邮件服务器和文件服务器。这些服务器都需要认证。当然，每个服务器不可能实现一个认证系统，而是提供一个中心认证服务器（AS-Authentication Server）用于这些服务器。这样，任何客户端只需维护一个密码即可登录所有服务器。

因此，在Kerberos系统中至少有三个角色：认证服务器（AS），客户端（Client）普通服务器（Server）。将有客户端和服务器AS在帮助下完成相互认证。

在Kerberos在系统中，客户端和服务器都有一个独特的名称Principal。同时，客户端和服务器都有自己的密码，只有自己的密码和认证服务器AS知道。

KDC

Client

Server

Ticket ： 网络对象相互访问的凭证只对客户机和特定服务器上的特殊服务有效。

票证包括以下内容：

• 服务主体名称
• 用户主体名称
• 用户主机的 IP 地址
• 时间标记
• 定义票证生命周期的值
• 会话密钥副本

KDC：可靠的认证来源，密钥分发中心， KDC但负责管理票据、认证票据和分发票据KDC不是独立服务，KDC可以分为Authentication Server (身份验证服务)和Ticket Granting Server (票据授权服务)

Authentication Service (AS）：身份验证服务， 存储着该Domain所有账户信息一般都是由 Account Database来维护

Ticket Granting Service： 票据授予服务，为client生成服务ticket(简称TGS)

Ticket-Granting Ticket：票据授权票据，由KDC的AS发放；取得此类票据后，以后申请其他应用的服务票据（ST）时间，不需要向KDC提交身份认证信息（credential），TGT具有一定的有效期，就像是kerberos进行kinit未来只有固定时间的有效期，需要持续renew来续约。

ST(service ticket): 服务票据，由KDC的TGS分发，任何应用（application）访问需要有效的服务票据；如果能正确接受ST，说明client和server信任关系已经建立，通常是数字加密证书。

Principal： 具有唯一标志的实体可以是计算机或服务，通过使用KDC通信发放的票据。Principal可分为两类： 对于用户主体来说，用户和服务的例子是可选的 ，但对于服务主体来说，实例是必要的。

由三部分组成 。username(or servicename)/instance@realm

例如：nn/zelda1@ZELDA.COM，zelda一是集群中的机器；或admin/admin@ZELDA.COM，管理员账户。

• username or servicename：本文服务，HDFS两种服务分别命名为nn和dn，即namenode和datanode
• instance：具体在本文中FQDN用来保证全局唯一的机器名(如多个)datanode各节点需要独立认证)
• realm：域，这里为ZELDA.COM(全大写)，Kerberos网络

Hadoop中的每一项服务和子服务一定要有自己的主体。在这种情况下，实例名称运行该服务的主机FQDN。 由于该服务没有使用密码登录以获得其票据，其主体的身份验证证据存储在keytab在密钥表文件中，该文件从Kerberos从数据库中提取并存储在服务组件主机上的安全目录中。NameNode组件。

在node1.example.com在主机上，启用kerberos之后，它将自动生成nn.service.keytab并存储文件/etc/security/keytabs在目录下，用户所有者是hdfs:hadoop，权限为400

Principal和Keytab命名约定

nn/node1.example.com@EXAMPLE.COM 为 /etc/security/keytabs/nn.service.keytab

请注意上述示例中各服务主体的主要名称。这些主要名称如nn或hive）分别代表NameNode或Hive服务。 每个主要名称都附加了实例名称，即运行它的主机的FQDN。这个协议是多个主机(DataNodes和NodeManager）运营服务提供唯一的主题名称。 例如，添加主机名进行区分DataNode A请求和来源DataNode B的请求。

Keytab：密匙文件， keytab每个文件host因为key中包含hostname

krbtgt：每个域控制器DC都有一个”krbtgt用户账户，是的KDC用于创建票据授予服务的服务账户(TGS)加密的密钥

Realm：域， 包含KDC还有很多客户端Kerberos网络

Authenticator ：client info加上当前时间的一个Timestamp

Master Key ：在Security有的领域Key可能会长期保持不变，比如你在密码里，可能好几年都没变。Key、由此衍生的Key被称为Long-term Key。对于Long-term Key使用有这样一个原则：被子Long-term Key网络上不应传输加密数据。原因很简单，一旦这些都被录用了Long-term Key原则上，只要有足够的时间，加密的数据包就可以被恶意的网络监听者截获。Long-term Key任何加密算法都不可能绝对保密。

Session Key：由于被Long-term Key加密数据包不能用于网络传输，所以我们使用另一个Short-term Key加密需要网络传输的数据。Key即使被加密的数据包被黑客截获，也只能在一段时间内有效，等待他截获Key计算出来的时候，这个Key早就已经过期了。

以上术语简单说说他们的关系:KDC由AS和TGS组成，AS发放身份认证TGT，TGT需要重复认证的凭证用于避免多次请求；TGS发放ST，ST访问某个service时的凭证，ST相当于告诉service你的身份被KDC认证是合法凭证。

Authentication解决了如何证明某人确实是他或她所声称的人的问题。

如何进行Authentication，如果是密码，我们使用这种方法（secret）只存在于A和B，然后有人声称自己是BA，B让A提供这个秘密来证明这个人是他或她声称的A。这个过程实际上涉及三个重要的关系Authentication的方面：

• Secret如何表示。
• A如何向B提供？Secret。
• B如何识别Secret。

基于这三个方面，我们将Kerberos Authentication最大限度的简化:整个过程涉及Client和Server，他们之间的这个Secret我们用一个Key（KServer-Clint）来表示。Client为了让Server对自己进行有效的认证，向对方提供如下两组信息：

• 代表Client自身Identity的信息，为了简便，它以明文的形式传递。
• 将Client的Identity使用KServer-Client作为Public Key、并采用对称加密算法进行加密。

由于KServer-Client仅仅被Client和Server知晓，所以被Client使用KServer-Client加密过的Client Identity只能被Client和Server解密。同理，Server接收到Client传送的这两组信息，先通过KServer-Client对后者进行解密，随后将机密的数据同前者进行比较，如果完全一样，则可以证明Client能过提供正确的KServer-Client，而这个世界上，仅仅只有真正的Client和自己知道KServer-Client，所以可以对方就是他所声称的那个人。

KRB_AS_REQ (Kerberos Authentication Service Request) 
KRB_AS_REQ的大体包含以下的内容
1.Pre-authentication data：一般地，它的内容是一个被Client的Master key加密过的Timestamp
2.Client name & realm：简单地说就是Domain name\Client
3.server Name：KDC的Ticket Granting Service（票据授权服务）的server Name

KDC-AS 通过KRB_AS_REQ中的Client name & realm 从 Account Database中提取Client对应的Master Key，对Pre-authentication data进行解密，如果是一个合法的Timestamp，发放TGT

KRB_AS_REP (Kerberos Authentication Service Response) 
身份验证服务(KDC-AS)会解密时间戳,若解密成功创建票据授予票据(Ticket-Granting Ticket,TGT)
包含2部分数据
kdc随机生成Session Key(kdc与client)，又称为Logon Session Key
1.使用Client的Master Key加密Logon Session Key
2.使用自己的master key（krbtgt）加密 TGT
	TGT又包含以下几部分
	1.Session Key:SKDC-Client
	2.Client name & realm
	3.End time：TGT到期的时间，一般为5分钟

Client通过自己的Master Key对第一部分解密获得session Key之后，携带着TGT便可以进入下一步：TGS（Ticket Granting Service）

KRB_TGS_REQ (Kerberos Ticket Granting Service Request) 
Client使用AS返回的Session Key构建访问特定服务的请求,再把AS返回的”票据授予票据(TGT)”连同请求一起发送到票据授予服务TGS) 
1.TGT：直接原封不动返回, TGT被KDC的Master Key进行加密，client无法解密TGT
2.Authenticator：client + timestamp，用client的master key加密
3.Client name & realm
4.Server name & realm：client 要 访问的服务名

TGS先得通过自己的Master Key对Client提供的TGT进行解密，从而获得这个session key(Logon Session Key) ，

再通过这个session key解密Authenticator进行验证。验证通过向对方发送Ticket Granting Service Response

KRB_TGS_REP (Kerberos Ticket Granting Service Response)
KRB_TGS_REP有两部分组成
kdc随机生成Session Key(Client和Server的Session Key,非Logon Session Key)
1.使用Logon Session Key(SKDC-Client) 加密过 Client和Server的Session Key(SServer-Client)
2.使用Server的Master Key进行加密的Ticket，改Ticket大体包含以下一些内容：
	1.Session Key：SServer-Client
	2.Client name & realm
	3.End time：Ticket的到期时间，一般为8小时

Client收到KRB_TGS_REP，使用Logon Session Key（SKDC-Client）解密第一部分后获得Session Key（SServer-Client），最后连同从KDC获得的被Server的Master Key加密过的数据包（Client Info + Session Key）一并发送到Server端。我们把通过Server的Master Key加密过的数据包称为Session Ticket。

KRB_AP_REQ (Kerberos Application Request) 
1.通过Logon Session Key 解密获取 SServer-Client的 Session Key
2.创建 Authenticator（Client Info + Timestamp）并用Session Key(SServer-Client)对其加密

Server接收到KRB_AP_REQ之后，通过自己的Master Key解密Ticket，从而获得Session Key（SServer-Client）。

通过Session Key（SServer-Client）解密Authenticator，进而验证对方的身份。验证成功，让Client访问需要访问的资源，否则直接拒绝对方的请求。

每当主体获取包括票证授予票证 (Ticket–Granting Ticket, TGT) 在内的票证时，可以通过 kinit 的 -l 选项指定的生命周期值。缺省情况下，kinit 使用最长生命周期值。kdc.conf文件中指定的最长生命周期值 (max_life)

可通过 kinit 的 -r 选项指定的可更新生命周期值。kdc.conf 文件中指定的最长可更新生命周期值 (max_renewable_life)。

每个票证都使用主体名称进行标识。主体名称可以标识用户或服务。以下是一些主体名称的示例：

yum install krb5-server krb5-libs krb5-workstation

KDC (Key Distribution Center）密匙分配中心, 其在kerberos中通常提供两种服务：

Authentication Service (AS)：认证服务

Ticket-Granting Service (TGS)：授予票据服务

includedir /etc/krb5.conf.d/

[logging]
 default = FILE:/var/log/krb5libs.log
 kdc = FILE:/var/log/krb5kdc.log
 admin_server = FILE:/var/log/kadmind.log

[libdefaults]
 dns_lookup_realm = false
 ticket_lifetime = 24h
 renew_lifetime = 7d
 forwardable = true
 rdns = false
# default_realm = EXAMPLE.COM
 default_realm = EXAMPLE.COM
 default_ccache_name = KEYRING:persistent:%{ 
        uid}

[realms]
# EXAMPLE.COM = { 
        
# kdc = kerberos.example.com
# admin_server = kerberos.example.com
# }

EXAMPLE.COM = { 
        
  kdc = ljh1
  admin_server = ljh1
}

[domain_realm]
# .example.com = EXAMPLE.COM
# example.com = EXAMPLE.COM

[logging]：表示server端的日志的打印位置

[libdefaults]：每种连接的默认配置，需要注意以下几个关键的小配置

​ default_realm = EXAMPLE.COM 默认的realm，必须跟要配置的realm的名称一致

​ ticket_lifetime：表明凭证生效的时限，一般为24小时

​ renew_lifetime：表明凭证最长可以被延期的时限，一般为一个礼拜。当凭证过期之后，对安全认证的服务的 后续访问则会失败

[realms]：列举使用的realm

​ kdc：代表要kdc的位置。格式是 机器:端口

​ admin_server：代表admin的位置。格式是机器:端口

[domain_realm]：代表默认的域名

[kdcdefaults]
 kdc_ports = 88
 kdc_tcp_ports = 88

[realms]
 EXAMPLE.COM = { 
        
  #master_key_type = aes256-cts
  acl_file = /var/kerberos/krb5kdc/kadm5.acl
  dict_file = /usr/share/dict/words
  admin_keytab = /var/kerberos/krb5kdc/kadm5.keytab
  supported_enctypes = aes256-cts:normal aes128-cts:normal des3-hmac-sha1:normal 
  arcfour-hmac:normal camellia256-cts:normal camellia128-cts:normal 
  des-hmac-sha1:normal des-cbc-md5:normal des-cbc-crc:normal
 }

初始化并启动：完成上面两个配置文件后，就可以进行初始化并启动了

/usr/sbin/kdb5_util create -s -r EXAMPLE.COM

[-s]表示生成stash file，并在其中存储master server key（krb5kdc）

[-r]来指定一个realm name —— 当krb5.conf中定义了多个realm时才是必要的

保存路径为/var/kerberos/krb5kdc 如果需要重建数据库，将该目录下的principal相关的文件删除即可

在此过程中，我们会输入database的管理密码。这里设置的密码一定要记住，如果忘记了，就无法管理Kerberos server。

当Kerberos database创建好后，可以看到目录 /var/kerberos/krb5kdc 下生成了几个文件

kadm5.acl kdc.conf principal principal.kadm5 principal.kadm5.lock principal.ok

我们需要为Kerberos database添加administrative principals (即能够管理database的principals) —— 至少要添加1个principal来使得Kerberos的管理进程kadmind能够在网络上与程序kadmin进行通讯

在maste KDC上执行：

/usr/sbin/kadmin.local -q "addprinc admin/admin"

在KDC上我们需要编辑acl文件来设置权限，该acl文件的默认路径是 /var/kerberos/krb5kdc/kadm5.acl（也可以在文件kdc.conf中修改）。

Kerberos的kadmind daemon会使用该文件来管理对Kerberos database的访问权限。对于那些可能会对pincipal产生影响的操作，acl文件也能控制哪些principal能操作哪些其他pricipals。

我们现在为administrator设置权限：将文件/var/kerberos/krb5kdc/kadm5.acl的内容编辑为

*/admin@EXAMPLE.COM *

代表名称匹配*/admin@EXAMPLE.COM都认为是admin，权限是 *。代表全部权限

手动启动

service krb5kdc start
service kadmin start

设置开机自动启动

chkconfig krb5kdc on
chkconfig kadmin on

1、登录 kerberos

录到管理员账户: 如果在本机上，可以通过kadmin.local直接登录。其它机器的，先使用kinit进行验证

kadmin.local
Authenticating as principal admin/admin@EXAMPLE.COM with password.
kadmin.local:  

2、查看用户

kadmin.local ： listprincs

3、添加用户

kadmin.local ： addprinc test@EXAMPLE.COM

4、删除用户

kadmin.local ： delprinc test@EXAMPLE.COM

5、创建keytable文件 生成test用户的 keytab 文件到 /root/kerberos 目录(目录由自己随意指定)

ktadd -k /root/kerberos/test.keytab test

6、只导出用户keytab文件(并且不要修改密码) -norandkey

ktadd -k /root/kerberos/test.keytab -norandkey test

7、登录

kinit -kt /root/kerberos/test.keytab test

8、查看登录用户

klist

9、查看keytab文件

klist -ket /root/kerberos/test.keytab

10、注销

kdestroy