网络身份认证——Kerberos配置及认证

教材：《信息系统安全概论》

实验目的

Windows域下kerberos的实现，对用户是否透明，尽可能多的描述细节。
学习Kerberos的安装和配置方法，掌握和了解Kerberos的工作原理和实现原理，使用Kerberos实现网络身份认证。

实验要求

1）阅读教材4.6节内容，分别说明客户机与三类服务器所需完成的任务及以及这种身份认证方式的优缺点。

2）在Kerberos服务端，查询KDC的配置文件，说明KDC支持的加密方式有哪些？

3）使用命令# man kadmin或查阅MIT Kerberos官方命令手册，说明在配置服务端时步骤3涉及语句的含义。

4）安装配置完毕后，分别在客户端和服务端输入klist命令，输出结果是什么，说明其含义。

实验环境

VMware Workstation Pro + Ubuntu 16.04

--备注：可以在虚拟机中开启克隆，就可以实现在一台机上控制服务端/客户端的功能。

实验内容

一、客户机与三类服务器所需完成的任务，及优缺点

Kerberos认证机制如图

1.1 Authentication
客户机：提供用户名和口令，向AS传输户名。
身份认证服务器AS：验证收到的用户名的合法性，将加密处理后的通行证和会话密钥用该合法用户对应的正确口令传回给客户机。

1.2 Grant
客户机：合法用户已经通过口令解锁成功，得到会话密钥(ticket)，向grant服务器提供ticket加密的服务请求和身份认证的时候得到的通行证
审批服务器Grant：验证通行证和服务请求的合法性，合法则发放会话密钥2和服务卡(第二张ticket)

1.3 Service
客户机：得到grant提供的服务卡，向SS发送会话密钥2加密的服务卡和启动服务的请求。
应用服务器SS：检验启动服务请求和服务卡的合法性，若合法则启动服务。

1.4优点

1）性能较高

一旦Client获得用于访问某个Server的票据，则该Server就能根据票据实现对Client的验证，不再需要KDC（身份认证机制）的参与

2）实现了双向验证（Mutual Authentication）

传统的NTLM认证基于这样一个前提：Client访问的远程的Service是可信的、无需对于进行验证，所以NTLM不曾提供双向验证的功能————这显然有点理想主义，为此Kerberos弥补了这个不足：Client在访问Server的资源之前，可以要求对Server的身份执行认证。

3）互操作性（Interoperability）

Kerberos最初由MIT首创，现在已经成为一行被广泛接受的标准。所以对于不同的平台可以进行广泛的互操作。

1.5 缺点
1）Kerberos身份认证采用的是对称加密机制，加密和解密使用相同的密钥，安全性有所降低
2）Kerberos中身份认证服务和票据授权服务是集中式管理的，容易形成瓶颈，且系统的性能和安全性也过分依赖于这两个服务的性能和安全。

二、在Kerberos服务端，查询KDC的配置文件

涉及加密方式的信息如下
master_key_type = des3-hmac-sha1
用于控制加密主体数据库中各项的主密钥的加密类型

supported_enctypes = aes256-cts:normal arcfour-hmac:normal
des3-hmac-sha1:normal des-cbc-crc:normal des:normal des:v4 des:norealm
des:onlyrealm des:afs3
复制代码

supported_enctypes将指定 kadmin addprinc
在为特定领域创建主体时使用的加密类型的缺省集。如果 Kerberos 领域中的大多数系统都支持缺省加密类型集的子集，则应使用 supported_enctypes 参数
详细解释参考 https://docs.oracle.com/cd/E19253-01/819-7061/6n91j2ver/index.html

三、配置服务端时步骤3涉及语句的含义

步骤3.添加主体principal

# sudo kadmin.local
复制代码

进入kerberos管理页面，有两种方式：
在Krb5 server所在机器并且当前用户是root的话，可以使用kadmin.local免密码进入；当前用户是非root用户或在其他机器上时，可以使用kadmin $admin_user进入，需要输入此admin用户的密码

kadmin.local: addprinc admin/admin
复制代码

添加 principal:admin，这里之后要输入两次密码，用于客户端登录

kadmin.local: ktadd -k /etc/kadm5.keytab kadmin/admin kadmin/changepw
复制代码

kadmin: ktadd [-e enctype] [-k keytab] [-q] [principal | -glob principal-exp] 将服务主体添加至密钥表文件
本命令行中，kadmin/admin 和 kadmin/changepw 主体被添加至主 KDC 的密钥表文件。对于该示例，密钥表文件必须是在 kdc.conf 文件中指定的文件。

kadmin.local: addprinc -randkey ftp/服务器域名	
复制代码

addprinc [options] <new_principal> -randkey
为新添加的principal生成一个随机密码。注意如果为principal生成一个随机密码，那么必须要将生成的随机密码放在keytab文件中才能使用

kadmin.local: ktadd -k /etc/ftp.keytab ftp/服务器域名
复制代码

同上，将ftp/服务器域名 添加至ftp.keytab

kadmin.local: quit
复制代码

退出kadmin

更多内容参考docs.oracle.com/cd/E19683-0…

四、客户端和服务端输入klist命令，说明输出结果及其含义

客户端忘记截图
服务端截图如下

实际上二者并没有什么太大的区别

Klist用于显示 Kerberos 凭证高速缓存或密钥表的内容，可以理解为查看当前会话状态。在不输入任何参数的时候，表示列出在缺省凭证高速缓存中的所有条目。

实验遇到的问题及解决方案

实验过程中在服务端和客户端都出现了问题，分别罗列如下：

1. 服务端

1.1在配置环境中间出错，不小心在客户端输入服务端的配置内容
使用sudo apt-get autoremove --purge krb5-kdc krb5-admin-server卸载重装。

1.2 按照步骤走完之后多次出现can not connect 的报错_
之后又出现 kinit:资源暂时不可用while getting initial credentials 的报错，但是ping 得通 报错如图

经过一系列挣扎，在即将放弃的时候发现，需要对__krb5.conf__文件进行修改，先在__[libdefaults]中设置__default_realm = realm_janet129
然后在__[domain_realm]__中设置自己的domain

最后在hosts中添加一行
192.168.145.129 realm_janet129 janet IP地址+服务器域名+主机名

2．客户端

问题与服务端大致相同，但修改的位置不太一样
修改hosts之后，找不到目标服务器

一番商讨之后，我觉得应该是初始安装的时候,没有要我配置服务器域名等初始设置导致的，这个步骤被忽略的主要原因，怀疑是之前卸载的时候没有卸载完全，内存或硬盘中还有对应配置的缓存，所以按照之前的配置方式走了。

在__conf__文件中修改两步：

 [libdefaults]
	    default_realm = realm_janet129
复制代码

以及__[realms]__中添加属于自己服务器的配置内容

[realms]	
realm_janet129 = {
		kdc = janet
		admin_server = janet
}
···
复制代码