Linux|系统管理|WEB开发

关注Linux,系统管理,WEB开发以及开源世界

Kerberos 认证配置

| Comments

第一部分 Kerberos 协议介绍

在希腊神话中，Kerberos是守护地狱之门的三头狗。在计算机世界里，美国麻省理工学院(MIT)把他们开发的这一网络认证系统命名为 Kerberos。 Kerberos认证协议是由美国麻省理工学院(MIT)在80年代首先提出并实现的,是该校Athena计划的一部分。

因为Kerberos是一个三方 认证协议，根据称为密匙分配中心（KDC）的第三方服务中心来验证网络中计算机相互的身份，并建立密匙以保证计算机间安全连接。Kerberos协议基本 上是可行的并且有效的。KDC有两个部分组成：认证服务器AS和票据授权服务器TGS。Kerberos是一种网络认证协议，允许一台计算机通过交换加密 消息在整个非安全网络上与另一台计算机互相证明身份。一旦身份得到验证，Kerberos协议将会给这两台计算机提供密匙，以进行安全通讯对话。 Kerberos协议可以认证试图等录上网用户的身份，并通过使用密匙密码为用户间的通信加密。总的来说，Kerberos 是一种基于私钥加密算法的，需要可信任的第三方作为认证服务器的网络认证系统。它允许在网络上通讯的实体互相证明彼此的身份，并且能够阻止旁听和重放等手 段的攻击。不仅如此，它还能够提供对通讯数据保密性和完整性的保护。

Kerberos从提出到今天，共经历了五个版本的发展。其中版本1到版本3主要由该校内部使用。当它发展到版本4的时候，已经取得了在MIT校园外的广 泛认同和应用。由于版本4的传播，人们逐渐发现了它的一些局限性和缺点（例如适用网络环境有限, 加密过程存在冗余等等）．MIT充分吸收了这些意见，对版本4进行了修改和扩充，形成了今天非常完善的版本5。现在可以MIT提供的Kerberos V5的最新实现是版本krb5 1.3.3，本文中提到的实现都是以它为依据的。

第二部分 Kerberos协议术语解释

Principal：在Kerberos中，Principal是参加认证的基本实体。一般来说有两种，一种用来表示Kerberos数据库中的用户，另 一种用来代表某一特定主机，也就是说Principal是用来表示客户端和服务端身份的实体, Principal的格式采用ASN.1标准,即Abstract Syntax Notation One，来准确定义)，Principal是由三个部分组成：名字（name），实例（instance），REALM（域）。比如一个标准的 Kerberos的用户是：name/instance@REALM 。

Name：第一部分。在代表客户方的情况，它是一个用户名；在代表主机的情况，它是写成host。

Instance：第二部分。对name的进一步描述，例如name所在的主机名或name的类型等,可省略。它与第一部分之间用‘ / ’分隔，但是作为主机的描述时写成host/Instance。

Realm：第三部分。是Kerberos在管理上的划分，在 KDC中所负责的一个域数据库称作为Realm。这个数据库中存放有该网络范围内的所有Principal和它们的密钥，数据库的内容被Kerberos 的认证服务器AS和票据授权服务器TGS所使用。Realm通常是永远是大写的字符,并且在大多数Kerberos系统的配置中，一般Realm和该网络 环境的DNS域是一致的。与第二部分之间用‘@’分隔，缺省为本地的Realm。

比如，Principal “ cnhawk/hawk.the9.com@THE9.COM ” 表示Realm “ THE9.COM ”中主机hawk.the9.com上的用户cnhawk ，而Principal “ host/hawk.the9.com @THE9.COM ” 则通常用来表示Realm “ THE9.COM”中主机hawk.the9.com。

Credential： Ticket和与它相联系的会话密钥合在一起称为Credential。之所以有这个概念是因为它们是客户端在向服务器证明自己的身份时必需的两样东西． 在一个Ticket的生存期内客户端会将这两样东西以Credential为单位保存在一个Cache文件中。

Ticket：一个Ticket是一个用于安全的传递用户身份所需要的信息的集合。它不仅包含该用户的身份，而且包含其它一些相关的信息。一般来说，它主 要包括客户方 Principal，目的服务方Principal，客户方IP地址，时间戳（分发该Ticket的时间），该Ticket的生存期，以及会话密钥等内 容。它的格式亦用ASN.1来准确定义。

Authenticator: 在客户端向服务端进行认证时，伴随Ticket一起发送的另外一个部分，它的作用是证明发送Ticket 的用户就是拥有Ticket的用户，即防止重放攻击。它的主要内容是一个时间戳（客户端发送Ticket的时间），在rfc1510中有它的完整的 ASN.1定义。

AS(Authentication Server)： 为用户分发TGT(Ticket Granting Ticket)的服务器。

TGT(Ticket Granting Ticket)： 用户向TGS(Ticket Granting Server)证明自己身份的Ticket.

TGS(Ticket Granting Server)：为用户分发到最终目的Ticket的服务器，用户使用这个Ticket向自己要求提供服务的服务器证明自己的身份。在实现上，AS和 TGS实际上是由同一程序完成的，因为它们的实现机制并没有太大的差别，只是在加密所发出的Ticket时所使用的密钥不同（AS使用用户的密钥，而 TGS使用会话密钥）。

KDC(Key Distribution Center)：密钥发放中心，通常将AS和TGS统称为KDC，有时也把AS 单独称为KDC。

第三部分 认证过程

1) Client → KDC：用户cnhawk向密钥分配中心（KDC）申请TGT；

2) KDC → Client：通过KDC的用户密码认证，cnhawk得到KDC发放的TGT；

3) Client → KDC：申请取得用户cnhawk所需要的host/s；

4) KDC → Client：KDC根据用户cnhawk提供的TGT，KDC向cnhawk发放host/s；

5) Client → Server：用户cnhawk向Server提供cnhawk，TGT和host/s ；Server根据主机的上保存的host/s和用户cnhawk的信息来验证cnhawk的登陆申请。

6) Server → Client：Server确认，发送信息给Client允许cnhawk登陆Server。

第四部分 实例配置

下面我们看看怎么在RedFlag DC5.0上实现这个功能，客户端是RedFlag DT5.0,FC4 和RedFlag 4.1Plus服务端配置：

1、需要的软件包

krb5-server
krb5-libs
krb5-workstation
pam_krb5

2、应用环境：
DNS域名： rfkrb.com   172.16.81.195
kerberos的realm：RFKRB.COM
kdc服务器：kdc.rfkrb.com 172.16.81.195
kadmin服务器：kadmin.rfkrb.com 172.16.81.195

应用服务器：mlsxdemo.rfkrb.com 172.16.81.195 mlsx.rfkrb.com 172.16.81.196 fante.rfkrb.com 172.16.81.193

3.确定 realm
realm是大小写敏感的，在网络中必须是唯一的。一般来说，通常使用全部大写的用户2级域名作为realm。在同一个kerberos服务器中可以有多个realm。在确定realm时应该考虑用户的整个网络。例如，如果用户有一个单独的办公室，应该把他们作为独立的realm。Kerberos realm拓扑应该反映用户的组织结构拓扑。

4.配置服务器

下面这个文件你需要修改：
/etc/krb5.conf

 简单的说，修改系统自带的文件，把”EXAMPLE.COM”改为你用的realm；把”example.com”改为你所用的dns domain。

/var/kerberos/krb5kdc/kdc.conf
 简单的说，修改系统自带的文件，把”EXAMPLE.COM”改为你用的realm。默认的加密算法是des3-hmac-sha1。

/var/kerberos/krb5kdc/kadm5.acl

 简单的说，修改系统自带的文件，把”EXAMPLE.COM”改为你用的realm。这样，给所有”/admin”的principal 全部权限。

 创建kerberos数据库
/usr/kerberos/sbin/kdb5_util create -s

 创建管理用户 admin:

 可以在KDC服务器运行 kadmin.local管理kerberos数据库。输入”?”可以列出所有命令。用addprinc增加principal。

# kadmin.local     
kadmin.local: addprinc admin/admin    
kadmin.local: listprincs

启动服务：

   chkconfig kadmin on    
   chkconfig krb5kdc on    
   /etc/init.d/kadmin start    
   /etc/init.d/krb5kdc start

为用户和服务创建principal
 添加用户：在kadmin或kadmin.local中运行
  kadmin.local:    addprinc mlsx

应用服务器

 kerberos并不是所有网络服务器都支持kerberos。kerberos-workstation提供的多个支持kerberos的常用的网络服务，包括telnet, ftp, rsh, rlogin。

 openssh声称可以支持kerberos，但是我的测试结果很奇怪，有的服务器可以，有的不行。我不清楚是什么原因。

 支持pam认证的服务软件，可以通过pam使用kerberos。但是这种情况下，只能实现统一用户认证，不能实现单点登录。也就是说，每次登录都需要输入用户名和密码。（对此我没有作过测试）
修改用户认证方式

运行authconfig，在Authentication栏选中”Use Kerberos”。选Next，配置kerberos。authconfig会自动修改 /etc/pam.d/system-auth和/etc/krb5.conf。也可以把kerberos服务器中的/etc/krb5.conf拷贝过来。

 添加服务：任何一个网络服务，如果能接受Kerberos的认证，必须在KDC中添加一个服务principal，并且保存在本地的keytab。默认的keytab是/etc/krb5.keytab。服务和principal的对应关系是：

 OpenSSH, pam_krb5  host/hostname    
 LDAP  ldap/hostname    
 NFS  nfs/hostname    
 keytab的重要性与用户口令相似，注意保护。应该只允许root读。创建keytab的方法是：在服务器上运行    
kadmin -p admin/admin    
  addprinc -randkey host/mlsxdemo.rfkrb.com

  ktadd host/mlsxdemo.rfkrb.com   addprinc -randkey host/mlsx.rfkrb.com    ktadd host/mlsx.rfkrb.com

时间同步

 kerberos认证的安全性部分基于ticket的时间戳。所以客户机的时间与kerberos服务器同步是非常重要的。默认情况下，客户机与kerberos服务器间的时间差必须小于300秒。

 一般情况下，可以使用ntp进行时间同步。系统默认的配置将从internet上获得时间。如果希望直接从kerberos服务器获得时间，可以：
1. 修改kerberos服务器的/etc/ntp.conf: 增加一行：
restrict 172.16.80.0 mask 255.255.248.0 nomodify notrap
2. 在客户端运行
ntpdate kdc.rfkrb.com
或者修改 /etc/ntp.conf，把ntp server设置为kerberos server
server kdc.rfkrb.com

客户端配置

客

Comments