Domain Adminsにこの制限を適用すると、「ネットワークが壊れる」のでしょうか。
ドメイン内のすべてのサーバーを保護するとします。
- ドメインコントローラーは、ジャンプサーバーからのRDPアクセスのみを許可します
- ドメイン管理者がDC以外のサーバーに接続できない
- など
これはすべてスウェルであり、メンバーサーバーのメモリにドメイン管理者のパスワードが存在しないようにするための安全な構成と見なす必要があります。
ここで、攻撃者が魔法のようにがメンバーサーバーの1つでドメイン管理者のパスワードを把握し、PsExecを介してMimikatz（またはその他のパスワード抽出ツール）をリモートでDC-ゲームオーバー。
ただし、
ネットワークからこのコンピューターへのアクセスを拒否する
dCでそれをすべてのドメイン管理者用に構成すると、何かが壊れますか？
これには理由もあり、ドメイン管理者がジャンプサーバー以外の別のサーバーからDC）に認証することはありません。
私は自分のラボでこれをモデル化しましたが、何も壊れません。この構成のため、ドメイン管理者パスワードを使用してpsexecを実行すると失敗します。これは勝利です。問題は、実際のネットワークで機能するかどうかです。
私が収集したものから、この制限はSMBを介して行われたすべての認証試行に対するものです。
おそらくサーバーフォールトに移動する必要があります。
ESAE（赤）フォレストは、Active Directoryを保護するための推奨事項です。 https://technet.Microsoft.com/en-us/windows-server-docs/security/securing-privileged-access/securing-privileged-access-reference-material
ネットワークの複雑さを知らなければ、確かに言うのは難しいですが、ドメイン管理者は私が知っているドメインコントローラーへのネットワークアクセスを必要としませんが、テストせずに危険な動きになる可能性があります。そうは言っても、それらのデバイスへの物理的なアクセスが明らかに必要になります。
より優れたソリューションは、DCが層0、メンバーサーバーまたは機密サーバーが層1、層2がデスクトップである特権アクセスの層モデルを使用することです。アカウントの垂直トラバーサルはないはずです。そのため、管理者はDC用にt0アカウント、メンバーサーバー用にt1、デスクトップ管理用にt2、エンドユーザー用にt3を持つことができます。それらのどれも他の層にアクセスできません。保護されたアクセスワークステーション（Paw）を使用すると、さらに一歩先を行くことができます（上記のリンクを参照）。
DAがメンバーサーバーにアクセスできない場合、メンバーサーバー自体の侵害によってドメイン管理者を明らかにすることはできません。プロセスまたはツールが階層間でデータをリークする他の短所をジャンプまたは検索し続ける必要があります。これは、DCへの接続が許可されている唯一のデバイスであるIPSecを備えた物理デバイスがあり、他のアカウントがそのデバイスにアクセスできない場合に、Pawが使用される場所です。次に、DAを危険にさらすために物理的なアクセスが必要になります。そのDAはその物理デバイスでのみ使用できるため、Mimikatzが他の場所で使用しているのを見ることはありません。
注：Windows以外のデバイスを管理する場合、これはさらに複雑になります。これは、パッチが100％更新されておらず、サーバー/ DCでJava/Adobeを実行しない、サーバー/ DCへのインターネットアクセスを制限する、ネットワークセグメンテーションを実装するなど、他の基本的なセキュリティプラクティスに従わない場合も問題ではありません。等.
詳細については、遠慮なくお問い合わせください。