我试图Kerberize一个Apache服务器，并允许创build的服务器主体login到Active Directory。 我已经在网上提供了众多的教程之一，它似乎工作正常。 我在项目的Linux方面，企业IT在Windows方面。
IT为我提供了一个服务帐户和一个服务负责人。 在这个例子中，我将它称为HTTP/[email protected]。 他们为我提供了一个keytab文件，用于在AD服务器上运行一个名为ktpass.exe的工具。
我已经validation了AD / KDC的KVNO和keytab文件相匹配。 一切都很好。
主机名有一个合适的DNS Alogging，IP有合适的PTRlogging。 两台服务器都在同步。
我可以通过发行的keytab文件从AD / KDC申请上述服务主体的票据，如下所示：
kinit -k -t http.keytab HTTP/[email protected] 这工作。 我获得一张票，我可以使用这张票来查询AD / LDAP目录。 keytab对于运行单点loginApache站点也很有效，这是本练习的目标之一。
半个小时过去了。
尝试使用上述kinit命令login失败，并显示以下消息：
Client not found in Kerberos database
我无法validation服务主体，就好像委托人在AD服务器上被删除一样。
现在它变得很奇怪，至less对我来说：
通过请求，ADpipe理员再次运行ktpass.exe工具，为我的服务构build一个新的keytab文件。 KVNO（密钥版本号）在服务器上递增，导致我们的Apachetesting服务器停止validationKerberos单点login。 这与我目前的configuration预计。 令我们惊讶的是，现在kinit命令再次运行。 我们又买了半个小时，然后又停了下来。
我们的IT部门在这里处于亏损状态，他们猜测这是AD服务器本身的一个问题。 我想这是configuration，但据他们说，在他们的设置任何地方都没有半小时的限制。
我遵循http://www.grolmsnet.de/kerbtut/ （请参阅第7节），但是在我find的所有文档中，这个方法似乎是一样的。 我没有发现任何提及服务负责人的时间限制。
编辑：这似乎是一个复制问题。 虽然在复制过程中没有报告错误，但服务帐户的SPN值是从“HTTP/[email protected]”更改（恢复？）“[email protected] “30分钟后。
我也学习了以Achim Grolms的mod_auth_kerb教程开始的Kerberos，真是一个很好的文档。
keytab文件只取代密码authentication。 密码被编码在文件中，这些字节用于KDCauthentication挑战。 服务帐户上的任何密码更改都将使密钥表authentication失效，并增加kvno编号。
要确认服务帐户SPN可用，我经常使用服务帐户密码进行身份validation：
kinit HTTP/[email protected]
如果失败，要确认服务帐户未被禁用，请尝试基本身份validation：
kinit account
如果没有通过身份validation，只需删除该帐户，并使用另一个login名创build一个新帐户以避免麻烦。
另一块软件（例如，另一个系统具有用于同一个SPN的旧生成的密钥表）尝试在此服务帐户上进行身份validation并由于密码无效而禁用该帐户的可能性很高。
设置Kerberos SSO时，操作太快可能会导致Active Directory中的不一致。 卡在configuration过程中的一般原则是遵循以下步骤：
kvno检查您希望configuration的SPN不再存在于域中 setspn -X检查多个帐户没有冲突的SPN ktpass选项 setspn -l account检查FQDN SPN和别名 以下是在DC上configuration服务帐户的一组命令：
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之间的不同DC上以太快的速度在pipe理命令行中生成密钥表生成，则DC同步可能会导致意外的结果，如所描述的结果。 所以让我们等待一段时间创build帐户，然后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
感谢您的所有意见，伙计们。 我们得到了微软的支持，他们帮助我们debugging了AD方面的authentication过程。 一切都按照预想的那样工作，但三十分钟后就失败了。
当我们进行远程debugging会话时，与会者注意到服务帐户的UPN / SPN突然从HTTP / [email protected]到[email protected] 。 经过很多挖掘，包括debuggingAD复制，我们发现罪魁祸首：
有人制作了一个定期运行的脚本（可能是事件，因为它正好运行ktpass.exe之后30分钟），UPN / PSN更新了“确保云连接” 。 我没有任何关于这样做的原因的补充信息。
该脚本已更改为允许以@ mycorp.com结尾的现有UPN / SPN值，从而有效地解决了该问题。
debugging这样的问题的提示：
再次感谢您的意见。