主页 / server / 问题 / 715891
Accepted
Saustrup
Asked: 2015-08-22 11:33:32 +0800 CST

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

  • 772

我正在尝试对 Apache 服务器进行 Kerberize，并允许创建的服务器主体登录到 Active Directory。我遵循了在线提供的众多教程之一，它似乎工作正常。我在项目的 Linux 端，企业 IT 在 Windows 端。

IT 为我提供了一个服务帐户和一个服务主体。在本例中，我将其称为 HTTP/[email protected]。他们为我提供了该主体的密钥表文件，其中涉及在 AD 服务器上运行一个名为 ktpass.exe 的工具。

我已验证 AD/KDC 的 KVNO 和 keytab 文件匹配。一切都很好。

主机名有适当的 DNS A 记录，IP 有适当的 PTR 记录。两台服务器时间同步。

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

kinit -k -t http.keytab HTTP/[email protected]

这行得通。我获得了一张票，我可以将这张票用于查询 AD/LDAP 目录之类的事情。keytab 也适用于运行 Single Signon 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 值已从“HTTP/[email protected]”更改（恢复？）为“[email protected]” " 30 分钟后。

linux

2 个回答

  1. Best Answer

    感谢您的所有投入，伙计们。我们让微软参与进来，他们帮助我们调试了 AD 端的身份验证过程。一切都按预期进行，但三十分钟后失败了。

    在我们进行远程调试会话时，其中一位参与者注意到服务帐户的 UPN/SPN 突然从HTTP/[email protected]重新设置为[email protected]。经过大量挖掘，包括调试 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 值是正确的并且与颁发的 keytab 文件中的值匹配（即通过 LDAP 查找）
    • 确保 keytab 文件中的 KVNO（密钥版本号）与服务器上的 on 匹配
    • 检查服务器和客户端之间的流量（即使用 tcpdump 和/或 WireShark）
    • 在 AD 端启用身份验证调试 - 检查日志
    • 在 AD 端启用复制调试 - 检查日志

    再次感谢您的意见。

    • 1

  2. 我还从 Achim Grolms 的mod_auth_kerb教程开始学习了 Kerberos，这确实是一个很好的文档。

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

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

    kinit HTTP/[email protected]

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

    kinit account

    如果验证失败，只需删除该帐户并使用另一个登录名创建一个新帐户即可避免麻烦。

    另一个软件（例如具有旧生成的相同 SPN 的密钥表的另一个系统）很有可能尝试在此服务帐户上进行身份验证，并由于密码无效而禁用该帐户。

    设置 Kerberos SSO 时，过快的操作可能会导致 Active Directory 中的不一致。当卡在配置过程中时，我的一般准则是遵循以下步骤：

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

    以下是在 DC 上配置服务帐户的一组命令：

    ktpass -princ HTTP/[email protected] -mapuser [email protected]
  -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 [email protected]
kinit HTTP/[email protected]
kinit -k -t http-mysite-mycorp-com.keytab HTTP/[email protected]
kvno HTTP/mysite.mycorp.com
kvno HTTP/mysite
    • 0

相关问题