マルチホームサーバーのActive Directory設計に関するアドバイス

私はお客様から、次の要件（簡略化された、実際にはかなり悪い）のシナリオでActive Directoryの設計を機能させるように依頼されました。

• クライアントシステム用のサブネットがあります。
• サーバーシステム用のサブネットがあります。
• 2つのネットワークは接続されていません。
• 各サーバーには2つのネットワークカードが必要です。1つはサーバーのネットワーク上にあり、もう1つはクライアントのネットワーク上にあります。
• クライアントとサーバー間のトラフィックは、クライアントのネットワーク上のみを流れる必要があります。
• サーバー間のトラフィックは、サーバーのネットワーク上でのみ流れるはずです。
• これは、ドメインコントローラにも適用されるはずです。

言うまでもなく、これはActive DirectoryがDNSを使用してドメインコントローラーを検索する方法にはあまり適していません。考えられるすべてのアプローチは、次のシナリオの1つにつながります。

• DCはドメインのDNSに「クライアント側」のIPアドレスを登録します。クライアントはそのアドレスを使用してクライアントと通信しますが、サーバーとADレプリケーショントラフィックも通信します。
• DCは、ドメインDNSに「サーバー側」のIPアドレスを登録します。サーバーはそのアドレスを使用してサーバーと通信し、レプリケーショントラフィックはそのネットワーク上を流れますが、クライアントはそれらに到達できません。
• DCは両方の IPアドレスをドメインDNSに登録します。それは、システムがそれらに到達するために何をするかはだれの推測です。

もちろん、これらの要件は完全にクレイジーであり、2つのネットワークでDNSサービスを分割してSRVレコードを手動で入力する（argh）かサーバーに配置させるなどのクレイジーソリューションを使用しない限り、それらすべてを同時に満たすことはできません。 DNSを使用するDCとクライアントは、WINS（double-argh）を使用してDCを見つけます。

私が思いついた解決策は、「サーバー」ネットワークに2つのDCを、「クライアント」1つに2つのDCを持ち、2つのADサイトを定義し、DCレプリケーショントラフィックのみで2つのネットワーク間の境界を越えることです。各サーバーには2つのネットワークカード（2つのサーバー側DCと純粋にバックエンドサーバーを除く）がまだあるため、これにはまだ DNSの変更が必要ですが、少なくとも機能する可能性はいくつかあります。

できるだけ早く逃げる以外のアドバイスはありますか？

最初に、私は他の多くの意見に同意します。それ以外の場合はクライアントを説得するか、実行します。

ただし、リストされている要件（リストされていないものは多数あります）を考慮すると、少なくともこれを実現するための基礎について考える（そして部分的にテストする）ことができます。

考慮が必要ないくつかの特定の側面があります。

1. Active Directoryドメインサービスのレプリケーション
2. クライアント/メンバーサーバーのDCロケータープロセス
3. AD DS以外のサービスの名前解決とトラフィック

1つと2つには多くの共通点があります。一般的に、私たちはこれに関してMicrosoftの気まぐれで、MicrosoftのAD DSプロセスの範囲内で作業する必要があります。

3つ目は、作業する余地が少しあることです。サービス（ファイル、データベースインスタンスなど）へのアクセスに使用するラベルを選択できます。

これが私が提案するものです：

ドメインコントローラー（DC）を構築する

• おそらく少なくとも2つ。
• 各DCには2つのNICがあり、1つは各IPネットワーク/ AD DSサイトにあります。現時点では、それらをcltおよびsrvと呼びます。
• 現在、srvネットワークの各DCに1つのNIC のみを構成します。

ADサイトとサービスを適切に構成する

• srvサイトとサブネット
• cltサイトとサブネット
• [サイト]-> [サイト間トランスポート]-> [IPを右クリック]から[すべてのサイトリンクをブリッジする]をオフにします。
• DEFAULTIPSITELINKが存在する場合（または名前を変更した場合）は削除するので、構成されたサイトリンクはありません。これは私には不明であることに注意してください。KCCは、おそらく2つのサイト（srvとclt）がさまざまな間隔で接続されていないことを示すエラーをディレクトリサービスイベントログにダンプします。ただし、同じサイト内のIPを使用して相互に接続できるため、2つのDC間でレプリケーションが続行されます。

AD DS統合DNSで追加のゾーンを構成する

• AD DSドメインがacme.localの場合、動的更新が有効になっている2番目のプライマリAD統合ゾーンを作成し、clt.acme.localと呼びます。

DCの2番目のNICを構成する

• これらのNICは、cltネットワーク/サイトのNICになります。
• IPを設定する
• これが魔法の部分です -アダプターのプロパティ-> IPv4のプロパティ->詳細設定-> DNSタブ->この接続のDNSサフィックスを clt.acme.localに設定 ->チェックこの接続を登録 ...- >この接続を使用DNSサフィックス...->ずっとOKです。
• ipconfig / registerdns
• これによりclt.acme.localゾーンにclt NIC IPが登録され、後で使用するIP /ネットワークを制御する方法が提供されます。

メンバーサーバーのNICを構成する

• cltサイトのメンバーサーバーNICのDNSサフィックスとチェックボックスは、上記と同様に適宜設定する必要があります。
• これらの設定は、静的およびDHCPで使用できますが、問題ではありません。

サイトでDNS [スタブ]リゾルバーの動作を構成する

• DC->それ自体と他のDC srv NIC IPを使用するようにDC srv NICを構成します。DC clt NIC DNSを空のままにします（ただし、静的IPが必要です）。（DC DNSサーバーは、デフォルトですべてのIPをリッスンします）。
• メンバーサーバー->メンバーサーバーのsrv NICを構成して、DC srvサイトのIPを使用します。メンバーサーバーclt NIC DNSを空のままにします（静的IPを使用できます）。
• クライアント/ワークステーション-> DCのclt NIC IPを使用するように（DHCPまたは静的経由で）DNSを構成します。

マッピング/リソースを適切に構成する

• サーバーが相互に通信する場合は、必ず.acme.localを使用してください->はsrvネットワークIPに解決されます。
• クライアントがサーバーと通信するときは、必ず.clt.acme.localを使用してください-> cltネットワークIPに解決されます。

私は何を話しているのですか？

• DCが相互に解決し、相互に接続できるため、AD DSレプリケーションは引き続き発生します。acme.localおよび_msdcs.acme.localゾーンには、DC srv NIC IPのみが含まれ、AD DSレプリケーションはsrvネットワークでのみ発生します。
• メンバーサーバーとワークステーションのDCロケータープロセスは機能します-サイトが不明な場合、さまざまなAD DSプロセスのさまざまな部分で遅延が発生する可能性がありますが、複数のDC IPが返された場合、試行され、失敗し、次に進みます働くまで。DFS-Nへの影響も完全には評価されていませんが、引き続き機能します。
• 前述の.acme.localおよび.clt.acme.localラベルを説明どおりに使用すると、非AD DSサービスは正常に機能します。

これは滑稽なので、完全にはテストしていません。 ただし、この（うわー、長い）答えのポイントは、それが可能かどうかを評価し始めることです。それを行う必要があるかどうかではありません。

@コメント

@Massimo 1/2 acme.localゾーンの複数のAD DSサイトを混同しないでください。したがって、acme.localゾーンのそれらのサイトのDCによって設定されたSRVレコードと、clt.acme.localゾーンの必要なSRVレコードを混同しないでください。クライアントのプライマリDNSサフィックス（およびそれらが参加しているWindowsドメイン）は、acme.localのままです。クライアント/ワークステーションにはNICが1つだけあり、プライマリDNSサフィックスはおそらくDHCPから取得され、acme.localに設定されています。

clt.acme.localゾーンは、DCロケータープロセスで使用されないため、SRVレコードを必要としません。クライアント/ワークステーションは、cltネットワークのメンバーサーバーIPを使用してメンバーサーバーの非AD DSサービスに接続するためにのみ使用します。AD DS関連のプロセス（DCロケーター）はclt.acme.localゾーンを使用しませんが、acme.localゾーンのAD DSサイト（およびサブネット）を使用します。

@マッシモ3

cltとsrvの両方のAD DSサイトのSRVレコードがあります-それらがacme.localゾーンに存在するだけです-上記のメモを参照してください。clt.acme.localゾーンは、DC関連のSRVレコードを必要としません。

クライアントは、DCの罰金を見つけることができます。クライアントDNSサーバーは、DCのclt IPをポイントします。

クライアントのDCロケータープロセスが開始するとき

• クライアントがそのサイトを知っている場合、DNSの質問は_ldap._tcp。[site] ._ sites.dc._msdcs.acme.local SRVになります。これにより、SRVレコードが登録されているサイト固有のDCが返されます。
• クライアントがそのサイトを知らない場合、DNSの質問は_ldap._tcp.dc._msdcs.acme.local SRVになります。これにより、すべてのDCが返されます。クライアントは、応答するLDAPが見つかるまで、DCのLDAPにバインドしようとします。クライアントがサイトを見つけると、クライアントはサイト検索を実行してクライアントのサイトを特定し、そのサイトをレジストリにキャッシュして、将来のDCロケーターインスタンスがより速く発生するようにします。

@マッシモ4

ええと、いいキャッチ。私の見方では、この問題を回避する方法は2つあります。

1. （以下の2と比較して）影響が少ないのは、DCのclt NIC IPを指すdc1.acme.localおよびdc2.acme.localのクライアント/ワークステーションのホストファイルにエントリを作成することです。

または

2. 各DCのnetlogon.dnsファイルに必要なSRVレコードを手動で作成します。これは、サーバーネットワークに何らかの影響を与える可能性があります。構成されている場合、メンバーサーバーはcltネットワーク上のDCと通信することがあります。

全体として見事なものはありませんが、それが必ずしも最終目標ではありません。多分クライアントはあなたの技術チョップをテストしているだけかもしれません。会議のテーブルにそれを配置して、「ここでは機能しますが、構成とサポートのために通常の4倍の料金を請求します。通常の速度の1.5倍に減らすことができます。 [正しい解決策]。」

先に述べたように、私の推奨は、そうでなければ説得するか、実行することです。しかし、それは確かにばかげている楽しい小さな運動です。:)

結局、私は2つのサイトソリューションに行きました：

• 「サーバー」ネットワーク用の2つのDC、「クライアント」ネットワーク用の2つのDC。
• 「サーバー」ネットワーク用と「クライアント」用の2つのADサイト。
• 「サーバー」ネットワーク内のDCは、そのNIC上にのみNICを配置するため（クライアントはまったくそれらと通信しません）、これは簡単です。
• 「クライアント」ゾーンのDCには2つありますが、DNSに登録するのはクライアント側のものだけです。
• サーバーはDCと通信し、クライアントはDCと通信します。

もちろん、これは2つのネットワーク間のレプリケーショントラフィックを有効にすることを意味します。「クライアント」は、ネットワーク内のDCがしますまだ「サーバ」は、ネットワーク上のNIC座っを持っているが、それはDNSに登録されませうとして、そのネットワーク内のDCは、クライアント側のIPアドレスを使用してそれらをご連絡いたします。そのため、NICは実際には完全に役に立たなくなり、一部のファイアウォールポートを開く必要があります。他の唯一のオプションはDCのhostsファイルを変更することですが、それが回避できることを願いましょう。

まあ、これは可能な限り多くの（クレイジーな）要件を満たすために実行できる最高の方法だと思います。

すべてのアドバイスをありがとう:-)

まず第一に、私たちがお客様にサービスを提供するとき、私たちは彼らの要件が何であるかを質問する必要があります。複雑さのレベルが不要であることをクライアントが理解できるようにします。

• クライアントの数はいくつですか？
• これはすべて内部トラフィックですか？
• ドメインの機能レベルは何ですか？
• TLSプロトコルが使用されていますか？

KISSメソッドの使用-2つのVLAN「SVR」と「CLT」を作成してSSL / TLSを有効にし、1日と呼びます。