AS（Authentication Server）= 认证服务器
KDC（Key Distribution Center）= 密钥分发中心
TGT（Ticket Granting Ticket）= 票据授权票据，票据的票据
TGS（Ticket Granting Server）= 票据授权服务器
SS（Service Server）= 特定服务提供端
（注意：此流程使用了对称加密；此流程发生在某一个Kerberos领域中；小写字母c,d,e,g是客户端发出的消息，大写字母A,B,E,F,H是各个服务器发回的消息。）
首先，用户使用客户端（用户自己的机器）上的程序进行登录：
- 用户输入用户ID和密码到客户端。
- 客户端程序运行一个单向函数（大多数为杂凑）把密码转换成密钥，这个就是客户端（用户）的“用户密钥”(user’s secret key)。
随后，客户端认证（客户端(Client)从认证服务器(AS)获取票据授权票据（TGT））：
- 客户端向AS发送1条明文消息，申请基于该用户所应享有的服务，例如“用户Sunny想请求服务”（Sunny是用户ID）。（注意：用户不向AS发送“用户密钥”，也不发送密码）该AS能够从本地数据库中查询到该申请用户的密码，并通过相同途径转换成相同的“用户密钥”。
- AS检查该用户ID是否在于本地数据库中，如果用户存在则返回2条消息：
- 消息A：客户端/TGS会话密钥(Client/TGS Session Key)（该会话密钥用在将来客户端与TGS的通信（会话）上），通过“用户密钥”进行加密
- 消息B：TGT（TGT包括：消息A中的“客户端/TGS会话密钥”，用户ID，用户网址，TGT有效期），通过“TGS密钥”(TGS’s secret key)进行加密
- 一旦客户端收到消息A和消息B，客户端首先尝试用自己的“用户密钥”解密消息A，如果用户输入的密码与AS数据库中的密码不符，则不能成功解密消息A。输入正确的密码并通过随之生成的“用户密钥”才能解密消息A，从而得到“客户端/TGS会话密钥”。（注意：客户端不能解密消息B，因为B是用“TGS密钥”加密的）。拥有了“客户端/TGS会话密钥”，客户端就足以通过TGS进行认证了。
然后，服务授权（客户端从TGS获取票据(client-to-server ticket)）：
- 当客户端需要申请特定服务时，其向TGS发送以下2条消息：
- 消息c：即消息B的内容（“TGS密钥”加密后的TGT），和想获取的服务的服务ID（注意：不是用户ID）
- 消息d：认证符(Authenticator)（Authenticator包括：用户ID，时间戳），通过“客户端/TGS会话密钥”进行加密
- 收到消息c和消息d后，TGS首先检查KDC数据库中是否存在所需的服务，查找到之后，TGS用自己的“TGS密钥”解密消息c中的消息B（也就是TGT），从而得到之前生成的“客户端/TGS会话密钥”。TGS再用这个会话密钥解密消息d得到包含用户ID和时间戳的Authenticator，并对TGT和Authenticator进行验证，验证通过之后返回2条消息：
- 消息E：客户端-服务器票据(client-to-server ticket)（该票据包括：“客户端/SS会话密钥”(Client/Server Session Key），用户ID，用户网址，有效期），通过提供该服务的“服务器密钥”(service’s secret key)进行加密
- 消息F：客户端/SS会话密钥(Client/Server Session Key)（该会话密钥用在将来客户端与SS的通信（会话）上），通过“客户端/TGS会话密钥”进行加密
- 客户端收到这些消息后，用“客户端/TGS会话密钥”解密消息F，得到“客户端/SS会话密钥”。（注意：客户端不能解密消息E，因为E是用“服务器密钥”加密的）。
最后，服务请求（客户端从SS获取服务）：
- 获得“客户端/SS会话密钥”之后，客户端就能够使用服务器提供的服务了。客户端向指定SS发出2条消息：
- 消息e：即上一步中的消息E“客户端-服务器票据”，已通过“服务器密钥”进行加密
- 消息g：新的Authenticator（包括：用户ID，时间戳），通过“客户端/SS会话密钥”进行加密
- SS用自己的“服务器密钥”解密消息e从而得到TGS提供的“客户端/SS会话密钥”。再用这个会话密钥解密消息g得到Authenticator，（同TGS一样）对票据和Authenticator进行验证，验证通过则返回1条消息（确认函：确证身份真实，乐于提供服务）：
消息H：新时间戳（新时间戳是：客户端发送的时间戳加1，v5已经取消这一做法），通过“客户端/SS会话密钥”进行加密 - 客户端通过“客户端/SS会话密钥”解密消息H，得到新时间戳并验证其是否正确。验证通过的话则客户端可以信赖SS，并向SS发送服务请求。
- SS向客户端提供相应的服务。