2016-11-23 62 views
0

用戶的密碼和salt決定了由ktpass生成的Kerberos密鑰。我注意到ktpass有時會改變用戶的鹽分,但有時候不會。通過捕獲kinit的包跡,我能夠發現鹽。鹽似乎是基於Kerberos領域和userPrincipalName生成的。但是,這並不簡單。如果以後手動更新UPN,鹽不會更新。 (我懷疑是否/mapop選項指定可以起到一定的作用。)ktpass如何和何時設置鹽?

  1. 在什麼情況下ktpass設置用戶的鹽?
  2. 鹽是如何確定的?
  3. 鹽是儲存在AD中,還是存儲在KDC中?
  4. 是否有直接的方法來讀取鹽的當前值?
  5. 有沒有辦法手動改變鹽?

回答

1
  1. 在Microsoft Windows Active Directory中,因爲它在Windows 2000年成立以來已使用使用Kerberos v5,該ktpass命令自動設置鹽。在Kerberos v5中使用的鹽總是。在Kerberos v4中,從未使用鹽。
  2. 完整的主體名稱(包括領域)用作salt,例如accountname/[email protected],然後將其與密碼的加密哈希配對,以絕對確保結果在整個AD森林。
  3. 如上所述,鹽是完整的主要名稱(包括領域)。它存儲在ntds.dit文件中,該文件是Active Directory數據庫。 KDC在由kdcsvc.dll產生的進程中得到啓動 - 並且它與存儲在ntds.dit中的值有關。因此,儘管KDC和AD數據庫在運行時環境中不是一個完全相同,但它們可以說是「隨時加入」的。我認爲,當域控制器關閉時,KDC內的所有重要元素都會在ntds.dit內部持續存在。微軟並沒有提供如何完成的確切細節。我已經廣泛地研究過,而且我的部分知識來源於仔細研究和推論,這些推理是從網絡上發現的文章中得到的。請注意,ntds.dit數據庫也是LDAP數據庫。如果DNS是AD集成的,它也是DNS數據庫。所有這些協議一起工作,再加上一些,形成「Active Directory」。
  4. 打開Active Directory用戶和計算機,轉到帳戶選項卡。 「用戶登錄名」是「閱讀」鹽的最直接的方式。你沒有看到領域名稱與它連接在一起,但它是隱含的。如果還定義了SPN,則以直觀的方式列出,如您在「屬性編輯器」選項卡(查找servicePrincipalName)下查找的那樣。確保您選擇了「查看」>「高級功能」以公開此選項卡。相應的UPN也將在同一部分中以較低的順序列出,形式如下:accountname/[email protected]
  5. 當您更改AD帳戶選項卡上的帳戶名稱時,您剛剛更改了鹽。請注意,如果有與此AD帳戶關聯的密鑰表,您將剛剛使其失效,因爲其中的密鑰是密碼哈希和salt的結合。當鹽或密碼更改時,密鑰將不再在AD帳戶和密鑰表中的密鑰之間匹配。此時您將不得不重新生成它。

有意義嗎?這實際上是一個現場解釋。要了解有關Kerberos與AD有關的更多信息,請從這裏開始:Kerberos Survival Guide

+0

根據我的經驗,ktpass僅在它更改_userPrincipalName_時才更改salt。如果使用'-setupn'選項運行'ktpass',例如使用已知鹽(與'/ rawsalt'結合)生成keytab,則AD中的salt不會更新。如果userPrincipalName手動更新(不使用'ktpass'),那麼salt並不總是被更新。我們認爲這可能是一個錯誤。 – mlowry

+0

我們知道salt並不總是被更新,因爲有幾個用戶的salt基於_userPrincipalName_的先前(不是當前)值。 – mlowry

+0

這是一個很好的討論,我會回來討論這個問題,並在今天晚些時候發表評論。必須跑掉atm ... –