トップ回答者
ドメインの外部信頼関係でアクセス拒否が発生する

質問
-
以下の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後に再構築しても症状は解決しません。
他にも同様のケースが無いか調べたのですが、正直お手上げです…
何か参考となる情報があればお知らせください。以上、よろしくお願い致します。
-
回答
-
ばんぶぅです。自己解決しました。
やはりホスト名の競合が原因でした。
newdomのドメインコントローラーのホスト名を、他のドメインと競合しないように変更した所、
問題は解決しました。また、これまで問題が発生していなかったdom-bについても、
newdomのホスト名を変更する前日より同様のエラーが発生し信頼関係が失敗していました。
こちらについてもドメインコントローラーにホスト名「ad02」が存在することが判明し、
newdomのホスト名変更の後に障害は解決しました。netdom trust /verify の挙動を見ていて思ったのですが、
ドメインの信頼関係は必ずしもFSMO同士が通信する訳ではなく、
任意のドメインコントローラー同士が通信するようです。当初はたまたま競合しないホスト名のドメインコントローラー同士が
信頼関係の通信を行っていたので問題が発生せず、
その後ドメインコントローラーの再起動等で、
信頼関係の通信を行うドメインコントローラーが切り替わった際に
ホスト名の競合が発生したようです。ちょうど、Windows Updateの適用でdom-bのドメインコントローラーを
再起動してからnewdom⇔dom-bの信頼関係に失敗するようになったので、
そう考えると全てに合点がいきます。- 回答としてマーク 840 Bamboo 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アドレスになっている等)しているのかもしれません。
フォーラムは有償サポートとは異なる「コミュニティ」です。フォーラムでご質問頂くにあたっての注意点 をご一読のうえ、お楽しみください。
-
チャブーンさん、御回答ありがとうございます。
まず、同じ信頼パスワードを使用してそれぞれで信頼を作成する方法ですが、
真っ先に試しましたが状況は同じです。次にファイアウォールですが、OSレベルでは全て無効化しています。
また、ドメインコントローラー間の各スイッチにもACLが設定されていない事は確認済みです。
更にポートスキャンツール等を利用して調査しても、KerberosやRPC等に必要なポートは
全て双方向で通信が出来る事を確認済です。
(互いのPDCエミュレータでそれぞれ相手方のPDCエミュレータに対してポートスキャンした結果)スタブゾーンについては、他のドメインのドメインコントローラーが
知らない間にIPが変わっているケースがあるので、
条件付きフォワーダーでフォワード先を固定すると支障が出る為、スタブゾーンを設定しています。
(各ドメインはそれぞれ元々別会社ですので、予告無しにネットワーク構成を変更されたりする時があります)> 自ドメイン以外を参照する際に「スタブゾーン」を設定することは、残念ながら正しくないようです。
ご提示頂いたMSDNのページを参照したのですが、正しくない根拠が判りません。
むしろ、スタブゾーンの解説の文末の「条件付きフォワーダーは、親ゾーンをホストしているDNSサーバーで…(以下略)」
の説明より、DNSサーバーの変更可能性があるケースではスタブゾーンを使用すべきと解釈します。※各ドメイン間にファイアウォール等が存在する場合は「条件付きフォワーダー」が優位なようですが。
PDCエミュレータのSRVレコードは
_ldap._tcp.pdc._msdcs.ドメイン名で正しいPDCホスト名(FQDN)が返るのを確認済で、
またこのホスト名を正引きすると、正しいIPアドレスが返ってくることも確認しています。 -
検証の途中結果を報告します。
それぞれのドメインコントローラーのうちの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)は全て
ドメインコントローラーの命名規則が異なるので確かに競合していません。少々準備が必要ですが、本番環境についてどちらかのドメインの
全てのドメインコントローラーのホスト名を変更してみます。結果が判り次第追って報告いたします。
- 編集済み 840 Bamboo 2015年11月13日 8:43
-
チャブーンです。
なるほど。(NetBIOS)コンピュータ名が重複していたこと、が原因の可能性があるということですね。それであれば確かにうなずけます(netdomはNetBIOS周りのチェックもしているはずですので)が、逆に腑に落ちない点として、そのような状況であればそもそも信頼構築時にエラーが出ていた可能性があること、当初の構築時に「検証エラー」が出なかったのはなぜか、という部分があります。もしかしたら、何かの状況(ネットワーク周りの環境等)でNBT周りの通信状況が構築当初と現時点で違っていた、という可能性はあるかもしれませんね。
あと、言い争うつもりは全くないのですが、私の理解では「スタブゾーン」は子ドメインをIP Reachableにするため親ドメイン上で設定する機能であり、ツリー関係にない名前空間に対して設定することは、デザイン上いささか違和感があります。名前空間上関連のないドメインについては、本来は再帰で解決する話しで、それができない場合のフォワーダ機能である、と思っています。(ご自身でもコメントされていますが)、クライアントからスタブゾーン先のDNSクエリがUnreachableの場合問題が発生しますが、これがReachableかどうかはサーバ設計者にはコントロールできない(異なる担当者が彼らの都合で設計する)ため、私個人としては「基本デザインをできるだけ外さない」ことを考えるようにしています。
フォーラムは有償サポートとは異なる「コミュニティ」です。フォーラムでご質問頂くにあたっての注意点 をご一読のうえ、お楽しみください。
- 編集済み チャブーンMVP, Moderator 2015年11月16日 2: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