我们知道Client通过在ASExchange阶段获得的TGT从KDC那么获得访问Server的Ticket。原来的Ticket是通过Server的Master Key进行加密的,而这个Master Key可以通过AccountDatabase获得。但是现在KDC需要使用Server和KDC之间的SKDC-Server进行加密,而KDC是不会维护这个Session Key,所以这个Session Key只能靠申请Ticket的Client提供。所以在AS Exchange和TGSExchange之间,Client还得对Server进行请求已获得Server和KDC之间的Session Key(SKDC-Server)。而对于Server来说,它可以像Client一样通过ASExchange获得他和KDC之间的SessionKey(SKDC-Server)和一个封装了这个Session Key并被KDC的Master Key进行加密的TGT,一旦获得这个TGT,Server会缓存它,以待Client对它的请求。我们现在来详细地讨论这一过程。
上图基本上翻译了基于User2User的认证过程,这个���程由4个步骤组成。我们发现较之我在上面一节介绍的基于传统3个Sub-protocol的认证过程,这次对了第2部。我们从头到尾简单地过一遍:
AS Exchange:Client通过此过程获得了属于自己的TGT,有了此TGT,Client可凭此向KDC申请用于访问某个Server的Ticket。
这一步的主要任务是获得封装了Server和KDC的Session Key(SKDC-Server)的属于Server的TGT。如果该TGT存在于Server的缓存中,则Server会直接将其返回给Client。否则通过AS Exchange从KDC获取。
TGS Exchange:Client通过向KDC提供自己的TGT,Server的TGT以及Authenticator向KDC申请用于访问Server的Ticket。KDC使用先用自己的Master Key解密Client的TGT获得SKDC-Client,通过SKDC-Client解密Authenticator验证发送者是否是TGT的真正拥有者,验证通过再用自己的Master Key解密Server的TGT获得KDC和Server 的SessionKey(SKDC-Server),并用该Session Key加密Ticket返回给Client。
C/S Exchange:Client携带者通过KDC和Server的Session Key(SKDC-Server)进行加密的Ticket和通过Client和Server的SessionKey(SServer-Client)的Authenticator访问Server,Server通过SKDC-Server解密Ticket获得SServer-Client,通过SServer-Client解密Authenticator实现对Client的验证。
kerberos安装及使用方法
具体安装过程不详述。仅说明几点需要注意的地方。
Realm
Realm是kerberos中“域”的概念。通常,一个主KDC管辖一个域。在一个intranet中,通常都是使用一个域名,例如example.com,这种情况下,域的名称就被设为域名的大写形式EXAMPLE.COM。
如果你有多个域,MIT建议使用易于记忆的形式,例如LOCATION.EXAMPLE.COM。
Principal
Kerberos中的principal即上文所提到的申请ticket时用到的唯一身份标识。总体来说,有两大类不同的principal。
用户principal的一般形式是user@EXAMPLE.COM。如果用户是管理员,那么一般形式为user/admin@EXAMPLE.COM。
服务principal的一般形式是service/location.example.com@EXAMPLE.COM。
其他类型的principal,较少用到。
Database
Kerberos的主KDC上有一个管理用户的数据库,这个数据库只存在于主KDC,只能由管理员来管理。数据库主要用来添加删除principal等重要管理工作。
下图示例了如何建立一个kerberos database,注意域的名称是EXAMPLE.COM:
shell%/usr/local/sbin/kdb5_util create -r EXAMPLE.COM -s
Initializing database'/usr/local/var/krb5kdc/principal' for
⇒ realm ' EXAMPLE.COM',
master key name 'K/M@ EXAMPLE.COM'
You will be prompted for the databaseMaster Password.
It is important that you NOT FORGET thispassword.
Enter KDC database master key: <= Type the master password.
Re-enter KDC database master key toverify: <= Type it again.
shell%
ACL
Kerberos的ACL不用于我们要应用到分布式计算系统中的ACL。ACL(Access Control List)在这里的作用是用于限定一台装有kerberos服务的机器上,何种principal对kerberos数据库做何种操作。
ACL文件的路径和名称在kdc.conf中配置。默认路径和名称为/usr/local/var/krb5kd/ kadm5.acl。ACL文件对kerberos的安全性有很重要的作用,所以建议只有root权限可以修改该文件。
ACL文件格式为:
Kerberos_principal permissions [target_principal] [restrictions]
Kerberos_principal和target_principal两项可以使用‘*’号作为通配符。例如对所有具有admin权限的principal给予对数据库所有操作的权限,可以使用‘*/admin@EXAMPLE.COM’的方法。
Permission选项分别限制数据库的以下操作:‘admcils’对数据库的操作分别是“添加、删除、修改、更换密码、查询、列出所有、允许对principal显式设置key”,上述英文字母的大写形式表示禁止这种权限。
Keytab