同じＤＮＳドメイン、異なるNetBios ドメイン名、間での信頼関係の設定

すべての返信

• 

  

  0

  サインインして投票

  Alec - アレック さん、こんにちは。フォーラムオペレーターの鈴木裕子です(^O^)／

  ドメイン名をリネームせずに信頼関係を構築して、アカウントの移行をされたいということですね。
  ご希望のような設定を可能にする方法がないか調べてみたのですが、残念ながらご希望に沿えるような情報が見つからず、ちょっと難しいのかなと思いました。
  USのExpertsExchangeという掲示板に同じような質問があったのですが（http://www.experts-exchange.com/OS/Microsoft_Operating_Systems/Server/2003_Server/Q_23014352.html）、ついていたRESは、やはりリネームする必要があるという内容で。。。

  「できません」と明記された情報は見つからなかったのですが、↓こちらのTechNetライブラリの記述を読んでみても、別フォレストで、同じDNS名を持つドメイン間では、やはり完全な信頼関係というのは難しいのかなと思います。

  フォレスト間で名前サフィックスをルーティングする
  http://technet.microsoft.com/ja-jp/library/cc784334.aspx

  ただ、実際に環境を作って試してみたわけではないので、外していたらごめんなさい！ご参考となれば幸いです。

  ---

  マイクロソフト株式会社　フォーラムオペレーター　鈴木裕子

  2009年4月20日 9:28

  返信

  |

  引用

  モデレータ
• 

  

  0

  サインインして投票

  鈴木さん、
  
  こんちには。お世話になります。ご返答頂きまして、ありがとうござます。
  
  やはり、ドメインをリネームしないと難しいようですね。
  リネームは、ロールバックが難しいようですので、出来ればリネームせずにドメインの移行が出来ればと思っていました。
  
  同じ名前の、全く別のフォレストで、ドメインをリネームせずに統合するとなれば、後は、同名アカウントのパススルーログオンしかないかと思うのですが、
  今のところ、この方法もうまくいっておりません。
  同じＩＤ、パスワードを、別フォレストの両ＤＣ上に作成して、別ドメインに所属するＰＣから別ドメインのファイルサーバにアクセスしようとするのですが、認証用のポップアップがでてきてしまい、パススルーされません。
  別ドメインのＰＣから、別ドメインのＤＣ上の共有には、パススルーで接続出来るのですが、ファイルサーバ上の共有では、認証の受けうまくいかないようです。
  また、ＤＣの共有にアクセスしている時は、ケルベロスで、ファイルサーバにアクセスしている時は、何故か、ＮＴＬＭでアクセスしようとしているようです。
  
  2000の時代に信頼関係なしで、パススルーでうまくドメインの統合が出来た記憶があるのですが、なにか勘違いをしているかもしれません。
  別フォレストで信頼関係なしで、パススルーログオンが出来るかご存知ありませんでしょうか。
  
  大変お手数ですが、どうぞよろしくお願い致します。
  
  Exterper Exchangeは、検索するたびに、出ててきて、欲しい情報がよく記載されているのですが、いかんせん有料なので利用したことはないんです。

  2009年4月21日 5:35

  返信

  |

  引用
• 

  

  0

  サインインして投票

  チャブーンです。
  
  がっかりされるかもしれませんが、結論としてはムリ、以上のことはいえないのではないでしょうか？
  
  ここの資料にこんな文面があります。
  
  ----
  DNS に関する注意事項

  Reskit フォレストおよび Acquired フォレストのドメイン コントローラから相互に接続できるようにするには、ドメイン ネーム システム (DNS) をセットアップして、各フォレストのサーバーで相手フォレストの信頼される側のドメイン内のサーバー名を解決することができなければなりません。Acquired 部門および Reskit 部門はともに、内部でプライベートな名前空間を持ちますが、一方の名前空間のコンピュータで他方の名前空間の名前を解決できるように DNS を構成する必要があります。この構成について詳しくは、『Microsoft Windows 2000 Server リソース キット 6 TCP/IP ガイド』の「第 6 章 Windows 2000 DNS (概要紹介) 」 (英語) を参照してください。
  ----
  
  うえの文面は、フォレスト間は(NTLM信頼関係であっても)「DNSベースで双方の名前解決ができなければならない」ということをいっています。おなじDNS名同士のフォレストの場合、DNS名前解決リソースの参照先として、自分自身と相手側を区別する方法がないので(これはDNSの実装上やむを得ないことです)、どうやってもDNSベースで名前解決を実行する、ということはできないのです。
  
  うえの資料の他にも、「DNSベースでの名前解決は必須」という資料はいくつかあったはずで、挙動上からも、相手先が Windows NT 4.0ドメインの場合を除いて、必ずDNSベースでの名前解決を使って信頼関係を作成する、という実装として理解しています。
  
  それと細かいことですけれど、
  
  > 同じＩＤ、パスワードを、別フォレストの両ＤＣ上に作成して、別ドメインに所属するＰＣから別ドメインのファイルサーバにアクセスしようとするのですが、認証用のポップアップがでてきてしまい、パススルーされません。
  
  これは当たり前の実装です。ドメインに入っていないコンピュータから別のコンピュータにアクセスした場合、そのセキュリティ範囲は「アクセス先のローカル(コンピュータ)SAM」を参照します(ワークグループはこの実装で動作します)。別ドメインのドメインコントローラなら「ローカルSAM」にドメイン情報自体があるのでワークグループ相当として動作しますが、メンバサーバの場合ローカルSAMにはドメイン情報がないので、当然アクセスができないのです。
  
  この場合は、アクセス元のコンピュータがドメインレベルの名前解決ができ、ドメインコントローラが正しく検索できる状況になっていることが必要です。たとえば、同じネットワークセグメントにあるコンピュータ同士で、「なんの名前解決の設定しなくてもうまくいった」ように見えるとき、それはブロードキャストによるNBTベースの名前解決が実行され、ドメインレベルでの名前解決がうまくいったから、ということになると思いますよ。
  

  • 回答としてマーク 鈴木裕子Support Engineer, Moderator 2009年4月30日 8:29

  2009年4月21日 8:39

  返信

  |

  引用

  モデレータ
• 

  

  0

  サインインして投票

  チャブーンさん、

  ご返答ありがとうございます。

  やはり、無理ですか・・・netdom trust でも、信頼関係のウィザードでも、NetBiosドメイン名の指定だけを要求される（ＮＴドメインの為の実装）ので、同名ＤＮＳ名でNetBiosドメイン名が異なれば、もしやと思っていたのですが、非常に残念です。

  そうなると、ドメインをリネーム以外の方法で、同名ドメイン間でユーザの認証を行うには、同名アカウントのパススルーしかないかなと考えたのですが、
  確かに、異なるドメイン間ですので、あるＰＣがケルベロス認証でＫＤＣから配布されたアクセスキーを使って、他のドメインにあるサーバにアクセスするのは、無理かなとは思ったのですが、別ドメインのＤＣ上の共有へは、ケルベロス認証でパススルー出来ていたので、別ドメイン上のＫＤＣから新たに認証を受けてアクセスキーの取得が可能になるのではと、考えていました。
  結局は、単にＡＤデータベースを、ローカルＳＡＭとして、参照していただけなのですね。

  ＤＮＳ名ではなく、NetBiosドメイン名も同じにすれば、異なるドメイン間でもパススルーは可能ではないのかなと思ってテストしたらうまくパススルー出来ました。
  というのも、ファイルサーバアクセス時に、当然ケルベロス認証は失敗するので、ＰＣはＮＴＬＭを使用することになり、ＮＴＬＭだとケルベロスと違って毎回、ユーザ名とパスワードをＤＣに認証をおこないに行くからです。

  手間はかかりますが、移行先ドメインを一旦削除して、NetBios名を同じにして再構築して、パススルーで徐々にＰＣを移行していくか、単純に、全てのサーバで、一旦Anonymous ログオンを有効にする方法でいこうかと考えています。
  ドメインをリネームして、移行ツールで移行するのが手っ取り早いと思うのですが、ロールバックがきかないので、リスクが高いかなと躊躇しております。

  2009年4月22日 8:47

  返信

  |

  引用
• 

  

  0

  サインインして投票

  こんにちは、フォーラムオペレーターの鈴木裕子です(^O^)／
  
  チャブーン さん、回答ありがとうございました！
  
  Alec - アレック さん、その後いかがでしたか？
  最終的にどのような形で移行が完了されるのか、気になるところですが、同様の情報を探している方がいらしたら、こちらのスレッドが大変参考になるのではないかと思いまして、勝手ながら私のほうで、チャブーンさんの投稿に[回答としてマーク]をつけさせていただきました。ただ、不適当と思われた場合や、疑問が解決していないような場合は、遠慮なくチェック解除してください。
  
  お時間のある時で良いので、よろしければその後の経過を教えていただけるとたいへん嬉しいです（＾－＾）
  
  これからも、皆様の情報交換の場としてForumを活用してくださいね。質問、コメントともどもお待ちしています！
  

  ---

  マイクロソフト株式会社　フォーラムオペレーター　鈴木裕子

  2009年4月30日 8:35

  返信

  |

  引用

  モデレータ
• 

  

  0

  サインインして投票

  鈴木さん、
  
  お世話になります。
  
  まだ、検証中ですがおそらく短期間、Anonymous ログオンを有効にすることになると思います。
  
  ありがとうございました。

  2009年5月1日 0:46

  返信

  |

  引用
• 

  

  0

  サインインして投票

  チャブーンです。
  
  ＃書こうかどうか迷ったのですが...
  
  お話を統括？するとですが、結論からいえば「労多くして実りナシ」としかいいようがないのではないでしょうか？
  
  「移行」というところで何がされたいのかわからないところがありますが、「パススルー認証」とやらで相手先ドメインの情報を呼び出せたとしても、これは単にアクセス元のコンピュータが単体で、アクセス先の管理者アカウント名義でアクセスしているだけの状態です。
  
  フォレスト間のアカウントの移行では、情報の操作を移行先・移行元双方で行なうことになりますので、情報の受け渡しを担当するプログラムが「どのアカウント権限で動作しているか」によって、アクセスできる情報が変わってきます。たとえば ADMT では(動作させる)移行先ドメインの管理者アカウントを移行元ドメインのBuiltin\Administratorsグループのメンバとして設定しますが、これは ADMT が情報の読み書きに移行先・移行元双方での管理者アカウントを必須としているためです。パススルー認証のような「アクセス元とアクセス先でアカウント自体が実は異なっている」場合、特定のプログラムによる操作で、情報の受け渡しや動作がうまくいかない可能性が高いでしょう。
  
  あと、これは重大なことですが、おっしゃる方法は MS 側で想定された=サポートされたやり方ではない、ということです。開発元(MS)が想定しない方法で作業して、後で何か問題が起こっても「自己責任でお願いします」ということになると思うので、そこは十分注意した方がいいと思いますよ。
  
  「ドメイン名を変えずにドメインコントローラ(やOS)を入れ替えたい」という場合、現環境に Windows Server 2003 などを「追加ドメインコントローラ」として追加して、以前のドメインコントローラを降格させる、という方法が一般的です。何か問題が起こったときのことを考え、普通は導入前に全ドメインコントローラ(最低でも 1 台)のフルパックアップを取っておきます。

  2009年5月1日 1:49

  返信

  |

  引用

  モデレータ
• 

  

  0

  サインインして投票

  チャブーンさん、

  ご指摘ありがとうございます。

  移行に関しての説明が足りなかったようです。
  パススルー認証を使用して、ＡＤＭＴを使用するつもりではないのです。

  現在ユーザ数3万ほどのグローバルなシングルフォレスト、シングルツリーのドメインがあります。仮にtest.comとします。
  以前は、物理的にネットワークがつながっていなかった為に、ある国のドメインがcountry.test.comとして、グローバルなフォレストとは別に存在しています。
  今回は、このcountry.test.comのドメインのユーザアカウント、ＰＣアカウント（共に500ほど）を、グローバルなtest.com下に、同名の、country.test.comとして統合しようとしております。
  NetBiosドメイン名は変更可ですが、DNSドメイン名は、ＩＳＯのスタンダードにしたがっているので変更不可です。
  通常は、ＡＤＭＴでアカウントを移行するのですが、ＤＮＳドメイン名が両フォレストで同じ為に、信頼関係を結ぶことが出来ませんでした。
  ＡＤＭＴでの一括したアカウントの移行が無理なようでしたら、ローカルのＩＴが順序ＰＣアカウントのドメインへの再参加をおこなわないといけないのですが、その間、プリンタ、ファイルサーバなどのリソースへのアクセスが出来ません。（ユーザアカウントの作成はスクリプトで自動化します）
  ですので、移行の間、パススルーで認証をスルーさせるか、Anonymous ログオンを有効にさせて、リソースにアクセスさせる方法しかないかなと考えておりました。
  ＮＴＬＭのパススルー認証はよく覚えていないのですが、Anonymous ログオンはＭＳのサイトに載っているのでサポートされているのかと。サポート外でもどのみちやらないといけないのですが。
  確かにおっしゃるとおり、いろいろと調べたわりには、結局はAnonymous ログオンかよという感じですが、ちょっとは勉強になったのでまあ良かったかなと思っています。

  2009年5月1日 7:01

  返信

  |

  引用