我们已经了解了Kerberos互操作性，下面我们将通过一些具体场景来核实它。注意，以下每一个身份验证和授权过程，在图一都已经叙述。

　　场景一： Windows域间环境

　　图3显示Windows域之间的身份验证。AMS.corp.net域中的客户端需要访问EMEA.corp.net域中的服务器资源。AMS.corp.net向客户端返回一个TGT请求，用于用户登录。由于应用服务器位于EMEA域中，AMS域控制器凭借着两个域间的信任关系，向EMEA域提交一个“远程”TGT请求。这个请求会被提交给EMEA的域控制器（TGS），同时，一个EMEA应用服务器的服务票证会返回给客户端。

图3：域间环境的授权过程

　　场景二：跨平台访问：Unix客户端访问windows资源

　　图4显示的场景与场景1几乎一样，唯一不同的是图中是UNIX客户端。 该客户端希望访问Windows域环境中服务器资源。请记住，在这个不同平台的环境里，Kerboeros只是协议而已，并不涉及平台的差异性。所以身份验证和授权的过程与场景1是一模一样的。MIT KDC会为Windows域生成一个远程TGT请求 (假设两个域间存在信任关系) 。该请求会被提交给Windows域控制器，控制器会返回一个服务票证，客户端使用该服务票证去访问需要访问的Windows应用服务器。唯一的问题就是Unix系统没有SID、GUID、Windows身份验证或组等概念。Windows提供了一个名称映射功能，允许在Unix域帐户映射到Windows帐户的SID、组成员身份和权限。这是在用户和计算机管理单元中的功能：高级功能－名称映射。过程如图5所示。帐户一对一或者一对多映射（一个Windows帐户，可以映射到多个Unix帐户）。在使用NFS访问系统之间的文件，该做法非常普遍。请注意，名称映射并不是总是必须的。

图4：使用Unix KDC

　　场景三：Unix/Linux提供域名保护服务

　　图5显示：Linux应用服务器为Windows客户端提供一个“域名保护服务”。以Samba为例。为了更好的叙述，我们做如下规定：

　　1.域中存在一个计算机帐户
　　2.krb5.conf文件- 这个文件可以让Windows KDC通过使用FQDN或IP地址来访问活动目录用户对象，用于TGT请求和Kerberos客户端。
　　3.krb5.keytab -加密的密钥存储服务，用于生成密钥，该密钥和计算机帐户用于加密和解密数据包的密钥一致。
　　4.Windows识别的服务。

　　当然，这里还有一个用于计算机帐户和应用服务器之间的共享密钥。用于该共享密钥的加密密钥与Windows服务器的计算机对象相关联，并保存在Unix/Linux服务器上的Keytab文件里。

图5：域名保护服务

　　Kerberos身份验证和授权对话过程。 请注意，因为服务票证由Windows KDC生成并由Windows客户端提交，所以该票证会包含Windows身份验证信息。这些信息是否使用取决于应用服务器在活动目录中的状态。

　　认识Kerberos协议是认识Windows环境下授权（登录）和认证（资源访问）的基础。由于许多组织使用Linux和Unix客户端和服务器，所以理解Kerberos如何提供不同平台的互操作性也非常重要。更多优秀文章请访问Kerberos 5指南。