現在、いわゆるカーブアウトプロジェクトに取り組んでいます。つまり、大企業の一部であるOLDCOが個別に販売され、新しいエンティティが新しいActiveDirectoryドメインNEWCOを構築しています。移行フェーズでは、OLDCOドメインコントローラーとNEWCOドメインコントローラーの両方、およびクライアントがIPアドレス空間で共有します。 NEWCOドメインは当面OLDCOドメインを信頼するため、たとえばOLDCOユーザーアカウントを使用してNEWCOクライアントマシンに対して認証することができます。
明らかに、移行フェーズの終わりまでに、OLDCO ADはなくなります。おそらく、ネットワークの分離によって、遠い将来にのみ発生します。
現在、OLDCOへの依存関係についてアプリケーションをテストできることを確認する方法を探しています。つまりアプリケーションXをNEWCOのドメインメンバーである新しいサーバーに移動した場合、気付かないうちにOLDCOリソースを使用しないようにするにはどうすればよいですか。
「もう存在しない」の最良のシミュレーションとして、移行されたアプリケーションサーバーからOLDCOコメインコントローラーへのアクセスを一時的に防ぐ、簡単にオンとオフを切り替えることができるファイアウォールルールを実装することを考えましたが、それは有効なテストでしょうか?
たとえば、ADの内部についてあまり確信が持てない場合、信頼が存在し、OLDCO DCが期限切れになる時点でキャッシュが期限切れになる可能性がある限り、NEWCOドメインコントローラーがOLDCOドメインからのデータをキャッシュする可能性があるかどうかはわかりません。成功したように見えたテストの後、問題は長い間私たちを襲うでしょう。
誰かが以前にそのようなプロジェクトを成功させ、ADフォレストでのカーブアウトなどのシミュレーション方法の他のアイデアを成功させたことがありますか?
標準の非読み取り専用ドメインコントローラーには、心配しているキャッシュは含まれていません。レプリケーショントポロジ内に存在する適切に統合されたドメインコントローラーのみが、Up-to-Date Vector(UTDV)やntdsutil
を使用して表示できるその他のNTDS固有情報など、相互の情報をキャッシュします。
テストしているのが南北トラフィック(内部-外部)トラフィックの場合、ファイアウォールルールを使用してテストし、問題のリソースからの切断をシミュレートすることを検討します。
テストしているのが東西トラフィック(内部-内部)トラフィックである場合は、グループポリシーオブジェクト(GPO)を使用してドメインコントローラーで高度な監査ポリシーを有効にすることを検討します。 _Audit account logon events
_で利用できる_Audit logon events
_および_Computer Configuration\Policies\Windows Settings\Security Settings\Local Policies\Audit Policy
_設定に最も関心があります。 GPOは、BUILTINドメインコントローラーグループに対するセキュリティフィルタリングとリンクする必要があります。
次に、次のIDのイベントビューアイベントを収集できます。
過去12時間のすべての一致するイベントについて、問題のドメインコントローラーでローカルに(管理者として)実行できるPowerShellスニペットを提供しています。
Get-EventLog -LogName Security -After ((Get-Date).AddHours(-12)) | Where-Object { $_.EventId -in 4624, 4625, 4648, 4634, 4647, 4672, 4678, 4679, 4770, 4771, 4774, 4776, 4778 } | Select TimeWritten, Source, EventID, InstancedId, Message | Sort TimeWritten -Descending | Format-Table Auto
複雑な動きです。
OLDCOドメインコントローラーへの正常なアカウントログオン監査をアクティブ化します。セキュリティログには、後にDCに対して行われたすべてのログイン試行が表示されます。したがって、資格情報はNEWCOドメインコントローラーからキャッシュされないため、最後に何かがまだ認証されているかどうかが表示されます。 。
大量のログが作成される可能性があることに注意してください。必ず大きなCを使用するか、ログを別の場所に移動してください。
そのような動きについては、あなたも考えることが複数あります。
Exchangeを使用する場合、移行にリンクされたメールボックスを使用することになります。その準備を始めましょう。
Windows認証を使用している場合は、SQLインスタンスをテストする必要があります。これは、ロギングのすべてのユーザー情報がnewcoドメインに適合しないためです。その部分をテストするには、newcoで別のSQLサーバーをオンラインにし、データを移行して、アプリケーションが本番環境以外でも正常に機能するかどうかをテストする方が簡単です。
ファイルリソースの場合、各フォルダのセキュリティグループをチェックして複製する必要があります。共有に定義された古いセキュリティグループは、oldcoドメインが落ちると機能しなくなります。
Radiusまたは証明書サーバーを使用していますか?等...
ご覧のとおり、移動を正しく計画するために行うべきドキュメントがたくさんあります。