森は2つあります。alpha.example.comそしてbravo.example.comドメインの NETBIOS 名はそれぞれ ALPHA と BRAVO です。これは、ドメイン名の命名に問題はなく、DNS と NETBIOS の両方で 2 つの異なる名前が付けられていることを意味しているようです。
ドメイン コントローラーとして次のサーバーがあります。
- dc01.alpha.example.com
- dc02.alpha.example.com
- dc01.bravo.example.com
このようにALPHAとBRAVOの間にフォレストの信頼を確立しようとすると、信頼を実際に検証するときに「ログオン要求を処理できるログオンサーバーがありません」というメッセージが表示されます。いくつかのフォーラムスレッドオンラインで、また、両方のドメインのドメイン コントローラの名前が同じである 2 つのドメインを接続すると問題が発生するという逸話的な証拠もいくつか聞きました。これは私には意味がわからないようで、Microsoft ツールのバグのように思えます。
dc01.alpha.example.com と dc01.bravo.example.com は明らかに 2 つの異なるマシンなので、これは問題にならないはずだと思いました。しかし、Windows はそれに同意していないようです。
この設定を機能させるために必要な情報が不足しているのでしょうか? 残念ながら、ドメイン コントローラーの名前を変更するのは、私たちにとっては悪い答えです。なぜなら、最終的には、すべて同じ名前のドメイン コントローラーを持つ多数のフォレストを接続することになるからです。つまり、多数の DC: の名前を変更することになります。
ちなみに、ドメイン コントローラーの 1 つの名前を変更すると信頼関係を確立できますが、できれば現実世界ではそれを実行したくありません。
ラボ内のすべてのマシンは、最新のパッチが適用された Windows Server 2012 R2 を実行していますが、特別な修正プログラムはインストールされていません。
DNS は次のように設定されています: ALPHA ドメインで、bravo.example.com のスタブ ゾーンが追加され、dc01.bravo.example.com の IP アドレスを指します。次に、dc01.bravo.example.com は dc01.alpha.example.com と dc01.bravo.example.com をアップストリーム DNS として使用します。これは少しハッキーな設定ですが (ラボなので...)、結果として両方の方法で DNS 解決が正しく機能します。dc01.bravo.example.com は bravo.example.com 内の名前を解決でき (権限があるため)、alpha.exaple.com の名前はアップストリーム DNS が権限を持っているため正しく解決されます。スタブ ゾーンがあるため、alpha のリゾルバは bravo の名前を正しく解決できます (スタブ ゾーンは AD に追加され、両方の DNS サーバーが取得します)。
さらに次のことを試しました:
- スタブゾーンから条件付きフォワーダーへの変更
- 外部トラストではなく森林トラストを運営する
症状に変化はありません。
答え1
問題は、名前サフィックス ルーティングと呼ばれるものによって発生します。この問題については、次の記事で説明しています。 https://technet.microsoft.com/ja-jp/library/cc784334%28v=ws.10%29.aspx より ネットダムを使用してこの問題に対処できると述べています。
記事の一部には次のように書かれている。
フォレスト間での名前サフィックスのルーティング
名前サフィックス ルーティングは、フォレストの信頼によって結合された Windows Server 2003 フォレスト間で認証要求をルーティングする方法の管理に使用されるメカニズムです。認証要求の管理を簡素化するために、フォレストの信頼が最初に作成されると、すべての一意の名前サフィックスが既定でルーティングされます。一意の名前サフィックスとは、ユーザー プリンシパル名 (UPN) サフィックス、サービス プリンシパル名 (SPN) サフィックス、DNS フォレストまたはドメイン ツリー名など、他の名前サフィックスに従属しないフォレスト内の名前サフィックスです。たとえば、DNS フォレスト名 microsoft.com は、microsoft.com フォレスト内の一意の名前サフィックスです。
フォレストには複数の一意の名前サフィックスを含めることができ、一意の名前サフィックスのすべての子は暗黙的にルーティングされます。このため、Active Directoryドメインと信頼関係では、名前サフィックスの先頭にアスタリスク（*）が表示されます。たとえば、フォレストが.microsoft.com を一意の名前サフィックスとして使用すると、microsoft.com のすべての子に対する認証要求が発生します (子ドメイン (.child.microsoft.com) は、子ドメインが microsoft.com 名前サフィックスの一部であるため、ルーティングされます。
2つのフォレスト間にフォレスト信頼が存在する場合、一方のフォレストに存在しない名前サフィックスを使用して、認証要求を2番目のフォレストにルーティングできます。新しい子の名前サフィックス（.child.widgets.com) が一意の名前サフィックス (.widgets.com などのフォレスト信頼が確立された後に作成された新しい一意の名前サフィックスは、信頼を確認した後、フォレスト信頼の [プロパティ] ダイアログ ボックスに表示されます。ただし、これらの新しい一意の名前サフィックスのルーティングは既定で無効になります。信頼を確認する方法の詳細については、「信頼を確認する」を参照してください。
重複する名前サフィックスが検出されると、最新の名前サフィックスのルーティングは既定で無効になります。名前サフィックスをルーティングする方法の詳細については、「既存の名前サフィックスのルーティングを有効または無効にする」を参照してください。管理者は、フォレストの信頼のプロパティ ダイアログ ボックスを使用して、特定の名前サフィックスの認証要求がフォレストにルーティングされないように手動で防止できます。
注意 • UPN サフィックスまたはユーザー名に @ 記号を追加しないでください。認証要求が信頼されたフォレストにルーティングされると、最初の @ 記号の前のすべての文字はユーザー名として解釈され、最初の @ 記号の後のすべての文字は UPN サフィックスとして解釈されます。
• ローカル セキュリティ機関 (LSA) は、有効な DNS 名ではない UPN サフィックスへのルーティングをブロックします。たとえば、UPN サフィックスに @ 記号を追加すると、自動的に無効になります。