☰

AD網域加入相當於NLA的linux伺服器

tag-icon • tag-icon linux active-directory ssh
AD網域加入相當於NLA的linux伺服器

首先，一些背景知識。

如今，如果您處於主要是 Windows Server AD 環境中，只有少量 Linux 伺服器，您可以選擇透過 SSH 向伺服器進行身份驗證：

  1. 透過 SSH 使用憑證驗證管理 Linux 伺服器（正常的 Linux 方式）
  2. 將 Linux 伺服器加入您的 AD 網域 (realm+sssd)，並透過 SSH 使用使用者名稱/密碼驗證來管理它們

問題是，選項 1 讓管理員需要管理一組與環境其他部分不同的憑證，而選項 2 則讓管理員在電腦完全相互識別之前透過網路直接向遠端伺服器提供密碼。

在 Windows 世界中，這是透過網路層級驗證解決的（至少對於 RDP，我知道應該避免）。過程的簡化版本如下所示：

  1. 使用者開始連接到遠端計算機
  2. 遠端電腦使用 AD 電腦帳戶令牌進行回應
  3. 本機電腦驗證令牌、查看 NLA 支援並向使用者顯示憑證對話框
  4. 使用者使用憑證完成對話框
  5. 本機透過網域控制（而非遠端電腦）驗證憑證
  6. DC 為本機提供身份驗證令牌
  7. 本機將令牌呈現給遠端計算機
  8. 遠端電腦根據網域驗證令牌
  9. 成功後，用戶將被允許存取遠端電腦。

實際上，該過程甚至可以更簡單，使用者首次登入本機時為使用者建立的現有身份驗證令牌已經可以使用。

這是一個複雜的過程，我在描述它時肯定犯了錯誤。關鍵在於身份驗證令牌取代了 Linux 故事中的證書，這樣使用者就永遠不會向潛在未知的機器提供實際憑證。此外，各方對可信任 DC 的依賴使得事情比 Linux 的故事更好，因為使用者不必管理自己的證書，即使透過自己的軟體（而不是為他們提供的軟體）也是如此。

現在回答這個問題。有沒有辦法獲得類似的方法來驗證與 AD 加入的 Linux 伺服器的 SSH 會話，其中伺服器永遠不會看到使用者憑證，但使用者體驗仍然是 Windows 本機憑證驗證？

答案1

有很多問題需要解決，但本質上需要的是“kerberized”SSH 或其他什麼。 NLA 還提供了一個額外的步驟（此處未指定），即在驗證身份驗證之前不提供控制台會話（創建該會話在資源方面是昂貴的）。

更重要的是，除了令人望而卻步的複雜性之外，我認為對此沒有太多興趣，因為已經有了解決方法。使用堡壘跳轉主機作為 Linux 主機的前端，禁止其他人的存取/連接埠類型。此堡壘主機可以是 Windows，並支援所有缺少的功能。

堡壘跳轉主機在 AD 環境中也變得越來越常見，允許對受保護資源進行 RDP 等類型的存取。

同樣對於 RDP 範例，憑證實際上並未受到伺服器的保護。這是透過使用 /RemoteGuard 開關來解決的。

https://learn.microsoft.com/en-us/windows/security/identity-protection/remote-credential-guard

https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/mstsc

相關內容