【消息B】：票据授权票据(TGT)（TGT包括：消息A中的“Client/TGS会话密钥”(Client/TGS Session Key)，用户ID，用户网址，TGT有效期），通过TGS密钥(TGS's secret key) 进行加密
一旦Client收到消息A和消息B，Client首先尝试用自己的“用户密钥”(user's secret key)解密消息A，如果用户输入的密码与AS数据库中的密码不符，则不能成功解密消息A。输入正确的密码并通过随之生成的"user's secret key"才能解密消息A，从而得到“Client/TGS会话密钥”(Client/TGS Session Key)。（注意：Client不能解密消息B，因为B是用TGS密钥(TGS's secret key)加密的）。拥有了“Client/TGS会话密钥”(Client/TGS Session Key)，Client就足以通过TGS进行认证了。
2.2.2 服务授权Client从TGS获取票据(client-to-server ticket)。
当client需要申请特定服务时，其向TGS发送以下2条消息：
【消息c】：即消息B的内容（TGS's secret key加密后的TGT），和想获取的服务的服务ID（注意：不是用户ID）
【消息d】：认证符(Authenticator)（Authenticator包括：用户ID，时间戳），通过Client/TGS会话密钥(Client/TGS Session Key)进行加密
收到消息c和消息d后，TGS首先检查KDC数据库中是否存在所需的服务，查找到之后，TGS用自己的“TGS密钥”(TGS's secret key)解密消息c中的消息B（也就是TGT），从而得到之前生成的“Client/TGS会话密钥”(Client/TGS Session Key)。TGS再用这个Session Key解密消息d得到包含用户ID和时间戳的Authenticator，并对TGT和Authenticator进行验证，验证通过之后返回2条消息：
【消息E】：client-server票据(client-to-server ticket)（该ticket包括：Client/SS会话密钥 (Client/Server Session Key），用户ID，用户网址，有效期），通过提供该服务的服务器密钥(service's secret key) 进行加密
【消息F】：Client/SS会话密钥( Client/Server Session Key) （该Session Key用在将来Client与Server Service的通信（会话）上），通过Client/TGS会话密钥(Client/TGS Session Key) 进行加密
Client收到这些消息后，用“Client/TGS会话密钥”(Client/TGS Session Key)解密消息F，得到“Client/SS会话密钥”(Client/Server Session Key)。（注意：Client不能解密消息E，因为E是用“服务器密钥”(service's secret key)加密的）。
2.2.3 服务请求Client从SS获取服务。
当获得“Client/SS会话密钥”(Client/Server Session Key)之后，Client就能够使用服务器提供的服务了。Client向指定服务器SS发出2条消息：
【消息e】：即上一步中的消息E“client-server票据”(client-to-server ticket)，通过服务器密钥(service's secret key) 进行加密
【消息g】：新的Authenticator（包括：用户ID，时间戳），通过Client/SS会话密钥(Client/Server Session Key) 进行加密
SS用自己的密钥(service's secret key)解密消息e从而得到TGS提供的Client/SS会话密钥(Client/Server Session Key)。再用这个会话密钥解密消息g得到Authenticator，（同TGS一样）对Ticket和Authenticator进行验证，验证通过则返回1条消息（确认函：确证身份真实，乐于提供服务）
【消息H】：新时间戳（新时间戳是：Client发送的时间戳加1，v5已经取消这一做法），通过Client/SS会话密钥(Client/Server Session Key) 进行加密
Client通过Client/SS会话密钥(Client/Server Session Key)解密消息H，得到新时间戳并验证其是否正确。验证通过的话则客户端可以信赖服务器，并向服务器（SS）发送服务请求。
服务器（SS）向客户端提供相应的服务。
3.Kerberos HA架构Kerberos支持两种服务器在域内冗余方式：Master/Slave（MIT和Heimdal）和Multimaster结构（Windows Active Directory）。在生产环境中部署Kerberos时，最好使用一主(Master)多从(Slave)的架构，以确保Kerberos服务的高可用性。
Kerberos中每个KDC都包含数据库的副本。主KDC包含域（Realm）数据库的可写副本，它以固定的时间间隔复制到从KDC中。所有数据库更改（例如密码更改）都在主KDC上进行，当主KDC不可用时，从KDC提供Kerberos票据给服务授权，但不提供数据库管理。KDC需要一个Admin来进行日常的管理操作。
Kerberos的同步机制只复制主数据库的内容，但不传递配置文件，以下文件必须手动复制到每个Slave中：
目前单机房HA方案使用的较多的是Keepalived + Rsync 。Keepalived可以将多个无状态的单点通过虚拟IP(以下称为VIP)漂移的方式搭建成一个高可用服务。