我们知道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