web-dev-qa-db-ja.com

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

私は顧客から、次の要件を持つシナリオで機能するActive Directoryの設計を考え出すように依頼されました(単純化すると、実際にははるかに悪いです)。

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

言うまでもなく、これはActiveDirectoryがDNSを使用してドメインコントローラーを見つける方法とはあまりうまくいきません。考えられるアプローチは、次のいずれかのシナリオにつながります。

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

もちろん、これらの要件は完全に狂っており、2つのネットワークでDNSサービスを分割し、SRVレコードを手動で入力する(argh)、またはサーバーに場所を特定させるなどの狂ったソリューションを使用しない限り、すべてを同時に満たすことはできません。 DNSを使用するDCとクライアントは、WINS(double-argh)を使用してDCを検索します。

私が思いついた解決策は、「サーバー」ネットワークに2つのDCを配置し、「クライアント」ネットワークに2つのDCを配置し、2つのADサイトを定義し、2つのネットワーク間の境界をDCレプリケーショントラフィック。これにはまだ DNSマングリングが必要です。各サーバーにはまだ 2つのネットワークカードがあります(2つのサーバー側DCと純粋なバックエンドサーバーを除く) 、しかし、それは少なくともいくつかのチャンスがあります。

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

10
Massimo

結局、私は2つのサイトのソリューションを採用しました。

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

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

まあ、これはできるだけ多くの(クレイジーな)要件を満たすためにできる最善のことだと思います。

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

3
Massimo

私は他の多くの人に同意することから始めましょう-そうでなければクライアントを説得するか、実行します。

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

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

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

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

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

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

ドメインコントローラー(DC)を構築する

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

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 NIC IPがclt.acme.localゾーンに登録されます。後で使用するIP /ネットワークを制御する方法が提供されます。

メンバーサーバーNICを構成します

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

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

  • DC->構成DC srv NIC自分自身と他のDC srv NIC = IP。そのままにしますDC clt NIC DNSは空です(ただし、静的IPは必要です)。(DCDNSサーバーは引き続きlisten onデフォルトではすべてのIP)。
  • メンバーサーバー->メンバーサーバーsrv NICを構成してDC srvサイトIPを使用します。メンバーサーバーcltを離れるNIC DNS空(静的IPを使用できます)。
  • クライアント/ワークステーション-> DCのclt NIC IP)を使用するようにDNSを(DHCPまたは静的のいずれかで)構成します。

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

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

私は何について話しているのですか?

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

かなりばかげているので、これを完全にテストしていません。しかし、この(すごい、長い)答えのポイントは、それが可能かどうかを評価し始めることです-それが行われるべきかどうかではありません。

@コメント

@Massimo 1/2acme.localゾーンの複数のAD DSサイトを混同しないでください。したがって、acme.localゾーンのサイトのDCによって入力されたSRVレコードと、 clt.acme.localゾーン。クライアントのプライマリDNSサフィックス(およびそれらが参加しているWindowsドメイン)は引き続きacme.localです。クライアント/ワークステーションにはNICが1つしかないため、プライマリDNSサフィックスはDHCPから派生している可能性があります。 acme.local。

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

@Massimo 3

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

クライアントはDC問題ありません。クライアントDNSサーバーは、DCのcltIPを指します。

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

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

@Massimo 4

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

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

または

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

全体として、どれもきれいではありませんが、それが必ずしも最終目標ではありません。たぶん、クライアントはあなたの技術チョップをテストしているだけです。 Plop会議テーブルに置いて、彼らに伝えてください"ここでは機能しますが、構成とサポートのために通常の4倍の料金を請求しています。1.5に減らすことができますx私の通常のレート-[正しい解決策]を実行することによる.5xPITA料金。 "

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

5
Weaver

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

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

K.I.S.Sメソッドを使用すると、SSL/TLSを有効にして1日と呼ぶ2つのVLAN「SVR」と「CLT」が作成されます。