在过去的几年里，我不得不“偶尔”与 Heimdal / MIT Gssapi 合作进行 kerberos 身份验证。我必须构建一个应用程序，用作在 Linux 机器上运行的 Web 服务，并为在 Windows 和/或 Linux 桌面和工作站上运行的浏览器等客户端应用程序提供服务。肯定不是最容易驯服的野兽。最终在总结我的工作时，我可以记录下由于多维度的挑战而产生的困难。开始使用 gssapi 编程确实是一个挑战，因为文档很差，而且几乎不存在教程。谷歌搜索主要导致一些关于什么是 kerberos 的理论讨论，或者导致编写的内容假定您已经知道除了一些特定的语义问题之外的所有内容。
以前没有真正做过这样的 wiki，而且我肯定不是 GSSAPI 和 Kerberos 的权威，所以请善待，但除此之外，请贡献并纠正我的错误。网站编辑，我指望你做你的魔法;）
成功完成项目需要正确完成 3 件具体的事情：
- 测试环境的设置
- 设置库
- 你的代码
正如我已经说过的，这样的项目是野兽，只是因为这三个项目都没有放在任何地方的同一页面上。
好的，让我们从头开始。
新手 GSSAPI 不可避免的理论可帮助客户端应用程序为服务器提供凭据以权威地识别用户。非常有用，因为服务器应用程序可以根据用户的需要调整其提供的响应。因此，很自然地，客户端和服务器应用程序都必须进行 kerberized，或者正如某些人所说的 kerberos 感知的。
基于 kerberos 的身份验证要求客户端和服务器应用程序都是 Kerberos 领域的成员。KDC（Kerberos 域控制器）是管理领域的指定机构。Microsoft 的 AD 服务器是最常见的 KDC 示例之一，尽管您当然可以使用基于 *NIX 的 KDC。但可以肯定的是，如果没有 KDC，就根本没有 Kerberos 业务。加入域的台式机、服务器和工作站相互识别，只要它们都保持加入域。
对于您的初始实验，请在同一领域中设置客户端和服务器应用程序。尽管通过在这些领域的 KDC 之间创建信任，或者甚至合并来自互不信任的不同 KDC 的密钥表，Kerberos 身份验证当然也可以跨领域使用。您的代码实际上不需要任何更改来适应这种不同且听起来很复杂的场景。
Kerberos 身份验证基本上是通过“票证（或令牌）”工作的。当成员加入领域时，KDC 将“授予令牌”给他们每个人。这些令牌是独一无二的；时间和 FQDN 是这些票证的重要因素。
在您考虑代码的第一行之前，请确保您已正确完成以下两项：
陷阱#1设置开发和测试环境时，请确保所有内容都经过测试并作为 FQDN 处理。例如，如果您想检查连接，请使用 FQDN，而不是 IP 进行 ping。因此不用说，它们必须具有相同的 DNS 服务配置。
陷阱#2确保所有运行 KDC、客户端软件、服务器软件的主机系统具有相同的时间服务器。时间同步是一个人忘记的东西，在经历了很多头发分裂和头部撞击之后才意识到不对劲！
客户端和服务器应用程序都需要 kerberos 密钥表。因此，如果您的应用程序要在 *NIX 主机中运行，并且是 Microsoft 域的一部分，那么在我们开始查看 gss 编程的剩余准备步骤之前，您必须生成一个 kerberos 密钥表。
Kerberos 5 (krb5 1.0) 互操作性分步指南绝对是必读的。
GSS-API Programming Guide是一本极好的书签。
根据您的 *NIX 发行版，您可以安装用于构建代码的头文件和库。但是，我的建议是下载源代码并自己构建。是的，你可能不会一下子把它弄好，但这肯定是值得的。
陷阱#3确保您的应用程序在 Kerberos 感知环境中运行。我真的很难学会这一点，但也许是因为我不那么聪明。在我最初的 gssapi 编程斗争阶段，我发现 kerberos 密钥表对于让我的应用程序支持 kerberos 是绝对必要的。但我根本找不到任何关于如何在我的应用程序中加载这些密钥表的信息。你知道为什么？！！因为没有这样的api存在！！！因为：应用程序将在知道 keytab 的环境中运行。好的，让我简化一下：在将环境变量设置KRB5_KTNAME为存储密钥表的路径后，必须运行应该执行 GSSAPI / Kerberos 的应用程序。所以要么你做这样的事情：
export KRB5_KTNAME=<path/to/your/keytab>
或者在使用 gssapi 的代码的第一行运行之前充分利用在您的应用程序中setenv进行设置。KRB5_KTNAME
我们现在准备在应用程序的代码中做必要的事情。
我知道应用程序开发人员必须审查许多其他方面，才能编写和测试应用程序。我知道一些环境变量，这可能很重要。
任何人都可以进一步阐明这一点吗？