☰

Kerberos 服務登入只能在執行 ktpass.exe 後 30 分鐘內進行

tag-icon • tag-icon linux active-directory kerberos
Kerberos 服務登入只能在執行 ktpass.exe 後 30 分鐘內進行

我正在嘗試對 Apache 伺服器進行 Kerberize 處理，並允許已建立的伺服器主體登入 Active Directory。我遵循了網上提供的眾多教程之一，它似乎工作得很好。我負責專案的 Linux 端，而企業 IT 負責 Windows 端。

IT 部門為我提供了一個服務帳戶和一個服務主體。在此範例中，我將其稱為 HTTP/[電子郵件受保護]。他們為我提供了該主體的金鑰表文件，其中涉及在 AD 伺服器上運行一個名為 ktpass.exe 的工具。

我已驗證 AD/KDC 的 KVNO 與密鑰表檔案是否匹配。一切都很好。

主機名稱有正確的 DNS A 記錄，IP 也有正確的 PTR 記錄。兩台伺服器時間同步。

我可以使用已發布的金鑰表檔案從 AD/KDC 請求上述服務主體的票證，如下所示：

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

這有效。我獲得了一張票證，並且可以使用這張票證進行查詢 AD/LDAP 目錄等操作。 keytab 也非常適合執行單一登入 Apache 站點，這也是本練習的部分目標。

半小時過去了。

現在嘗試使用上述 kinit 命令登入失敗並顯示以下訊息：

Client not found in Kerberos database

我無法作為服務主體進行身份驗證，就像主體已在 AD 伺服器上刪除一樣。

現在它變得很奇怪，至少對我來說：

根據請求，AD 管理員再次執行 ktpass.exe 工具，為我的服務建立一個新的金鑰表檔案。 KVNO（金鑰版本號）在伺服器上遞增，導致我們的 Apache 測試伺服器停止驗證 Kerberos 單一登入。這是我目前的配置所預期的。令我們所有人驚訝的是，現在 kinit 指令又起作用了。我們又為自己爭取了半個小時，然後它又停止工作了。

我們的IT部門對此感到茫然，他們猜測這是AD伺服器本身的問題。我認為這是配置，但根據他們的說法，他們的設置中的任何地方都沒有半小時限制。

我已經關注了http://www.grolmsnet.de/kerbtut/（請參閱第 7 節）但我找到的所有文件中的方法似乎都是相同的。我沒有找到任何關於服務主體時間限制的參考。

編輯：這似乎是一個複製問題。雖然複製過程中沒有報告錯誤，但服務帳戶的 SPN 值從「HTTP/[電子郵件受保護]“ 到 ”[電子郵件受保護]“30分鐘後。

答案1

謝謝你們的意見，夥伴們。我們邀請了 Microsoft，他們幫助我們調試 AD 端的身份驗證過程。一切都如預期進行，但三十分鐘後失敗了。

當我們進行遠端偵錯會話時，其中一位參與者註意到服務帳戶的 UPN/SPN 突然從HTTP/[電子郵件受保護]到[電子郵件受保護]。經過大量挖掘（包括調試 AD 複製），我們找到了罪魁禍首：

有人製作了一個定期運行的腳本（或者可能透過事件運行，因為運行 ktpass.exe 後恰好是三十分鐘），該腳本將 UPN/PSN 更新為“確保雲端連線”。我沒有任何關於這樣做的原因的補充資訊。

腳本已變更為允許以以下結尾的現有 UPN/SPN 值@mycorp.com，有效解決問題。

調試此類問題的提示：

  • 確保身份驗證的所有參與者都支援相同的加密類型。避免使用 DES——它已經過時且不安全。
  • 確保在服務帳戶上啟用 AES-128 和 AES-256 加密
  • 請注意，在服務帳戶上啟用 DES 意味著“此帳戶僅使用 DES”，即使您啟用了任何 AES 加密。搜尋一下UF_USE_DES_KEY_ONLY有關詳細資訊。
  • 確保 UPN/SPN 值正確並且與頒發的 keytab 檔案中的值相符（即透過 LDAP 查找）
  • 確保密鑰表檔案中的 KVNO（密鑰版本號）與伺服器上的 KVNO（密鑰版本號）匹配
  • 檢查伺服器和客戶端之間的流量（即使用 tcpdump 和/或 WireShark）
  • 啟用 AD 端身份驗證偵錯 - 檢查日誌
  • 在 AD 端啟用複製調試 - 檢查日誌

再次感謝您的意見。

答案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 之間的不同 DC 上的操作完成得太快，並在管理命令列中執行 ktpass 來產生金鑰表，則 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

相關內容