none
ドメインの外部信頼関係でアクセス拒否が発生する RRS feed

  • 質問

  • 以下のdom-a~dom-dをnewdomへ統合しようとしています。

    [ドメイン名(NETBIOS名/フォレスト機能レベル)]
    newdom.local       (NEWDOM    /2012 R2)
    lan.dom-a.com      (DOM-A     /2008 R2)
    lan.dom-b.com      (SHINBASHI /2008 R2)
    honsha.dom-c.ad.jp (HONSHA    /2003 R2)
    local.dom-d.com    (DOM-D     /2008 R2)


    統合にあたり、1年前(2014年8月)にまず
    各ドメインをそれぞれ双方向の外部信頼関係にしました。
    この時には特に問題もなく、全てのドメイン同士のサーバーに接続が出来、
    信頼関係の検証もエラーは発生しませんでした。

    ようやく統合の準備が整い、
    最近になってnewdom所属の端末からのアクセステストを行ったところ、
    dom-aのサーバーにのみ上手く接続が出来ません。

    \\fileserver.lan.dom-a.com\を開こうとすると出るエラー内容は
    「プライマリ ドメインと信頼される側のドメインとの信頼関係に失敗しました。」
    となります。

    newdomのPDCエミュレータより、信頼関係の検証を行った所エラーとなり、
    ウィザードに従ってパスワードのリセットを行っても
    「アクセス拒否」となり回復しません。

    他のドメイン間は、全ての検証は問題なく完了します。

    newdom⇔dom-a間の信頼関係を一旦削除し再度作成しても、
    ウィザードの最後の検証でエラーとなります。

    netdom trust newdom.local /domain:lan.dom-a.com /usero:newdom\administrator /passwordo:* /userd:dom-a\administrator /passwordd:* /reset /force /verbose

    を実行すると各ドメインのPDCエミュレータへセキュリテイ接続は完了するのですが、
    パスワードのリセットの段階で「アクセス拒否」エラーが発生します。

    しかし、各ドメインの「Active Directory ユーザーとコンピューター」にて
    拡張機能を表示し、「system」コンテナ内の
    相手方のドメインの信頼アカウントのプロパティを開き、
    whenchanged属性を見ると、
    netdom trust /resetを行った時刻に更新されています。

    各ドメインコントローラー間にはファイアウォールやACLは存在しません。
    仮に存在していれば、dom-a⇔dom-bやnewdom⇔dom-bもエラーとなるはずです。
    また、少なくともdom-a、dom-b、newdomのPDCエミュレータは
    同じL2スイッチに接続されています。

    netdom trust /remove /force で信頼関係を一旦削除し、
    netdom trust /add /twoway で再作成しても症状は改善しません。


    もちろん、全ての操作でドメイン名はFQDNを指定しています。
    また、各ドメインには他のドメインの前方参照ゾーンとして
    スタブゾーンを作成しており、
    nslookupで各ドメイン間の名称解決を検証しても正常に機能します。

    ドメイン名を引くと全ドメインコントローラーのIPが返って来ます。
    _ldap._tcp.pdc._msdcs.ドメイン名を引くとpriorityやweight、
    svr hostname等が正常に返って来ます。

    各ドメインコントローラーは全て同じ外部NTPと同期しているので、
    時刻は全て合致しています。

    このフォーラムの

    と症状は同じなのですが、/remove /force後に再構築しても症状は解決しません。

    他にも同様のケースが無いか調べたのですが、正直お手上げです…
    何か参考となる情報があればお知らせください。

    以上、よろしくお願い致します。

    2015年11月12日 1:40

回答

  • ばんぶぅです。自己解決しました。

    やはりホスト名の競合が原因でした。
    newdomのドメインコントローラーのホスト名を、他のドメインと競合しないように変更した所、
    問題は解決しました。

    また、これまで問題が発生していなかったdom-bについても、
    newdomのホスト名を変更する前日より同様のエラーが発生し信頼関係が失敗していました。
    こちらについてもドメインコントローラーにホスト名「ad02」が存在することが判明し、
    newdomのホスト名変更の後に障害は解決しました。

    netdom trust /verify の挙動を見ていて思ったのですが、
    ドメインの信頼関係は必ずしもFSMO同士が通信する訳ではなく、
    任意のドメインコントローラー同士が通信するようです。

    当初はたまたま競合しないホスト名のドメインコントローラー同士が
    信頼関係の通信を行っていたので問題が発生せず、
    その後ドメインコントローラーの再起動等で、
    信頼関係の通信を行うドメインコントローラーが切り替わった際に
    ホスト名の競合が発生したようです。

    ちょうど、Windows Updateの適用でdom-bのドメインコントローラーを
    再起動してからnewdom⇔dom-bの信頼関係に失敗するようになったので、
    そう考えると全てに合点がいきます。

    • 回答としてマーク 840 Bamboo 2015年11月25日 10:07
    2015年11月25日 10:07

すべての返信

  • チャブーンです。

    この件ですが、ひとまず切り分けのために「それぞれのドメインコントローラ上で同じ信頼パスワードを使って双方向の信頼を作成」してみて、それから検証を行ってみてはどうでしょうか。こうすれば、双方のドメインの信頼パスワードが正しいことは保証されますので、本当にパスワードの誤りの問題かどうか、確認ができると思います。

    それと、細かい点ですが

    各ドメインコントローラー間にはファイアウォールやACLは存在しません。
    仮に存在していれば、dom-a⇔dom-bやnewdom⇔dom-bもエラーとなるはずです。

    ファイアウォールはOSレベル、L3レベルと重層的に存在するので、状況から決めつけられないことをお奨めします(きちんと確認された方がよいでしょう)。

    また、各ドメインには他のドメインの前方参照ゾーンとして
    スタブゾーンを作成しており、
    nslookupで各ドメイン間の名称解決を検証しても正常に機能します。

    これですが、自ドメイン以外を参照する際に「スタブゾーン」を設定することは、残念ながら正しくないようです。このようなケースでは条件付きフォワーダが適切です。条件付きフォワーダの場合、問い合わせ元からのすべてのDNSクエリについて、フォワーダ先からの応答が保証されます。

    https://msdn.microsoft.com/ja-jp/library/cc780434(v=ws.10).aspx

    もし、信頼パスワードが正しくても検証が失敗する場合ですが、MS-RPC通信がきちんと行えているかどうか、また相手先PDCエミュレータを正しく認識できているかどうか、の確認がいると思います。pdcエミュレータはDNSベースでSRVレコードとして記録されていますが、何らかの原因で、そのレコードが破損(あるいは過去のIPアドレスになっている等)しているのかもしれません。


    フォーラムは有償サポートとは異なる「コミュニティ」です。フォーラムでご質問頂くにあたっての注意点 をご一読のうえ、お楽しみください。

    2015年11月12日 8:57
    モデレータ
  • チャブーンさん、御回答ありがとうございます。

    まず、同じ信頼パスワードを使用してそれぞれで信頼を作成する方法ですが、
    真っ先に試しましたが状況は同じです。

    次にファイアウォールですが、OSレベルでは全て無効化しています。

    また、ドメインコントローラー間の各スイッチにもACLが設定されていない事は確認済みです。
    更にポートスキャンツール等を利用して調査しても、KerberosやRPC等に必要なポートは
    全て双方向で通信が出来る事を確認済です。
    (互いのPDCエミュレータでそれぞれ相手方のPDCエミュレータに対してポートスキャンした結果)

    スタブゾーンについては、他のドメインのドメインコントローラーが
    知らない間にIPが変わっているケースがあるので、
    条件付きフォワーダーでフォワード先を固定すると支障が出る為、スタブゾーンを設定しています。
    (各ドメインはそれぞれ元々別会社ですので、予告無しにネットワーク構成を変更されたりする時があります)

    自ドメイン以外を参照する際に「スタブゾーン」を設定することは、残念ながら正しくないようです。

    ご提示頂いたMSDNのページを参照したのですが、正しくない根拠が判りません。
    むしろ、スタブゾーンの解説の文末の「条件付きフォワーダーは、親ゾーンをホストしているDNSサーバーで…(以下略)」
    の説明より、DNSサーバーの変更可能性があるケースではスタブゾーンを使用すべきと解釈します。

    ※各ドメイン間にファイアウォール等が存在する場合は「条件付きフォワーダー」が優位なようですが。

    PDCエミュレータのSRVレコードは
    _ldap._tcp.pdc._msdcs.ドメイン名で正しいPDCホスト名(FQDN)が返るのを確認済で、
    またこのホスト名を正引きすると、正しいIPアドレスが返ってくることも確認しています。

    2015年11月13日 8:32
  • 検証の途中結果を報告します。

    それぞれのドメインコントローラーのうちの1台ずつをP2Vして、検証環境上で状況を再現しました。

    まず、検証環境上で他の(P2Vしていない)ドメインコントローラーを削除し、
    必要に応じてFSMOの強制転送を行いました。
    また、検証以外のドメインとの信頼関係を削除し、
    DNSレコード等も全てクリーニングし、ドメインコントローラーが1対1の状態で
    外部信頼関係の構築を試みました。

    結果、エラー内容は少々違うものの、症状は再現できました。
    この時、同一のHyper-Vホスト上で同一のHyper-V仮想スイッチに
    各ドメインコントローラーを設置したので、
    イベントログに「NETLOGON」エラーが出力され、
    NetBIOS名が競合しているとのこと。

    実際に、各ドメインのドメインコントローラー名は
    ad01.newdom.local
    ad02.newdom.local (FSMO)

    ad01.lan.dom-a.com (FSMO)
    ad02.lan.dom-a.com
    ad03.lan.dom-a.com
    であ、本番環境ではad02.newdom⇔ad01.lan.dom-aで、
    エラー内容が少々異なったようですが、
    たまたまP2Vしたドメインコントローラーが両方ともad02だったのでNETLOGONエラーに気づきました。

    実際にエラーが発生する検証環境上で、一方のドメインコントローラーのホスト名を
    ad02⇒ad01に変更したら正常に動作し、元に戻したらエラーが再現されました。

    また、他のドメイン(dom-b/dom-c/dom-d)は全て
    ドメインコントローラーの命名規則が異なるので確かに競合していません。

    少々準備が必要ですが、本番環境についてどちらかのドメインの
    全てのドメインコントローラーのホスト名を変更してみます。

    結果が判り次第追って報告いたします。


    2015年11月13日 8:42
  • チャブーンです。

    なるほど。(NetBIOS)コンピュータ名が重複していたこと、が原因の可能性があるということですね。それであれば確かにうなずけます(netdomはNetBIOS周りのチェックもしているはずですので)が、逆に腑に落ちない点として、そのような状況であればそもそも信頼構築時にエラーが出ていた可能性があること、当初の構築時に「検証エラー」が出なかったのはなぜか、という部分があります。もしかしたら、何かの状況(ネットワーク周りの環境等)でNBT周りの通信状況が構築当初と現時点で違っていた、という可能性はあるかもしれませんね。

    あと、言い争うつもりは全くないのですが、私の理解では「スタブゾーン」は子ドメインをIP Reachableにするため親ドメイン上で設定する機能であり、ツリー関係にない名前空間に対して設定することは、デザイン上いささか違和感があります。名前空間上関連のないドメインについては、本来は再帰で解決する話しで、それができない場合のフォワーダ機能である、と思っています。(ご自身でもコメントされていますが)、クライアントからスタブゾーン先のDNSクエリがUnreachableの場合問題が発生しますが、これがReachableかどうかはサーバ設計者にはコントロールできない(異なる担当者が彼らの都合で設計する)ため、私個人としては「基本デザインをできるだけ外さない」ことを考えるようにしています。


    フォーラムは有償サポートとは異なる「コミュニティ」です。フォーラムでご質問頂くにあたっての注意点 をご一読のうえ、お楽しみください。


    2015年11月16日 2:38
    モデレータ
  • ばんぶぅです。自己解決しました。

    やはりホスト名の競合が原因でした。
    newdomのドメインコントローラーのホスト名を、他のドメインと競合しないように変更した所、
    問題は解決しました。

    また、これまで問題が発生していなかったdom-bについても、
    newdomのホスト名を変更する前日より同様のエラーが発生し信頼関係が失敗していました。
    こちらについてもドメインコントローラーにホスト名「ad02」が存在することが判明し、
    newdomのホスト名変更の後に障害は解決しました。

    netdom trust /verify の挙動を見ていて思ったのですが、
    ドメインの信頼関係は必ずしもFSMO同士が通信する訳ではなく、
    任意のドメインコントローラー同士が通信するようです。

    当初はたまたま競合しないホスト名のドメインコントローラー同士が
    信頼関係の通信を行っていたので問題が発生せず、
    その後ドメインコントローラーの再起動等で、
    信頼関係の通信を行うドメインコントローラーが切り替わった際に
    ホスト名の競合が発生したようです。

    ちょうど、Windows Updateの適用でdom-bのドメインコントローラーを
    再起動してからnewdom⇔dom-bの信頼関係に失敗するようになったので、
    そう考えると全てに合点がいきます。

    • 回答としてマーク 840 Bamboo 2015年11月25日 10:07
    2015年11月25日 10:07