运行ktpass.exe后30分钟只能登录Kerberos服务

Question

我正在尝试对Apache服务器进行Kerberize，并允许创建的服务器主体登录到Active Directory。我遵循了许多在线教程中的一个，它似乎运行良好。我在项目的Linux方面，而公司IT在Windows端。

它为我提供了一个服务帐户和一个服务主体。在本例中，我将它称为HTTP/mysite.mycorp.com@MYCORP.COM，他们为我提供了一个用于上述主体的keytab文件，其中包括在AD服务器上运行一个名为ktpass.exe的工具。

我已经验证AD/KDC和keytab文件的KVNO是否匹配。平安无事。

主机名有正确的DNS A记录，IP有适当的PTR记录.两台服务器都处于时间同步状态。

我可以通过发出的keytab文件从AD/KDC请求上述服务主体的票证，如下所示：

kinit -k -t http.keytab HTTP/mysite.mycorp.com@MYCORP.COM

这个很管用。我获得了一张票证，并且我能够使用这个票据来查询AD/LDAP目录。keytab对于运行一个单点登录Apache站点也很有用，这也是本练习的部分目标。

半个小时过去了.

使用上面的kinit命令登录的尝试现在失败了，这条消息是：

Client not found in Kerberos database

我无法作为服务主体进行身份验证，就好像在AD服务器上删除了主体一样。

现在变得很奇怪，至少对我来说是这样：

根据请求，AD管理员再次运行ktpass.exe工具，为我的服务构建一个新的keytab文件。KVNO (密钥版本号)在服务器上增加，导致Apache测试服务器停止验证Kerberos单点登录。这是我目前的配置所期望的。令我们所有人惊讶的是，现在kinit命令又起作用了。我们又给自己买了半个小时，然后它又停止工作了。

我们的IT部门在这里不知所措，他们推测这是AD服务器本身的问题。我认为这是配置，但根据他们的说法，在他们的设置中没有半小时限制。

我遵循了http://www.grolmsnet.de/kerbtut/ (参见第7节)，但在我找到的所有文档中，方法似乎都是相同的。我没有发现任何关于服务主体的时间限制的参考。

编辑:这似乎是一个复制问题。虽然复制过程中没有报告错误，但是服务帐户的SPN值被更改(恢复？)30分钟后，从"HTTP/mysite.mycorp.com@MYCORP.COM“到”服务名称-帐户@mycorp.com“。

Answer 1

谢谢你们的意见，伙计们。我们让微软上船，他们帮助我们在AD端调试身份验证过程。一切照常进行，但三十分钟后就失败了。

当我们正在进行远程调试时，与会者注意到服务帐户的UPN/SPN突然从HTTP/mysite.mycorp.com@MYCORP.COM重发到service- account @mycorp.com。经过大量的研究，包括调试AD复制，我们发现了罪魁祸首：

有人做了一个定期运行的脚本(可能是通过事件运行，因为它是在运行ktpass.exe后30分钟)，它更新了UPN/PSN，以“确保云的连通性”。对于这样做的原因，我没有任何补充资料。

对脚本进行了修改，允许以@mycorp.com结尾的现有UPN/SPN值，有效地解决了这个问题。

用于调试问题的

提示如下：

• 确保身份验证的所有参与者都支持相同的加密类型。避免DES -这是过时的和不安全的。
• 确保在服务帐户上启用AES-128和AES-256加密。
• 请注意，在服务帐户上启用DES意味着“只对此帐户使用DES”，即使您启用了任何AES加密。搜索UF_USE_DES_KEY_ONLY以获得有关此方面的详细信息。
• 确保UPN/SPN值是currect，并匹配发出的keytab文件中的值(即通过LDAP查找)
• 确保keytab文件中的KVNO (键版本号)与服务器上的on匹配。
• 检查服务器和客户端之间的通信量(即使用tcpdump和/或WireShark)
• 在AD侧检查日志上启用身份验证调试
• 在AD侧检查日志上启用复制调试

再次感谢您的投入。

Answer 2

我还从Achim的mod_auth_kerb教程开始学习Kerberos，这是一篇很好的文档。

keytab文件仅替换密码身份验证。密码是在文件中编码的，这些字节用于使用KDC进行身份验证。服务帐户上的任何密码更改都将使keytab身份验证无效，并增加kvno号。

要确认服务帐户SPN可用，我通常使用服务帐户密码进行身份验证：

kinit HTTP/mysite.mycorp.com@MYCORP.COM

如果失败，要确认服务帐户未被禁用，请尝试基本身份验证：

kinit account

如果无法进行身份验证，只需删除该帐户并创建一个具有另一个登录名的新帐户，以避免麻烦。

另一种软件--例如，另一个具有相同SPN的旧密钥选项卡的系统--很有可能试图在此服务帐户上进行身份验证，并由于密码无效而禁用该帐户。

当设置Kerberos SSO时，太快的操作可能会导致Active中的不一致。当我停留在配置过程中时，我的一般指导方针是遵循以下步骤：

• 删除测试和生产系统的“旧”或“失败”服务帐户。
• 与kvno检查您希望配置的SPN不再存在于领域中。
• 与setspn -X检查多个帐户上没有冲突的SPN
• 为每个系统创建一个服务帐户，专用于一个完全合格的SPN，并具有全新的登录名。
• 防止服务帐户的密码更改和密码过期。
• 让我们等一段时间等待DC同步
• 生成密钥选项卡时将密码设置为ktpass选项
• 用setspn -l account检查FQDN和别名

下面是一组命令，用于在DC上配置服务帐户：

ktpass -princ HTTP/mysite.mycorp.com@MYCORP.COM -mapuser mysiteAccount@MYCORP.COM
  -crypto RC4-HMAC-NT -ptype KRB5_NT_PRINCIPAL
  -pass long!$longp2ass3word -out c:\temp\http-mysite-mycorp-com.keytab
setspn -a HTTP/mysite mysiteAccount
setspn -l mysiteAccount

如果在MMC和在管理命令行中运行ktpass以生成keytab的不同DC上完成的操作太快，那么DC同步可能会导致您所描述的意外结果。因此，让我们在创建帐户和ktpass以及任何其他setspn命令之间等待一段时间。

以及在Linux上运行以检查一切正常工作的命令：

kinit mysiteAccount@MYCORP.COM
kinit HTTP/mysite.mycorp.com@MYCORP.COM
kinit -k -t http-mysite-mycorp-com.keytab HTTP/mysite.mycorp.com@MYCORP.COM
kvno HTTP/mysite.mycorp.com
kvno HTTP/mysite