☰

AD ドメインに参加した Linux サーバー (NLA と同等)

tag-icon • tag-icon linux active-directory ssh
AD ドメインに参加した Linux サーバー (NLA と同等)

まず、背景を説明します。

現在、少数の Linux サーバーのみを含む、主に Windows Server AD 環境にいる場合は、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

対処すべき点はたくさんありますが、基本的に必要なのは「Kerberos 化された」SSH などです。NLA は、認証が検証されるまでコンソール セッション (作成にはリソースの面でコストがかかります) を提供しないという追加の手順 (ここでは指定されていません) も提供します。

もっと正確に言えば、複雑さは別として、回避策がすでにあるため、これに大きな関心が寄せられているとは思えません。Linux ホストのフロントエンドに要塞ジャンプ ホストを使用し、他のホストからのアクセス/ポートの種類を禁止します。その要塞ホストは Windows であってもよく、不足しているすべての機能をサポートします。

保護されたリソースへの RDP などのアクセス タイプを許可するために、Bastion ジャンプ ホストも AD 環境で一般的になりつつあります。

また、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

関連情報