none
ADドメインを別サイトへ移転する手順について RRS feed

  • 質問

  • オンプレミスのADドメイン①プライマリ②サブ(ドメインX)をクラウド環境に移転する計画中です。①②はDNSも兼ねています。

    移行方法としては、①②の入替に際して、DNSのアドレスが変わってしまうことから、

    ・ドメインY ⑩新プライマリ⑪新サブ を構築
    ・ドメインXの①②と相方向信頼関係を結び、ドメイン情報を⑩⑪へ移行
    ・ドメインXに所属するPCについて設定変更作業を順次行う。
      ・所属するグループ(ドメイン名)の変更 X→Y
      ・ネットワーク設定でのDNSサーバーのアドレス変更 ①②→⑩⑪
    ・①②のドメインサーバーからの降格、撤去

    という方法しかないのでしょうか?
    PCの設定変更作業が大変そうなので、困っています。

    • 編集済み hatsujiro 2015年3月31日 7:26
    2015年3月31日 7:26

回答

  • チャブーンです。

    ドメインコントローラの同期というのは、文字通り全情報の同期を指しますが、信頼というのは、単に相手ドメイン(のアカウントやリソース)にアクセスを許可する、ということで、中身としては全く違います。リンクについては、上げ直しておきます。

    http://www.atmarkit.co.jp/ait/articles/1406/10/news030.html

    「安全」というのは、どのような情報に対して安全策を採りたい、のかわからないので、コメントのしようがないのですが、クライアント内に格納されたデータ(ユーザープロファイルの中身等)であれば、参照DNSサーバだけを切り替えることで、データが失われることはほぼありません。サーバ側データについても(ユーザがサーバ情報をオンラインで使用中ならともかく)、これは同様です。

    この移行というのが何を指しているかあやふやですが、作業全体を1日で終わらせる必要はとくにないでしょう。GPOにより(スタートアップ)スクリプトにやらせることは、本来ユーザが書き換える「参照先DNSサーバ」を、コンピュータ起動時(ユーザがログオンする前です)に自動的に行わせるということです。スクリプト(の指示)が時限的に消えてしまうと行ったことはありませんし、重複適用されてもとくに問題はありません。必要なこの作業が全部のクライアントで完了してから、既存のドメインコントローラを降格させればよいのではないでしょうか。

    • 回答の候補に設定 佐伯玲 2015年4月6日 8:24
    • 回答としてマーク hatsujiro 2015年4月8日 9:19
    2015年4月4日 9:29
    モデレータ

すべての返信

  • チャブーンです。

    Microsoft Azure上の仮想マシン、ということでしたら、したの方法で移転が可能です。イメージとしては、新ドメインコントローラを追加ドメインコントローラとしてインストールして、旧ドメインコントローラを降格する、という一般的手順のクラウド版、になるでしょう。

    http://azure.microsoft.com/ja-jp/documentation/articles/virtual-networks-install-replica-active-directory-domain-controller/


    追記:前提として、コンピュータの設定変更が大変=現ドメイン情報を壊さずに移行したい、という流れでの回答です。
    2015年3月31日 7:44
    モデレータ
  • チャブーン様

    コメント有難うございます。

    ドメイン名を引き継いで、新ドメインを追加、旧ドメインを降格という方法だと、確かにドメイン名は変えなくても済みますね。

    ただ、DNSサーバーをDCと兼用している場合、

    同じネットワーク内のサーバーであれば、新ドメインのIPアドレスを旧ドメインのものに置きかえ、旧ドメインのIPアドレスを別のものに変えれば、DNSサーバーのアドレスは変えなくても済みますが、

    クラウドのように別セグメントのネットワークにあるサーバーの場合、明らかにIPアドレスが変わってしまうため、こうした置換ができないように思えます。

    このため、どうしてもDNSのアドレスが変わってしまうため、遠隔地のクライアント設定作業の時間を要するため、ドメインを別において信頼関係を結んだ状態で、ドメイン名とIPアドレスの変更作業をせざるを得ない、というところで行き詰っています。

    AZUREや仮想化は使ったことが無く、不勉強で申し訳ないのですが、こうしたアドレスの問題も解決できるのでしょうか?

    2015年4月1日 5:50
  • チャブーンです。

    ドメイン移行時のクライアント側の問題点として、一番問題になるのは「ドメインを移行した場合アカウントが新規扱いになる」という点です。新規扱いになったアカウントのプロファイル(とその中身)は全部新規設定の必要があり、ユーザ環境再構築にかなりの時間を割かれます。

    現ドメインをそのまま引き継いだ場合、単純に変更する必要があるのはクライアント側の「参照先DNSサーバ」、ただそれだけになります。一般的にそうならないのは「サーバ側のIPアドレス」を以前のもので使おうとするからで、オンプレミスのシステムであっても、サーバ側のIPアドレスが変われば、クライアント側の参照先DNSサーバは、必ず変更することになります。

    クライアント側の参照先DNSサーバをスマートに変えたい、ということであれば、以下の対応を検討してください。Azure VPN等で恒久的にクラウド先ドメインコントローラにアクセスできることが前提になりますが。

    1. クラウド側に追加ドメインコントローラを構成する
    2. (この段階で)クライアント側の参照先DNSサーバをクラウド先IPアドレスに変更する(スクリプト等で)
    3. クライアント側の設定変更がすべて完了してから、オンプレミス側ドメインコントローラを降格する

    新旧両方のドメインコントローラ(DNSサーバ)が生きている状態であれば、仮にGUIで参照先DNSサーバの設定を変えたとしても、「設定作業の成功・失敗」に左右されず、ログオン認証を継続できます。つまりリモートで操作していても、影響は最小限ですみます。

    スクリプトで、といっているのは、100台単位のクライアントに手動で設定することは大変ですし、スタートアップスクリプトなら簡単に変更作業ができるからです。お気に召さない場合、手動でやっていただいても結果は同じ(一瞬切れる可能性はありますが)と思われます。


    追記:クラウド側ドメインコントローラのIPアドレスが(DHCPで割り振られているため)、予期せず突然変わってしまう、と思っておられるなら、そのようなことはありません。ただし必要な手順を守る(最初に紹介したリンク内に方法が書いてあります)必要があります。
    2015年4月1日 6:13
    モデレータ
  • チャブーン様 コメント有難うございました。

    新ドメイン名を変える場合は、ドメイン参加の作業になるので、PCの移行と同じような手順でマイドキュメント等のアカウント別フォルダをバックアップしてドメイン参加後に元に戻すという面倒な作業が必要になる訳ですね?仰る通り、それだけは避けたいと思っています。

    >新旧両方のドメインコントローラ(DNSサーバ)が生きている状態であれば、仮にGUIで参照先DNSサーバの設定を変えたとしても、「設

    >定作業の成功・失敗」に左右されず、ログオン認証を継続できます。つまりリモートで操作していても、影響は最小限ですみます。

    と書かれておられるように、旧DCから新DCにドメイン情報をコピーし、信頼関係がある状態だとすれば、最初にログインする時の状態(設定DNSのアドレスが旧DC=旧DNS)でも、そのスクリプトが有効?で、最悪失敗したとしても、認証は継続できているので、リモートデスクトップなどでなんとか手動リカバリは可能ということでしょうか?

    度々の質問で申し訳ないですが、遠隔地でリモート操作が出来ないということになると、業務が止まってしまうというリスクだけが心配です。

    2015年4月2日 2:21
  • チャブーンです。

    基本的には、おっしゃる通りの認識になります。ちなみに追加ドメインコントローラというのは、同一ドメインのコピー(レプリカ)としての存在ですので、信頼(=異なるドメイン間での認証関係)という概念はありません。ドメインコントローラのレプリカ、について、念のため以下から再確認いただくとよいと思われます。

    http://www.atmarkit.co.jp/ait/articles/1406/10/news030.html

    スタートアップスクリプトについては、したの資料が参考になると思われますが、台数が少なければ、手動で行われた方がよろしいかと思います。

    https://technet.microsoft.com/ja-jp/windowsserver/ff476945.aspx

    なお、リモート接続状態のまま、ネットワーク情報を書き換えつつも、接続を完全担保する(リスク0のネットワーク接続変更方法)はありませんので、最小限のリスクについては、ご理解いただく必要があります。


    2015年4月3日 3:07
    モデレータ
  • チャブーン様 コメント有難うございました。

    理解不足で度々の質問をご容赦下さい。

    http://www.atmarkit.co.jp/ait/articles/1406/10/news030.html

    がリンク切れになっておりましたので、確認させて頂きますと、ドメインが同じ場合はレプリケーション、異なる場合は相互信頼関係の構築ということで結果としては、ともに2つのサーバー間で同期をとることができるように理解しました。

    今回、作業を依頼するベンダーは、移行を段階的に行うためには、ドメインを別にして段階的に新ドメインへ参加する手順をスクリプトで行うほうが安全であるという見解なのですが、ネットワーク接続についてのリスクは共通であることを考えると、ドメインを同じにして、DNSサーバーのアドレスを変えるほうが、スクリプトで行う変更の作業量も少ないのでリスクは少ないように思えて仕方ないので、質問させて頂いた次第です。

    端末の作業台数が200台なのですが、ログオンの認証を継続させておくには、この移行を1日内の作業で完結させる必要がある訳なのでしょうか?


    2015年4月4日 7:05
  • チャブーンです。

    ドメインコントローラの同期というのは、文字通り全情報の同期を指しますが、信頼というのは、単に相手ドメイン(のアカウントやリソース)にアクセスを許可する、ということで、中身としては全く違います。リンクについては、上げ直しておきます。

    http://www.atmarkit.co.jp/ait/articles/1406/10/news030.html

    「安全」というのは、どのような情報に対して安全策を採りたい、のかわからないので、コメントのしようがないのですが、クライアント内に格納されたデータ(ユーザープロファイルの中身等)であれば、参照DNSサーバだけを切り替えることで、データが失われることはほぼありません。サーバ側データについても(ユーザがサーバ情報をオンラインで使用中ならともかく)、これは同様です。

    この移行というのが何を指しているかあやふやですが、作業全体を1日で終わらせる必要はとくにないでしょう。GPOにより(スタートアップ)スクリプトにやらせることは、本来ユーザが書き換える「参照先DNSサーバ」を、コンピュータ起動時(ユーザがログオンする前です)に自動的に行わせるということです。スクリプト(の指示)が時限的に消えてしまうと行ったことはありませんし、重複適用されてもとくに問題はありません。必要なこの作業が全部のクライアントで完了してから、既存のドメインコントローラを降格させればよいのではないでしょうか。

    • 回答の候補に設定 佐伯玲 2015年4月6日 8:24
    • 回答としてマーク hatsujiro 2015年4月8日 9:19
    2015年4月4日 9:29
    モデレータ
  • チャブーン様

    お返事が遅れまして失礼いたしました。

    リンク先並びに今までのコメントを再度拝見させて頂きまして、仰るような移行手順で問題ないのではないかと再確認しました。

    ベンダーと再度話し合って作業手順を決めたいと思います。

    長々とご対応有難うございました。

    2015年4月8日 9:18