AADC(Azure AD Connect)の移行

こんにちは。

社内オンプレミスにあるサーバー群をクラウドへ移行する顧客も最近になって多くなってきており、その際にADからAzureADへとオブジェクト同期を行っているAADC(Azure AD Connect)サーバーの移行もあわせて必要とするケースが増えてきた印象です。
(いつかはこのハイブリッド構成もなくなるのでしょうが、それまでは移行が必要かと。)

久しぶりにAADC移行を行ったこともあって少し忘れていたので備忘録もかねてAADCサーバーの移行について今更ながらですが、まとめてみました。


本記事が参考にあれば幸いです。

AADCの移行パターン

すでにADからAADCを介してAzureADへと同期を行っている環境において、AADCの同期パターンはいくつかあると思っております。

同期元ADが変わらない場合

①のように同期元ADが何も変わらず、AADCだけを移行する場合については特に同期オブジェクト(ユーザーやグループなど)を気にする必要があまりありません。ただ新規AADCからちゃんと同期されている構成(旧AADCと同様に同期対象が設定できているか)をとれているかは確認する必要があります。

同期元ADが変わる場合

一方、②、③のようなADサーバーを別のADまたは新規AD構築(フォレストが変わる)する場合においては注意が必要です。
この場合、すでに旧ADとAzureADとの間でオブジェクトはハードマッチされている構成となっております。
したがって新ADで運用するためには新ADにあるオブジェクトとAzureADのオブジェクトをハードマッチさせ、同期状態にする必要があります。

AADCの移行に必要なこと

基本的には、新AADCをステージングモードとして構成し、旧AADCをステージングモードにして新AADCをアクティブにする切替手順に変わりはありません。
しかし、よく旧AADCサーバーのバージョンがあまりにも古かったり、Syncルールをカスタムしている環境が稀にあります。
その場合、新AADCで最新のバージョンで移行を試みると、バージョンによる設定差異や、編集したルールが反映されなかったりなどによって同期オブジェクトに影響が発生する可能性もあります。

旧AADC環境のバージョンが古い場合の一般的な移行方法

ざっくり進め方としては以下になります。※あくまで参考例なので環境によって変わります。

  1. 新AADCサーバーを旧AADC サーバーと同一バージョンとしてステージングモードで構築
  2. 新AADCサーバーと旧AADC サーバーをCondigrationDocumenterツールで比較
  3. 設定比較に問題がないことを確認し、新AADCサーバーを最新バージョンへアップグレード
  4. 最新バージョンの新AADC サーバーがステージングモードで正しく動作していることを確認
  5. CSExportAnalyzerツールにてエクスポート結果を確認し、影響がないことを確認
  6. 旧AADCサーバーをステージングモードへ変更
  7. 新AADCサーバーをアクティブモードに変更
  8. 新AADCにて運用開始

以降ポイントごとに補足します。

①新AADCサーバーを旧AADC サーバーと同一バージョンとしてステージングモードで構築

旧AADCサーバーにモジュールがある場合に限りですので、スキップしても移行はできるため必須ではないです。あればなおよしといった形で認識しております。ただし、後続手順書の設定比較ツールとエクスポート結果確認が困難になります。

この新AADCサーバーを構築するときですが、当然ながら、旧AADCと同じ設定で合わせる必要があります。環境に応じて様々な方法がありますが、以下Microsoft社でもAADC移行時の設定情報のImport/Export手順が公開されていますので、こちらをご参考に構築いただければと思います。
今回の本記事ではそこまで旧AADCをカスタマイズなどは行っておりませんので、すべて手動でインストールを行います。

Azure AD Connect 移行に伴う設定情報の Export / Import

現在ご利用環境のバージョンが 1.5.4x.0 未満、かつ、別のサーバーに新規に Azure AD Connect インストールし、利用環境の設定情報を復元する場合の方法です。
例えば、現在利用している Azure AD Connect のバージョンが 1.1.647.0 で 1.5.45.0 にスイング アップグレードするために、追加で Azure AD Connect 用にサーバーを構成し、Azure AD Connect の各種設定を行う場合が想定される方法となります。



②新AADCサーバーと旧AADC サーバーをCondigrationDocumenterツールで比較

古くからAADCを導入してOffice365を利用されている環境ですと、時々旧AADCのバージョンが結構古い場合やカスタムルールを独自で設定されている場合などがあります。
新AADCと旧AADCで設定状態に差異が大きくあると同期オブジェクトに影響が発生する可能性も否定はできないと思います。

そこで以下ツールを利用し、設定に差異がないかを事前に確認しておくことでより同期オブジェクトへの影響が発生する可能性を少なくできると思います。

CondigrationDocumenterツールは以下が参考になります。

Azure AD Connect Sync Configuration Documenter 使用方法 | Japan Azure Identity Support Blog (jpazureid.github.io)


③設定比較に問題がないことを確認し、新AADCサーバーを最新バージョンへアップグレード

①の手順で旧AADCのモジュールが残存し、同じバージョンのAADCを用意できた場合に限ります。
旧AADCのモジュールがなかった場合はスキップします。


⑤CSExportAnalyzerツールにてエクスポート結果を確認し、影響がないことを確認

いざ同期を行ったときに同期オブジェクトがどうなるのか、事前に確認可能としてくれるのが以下Microsoft社で公開されているツールになります。

詳しくは以下公開情報にわかりやすく記載いただいているのでこちらを確認いただく方が良いと思っております。
※注意点としては、記事の最後に記載の通り、ソフトマッチケースでは利用できないということです。
 あくまでAADCが把握している情報でしか、確認ができないことを前提とし、利用する必要があります。

CSExportAnalyzerツールは以下Microsoft社にて公開されている情報が参考になります。

ステージング サーバーのすゝめ | Japan Azure Identity Support Blog (jpazureid.github.io)

補足:ハードマッチ

次にハードマッチについてです。このケースは同期元のADが変わる場合に必要となる作業です。
冒頭で説明した図ですと、②と③がのケースが本作業が必要となります。
以下のMicrosoft社の公開情報が一番わかりやすいと思います。

ハードマッチによる同期ユーザーの切り替え方法 (AD フォレスト移行 編)

今回は、オンプレミス AD フォレストの移行を検討されている方々に向けて、既存の AD フォレストと同期している Azure AD ユーザーを新しい AD フォレストに紐付け替える方法についてご紹介したいと思います。

このハードマッチについてを簡単に図にしてみると以下のようになります。
よくあるのが、昔のAADCはADとAzureADの紐付け属性(ソースアンカー)として設定されているのが、ADの”ObjectGuid”という属性になります。この属性はオブジェクトを作成した時点でシステム側で勝手に作成される属性なので、新AD側に持って行くことができません。(左の図の通り)

そこでソースアンカーをms-DS-ConsistencyGuidに変更し、これまで”ObjectGuid”に設定していた値を新ADサーバーの”ms-DS-ConsistencyGuid”に設定することで紐付けを行います。
なお、AADCから同期される際は、ObjectGuidの値を「Base64」形式に変換し、AzureADのImmutableIDにセットしています。(”8UG6k+o8zpkv3+rEw==”みたいな値が入ってます。)

ただし、このObejctGuidの値を新ADに持っていく際、UIベースで手動でコピー&ペーストであればなんら問題ありませんが、Powershellの場合は注意が必要です。Powershellの場合、単純な値設定だけではうまく値が設定されません。

よくやりがちなのですが、PowerShellで通常通り設定すると、取得したGuid値をそのままセットしてもGUI上は設定されているように見えますが、実際には値としては正しく設定されていないことがわかります。

とはいえ、大多数のユーザー数がいる環境において、手動によるコピペを行うのは無理だと思います。
なのでもし、Powershellによる一括操作手順を詳しく知りたいという場合、少し説明が長くなるため、以下お問い合わせフォームにてご連絡いただければと思います。

お問い合わせ

お仕事依頼やお問い合わせ/技術交流や趣味を通したご質問ありましたら、以下お問い合わせフォームからお気軽にご連絡ください。

やってみる

それでは実際にざっくりやっていきます。
今回のケースとしては、ADの同期元は変わらずシンプルにAADCのみを移行する手順で進めていきたいと思います。

まずは旧AADCのバージョンを確認します。
これは単純に旧AADCサーバーにログインしてバージョンを確認するわけですが、[プログラムと機能]一覧から確認するのが手っ取り早いと思います。

バージョンを確認後、旧AADCサーバーにモジュールが残っていれば、新AADCサーバーへコピーして旧AADCバージョンでインストールした後に最新バージョンにアップグレードする手順が望ましいです。
理由は移行方法の章でも記載の通り、バージョンが一致している状態でないと設定比較ツールがあまり有効ではなくなるためです。
とはいえ、旧AADCサーバーにインストールモジュールを残しているケースはあまり少ないと思うので、その場合は目視による設定値比較と同期オブジェクトの事前確認(CSExportAnalyzerツール)で対応することになります。
新AADCサーバーを新しいバージョンで構築後に実際見てみましょう。

次に新AADCサーバーを構築していきます。

ダウンロードした最新のインストールファイルを実行し、AADCウィザード画面に沿ってインストールを進めていきます。インストール手順はすでにブログなどで素晴らしい手順が公開されているのでそちらをご確認いただけたらと思います。

なお、旧AADCもそこまでカスタマイズなどは行っていないため、サクッと新規インストールで進めていきます。

よくあるのが、新AADCで同期対象のADを追加しようとすると、以下のようなエラー(通信に失敗しているようなエラー)が出力されたりします。

この時AADCはフォレストルートのADだけでなく、その他ドメインツリーのADも接続するため、接続できない場合はエラーとなってインストールを進めることができません。

以下を参考にAD疎通確認などのトラブルシューティングが必要となります。

Azure AD Connect:ADConnectivityTools PowerShell リファレンス

https://docs.microsoft.com/ja-jp/azure/active-directory/hybrid/reference-connect-adconnectivitytools

ディレクトリ(同期元AD)を追加できたら次はこのインストールウィザード実行時のポイントともなります、同期対象OUの指定です。
旧AADCと新AADCで同期元ADは同じであっても同期対象のOUに差異があると、切替を行った際に差分分のオブジェクトに影響が発生することになります。
一番よくないのは、新AADC側の同期対象OU設定が旧AADCよりも少ないことであり、この場合は切替後に同期オブジェクトが削除されてしまう可能性があります。ですので設定値は合わせておくことが必要です。


次にソースアンカーについてです。
本記事のハードマッチ章で説明している通り、旧AADCのソースアンカーが”ObjectGuid”の環境において同期元ADの変更が必要な場合は、新AADCのインストール手順では、”ms-DS-ConsistencyGuid”を選択する必要があります。
なお、この設定は初回インストール時にしかできないので、あとから変更できません。
変更が必要な場合は、AADCを再インストールする必要があるので、これまでセットアップしてきた手順をもう一度実施する必要が出てきます。

インストールウィザードを進められたら最後も注意が必要です。
新AADCをインストールしている時点ではまだ、旧AADCが同期を行っております。
その状態で新AADCも同期がアクティブになってしまうと、旧AADCと新AADCがお互い同期を実行してしまうことになります。
まだ、新AADCの設定値が問題ないかとCSExportAnalyzerツールを用いた、オブジェクト同期の事前確認もできていないので、何が起こるかわからない状態のため、ステージングモードとして構成しておくようにします。
加えて、インストール構成が完了後、すぐに同期が実行されるプロセスも実行しないようにチェックを外しておきましょう。


インストールが完了したら次は設定パラメータの比較です。
お伝えした通り、本ツールはかなり設定値を細かく見てくれるツールなのでAADCのバージョンを合わせておいた状態で実施することがベストです。
今回、バージョンをあわせていないのであくまで参考までとして記載します。

AADCの設定値の比較は以下のツールを使って行います。
Microsoft社の公開情報の通り、まずはツールをダウンロードします。
本ツールは比較ツールであり、データはAADCからコマンドにて取得しますので、作業端末などにダウンロードしておいて問題ないです。

microsoft/AADConnectConfigDocumenter

https://github.com/Microsoft/AADConnectConfigDocumenter/releases

ダウンロードしたZipファイルを展開し、「AzureADConnectSyncDocumenter\Data」フォルダに旧AADCと新AADC用のフォルダを任意のフォルダ名で作成しておきます。
デフォルトの「contoso」フォルダは特に不要なので無視で構いません。

次に、設定値を比較するために旧AADCと新AADCで情報取得を行います。
これは、AADCサーバー標準で用意されている設定値を確認するコマンドです。

Get-ADSyncServerConfiguration -path "出力先パス"

取得すると、以下のフォルダが作成されますがすべてのファイルを先ほどツールダウンロードした作業端末にコピーします。コピー先は「AzureADConnectSyncDocumenter\Data」フォルダ配下に作成した任意のフォルダになります。

次にバッチファイルを編集し、今回情報取得したフォルダを参照するようにします。

対象のバッチファイルを右クリックし、[編集]をクリックします。
1行目のコマンドで今回情報取得した設定ファイルを参照するようにファイルパスを修正し、保存します。

準備ができたら、コマンドプロンプトを起動し、本ツールがあるフォルダに移動します。
移動後、以下のコマンドを実行します。

.\AzureADConnectSyncDocumenter.cmd

すると生成処理が動作し、最終的に比較した結果が[AzureADConnectSyncDocumenter]フォルダの配下に[Report]フォルダが作成され、html形式として出力されます。

htmlファイルを開くと以下のような画面が表示されます。
水色の字の部分は目次みたいなもので実際の設定値は下にスクロールすると確認することができます。
画像上部にある通り、字の色が差分結果を示してくれており、赤字がDelete(削除)、青字がUpgrade(更新)、緑字がCreate(作成)になっています。

例えば、AADCの基本設定を見てみます。
[Global Settings]をクリックしてみると、実際の設定値まで飛ぶことができます。
黒枠で囲っている部分を見ると、[AutoUpgradeState]が青字で”Enabled”になっていることから、新AADCでは自動アップグレード機能を有効にしていることがわかります。
逆に言うと、旧AADCはアップグレード機能を無効にしていることがわかるため、設定値に差分が生じていることが確認できるというわけです。

また、AADCSyncルールもかなり細かく比較されるため、すごく便利なツールであることは間違いありません。
ただ、あまりにもバージョンに差異があると、どうしてもバージョンアップによってルールが新たに追加または更新されることは避けられないので、設定値の差分が大量に発生し、本ツールの効果がなくなってしまいます。
したがって本ツールを使う場合は、バージョンをなるべく合わせておくと、効率的な設定値比較が行えるため、切替は計画的に遂行する必要があるということです。

では最後の確認ポイントになります。
新AADCへ切替後、どのようにオブジェクトが同期されるのかを確認する”CSExportAnalyzer”ツールですが、ソフトマッチシナリオでは利用できないことを再度記載しておきます。
あくまでAzureADとADが同期(紐づいている)されているオブジェクトのみに対して確認することができます。

こちらのツールについては、特にダウンロードなどは必要ありません。
まず対象サーバーである新AADCにログインします。

次に以下のコマンドでステージングモードであるかをもう一度確認しておきましょう。
オブジェクトの確認のためには新AADCで一度同期実行を行う必要があるため、万が一アクティブモード状態ですと同期を実行したタイミングですぐに処理が走ってしまいます。

差分同期が無効(FALSE)、ステージングモードが有効(TRUE)であることを確認します。

SyncCycleEnabled:FALSE
StagingModeEnabled:TRUE

Get-ADSyncScheduler

ステージングモードであることを確認出来たら、フル同期を実行します。

Start-ADSyncSyncCycle -PolicyType Initial

次にコネクタの名前を取得します。後ほど実行するコマンドで明示的にコネクタの名前を指定する必要があるためです。

Get-ADSyncConnector | fl name

コマンドプロンプトを起動し、ツールがある場所まで移動します。

cd C:\Program Files\Microsoft Azure AD Sync\Bin

あとはコネクタごとに2種類のコマンドを実行します。

1つはxml形式のコマンド、もう1つはそのxml形式のファイルをcsv形式に変換するコマンドです。
両コマンドをそれぞれ各環境のコネクタ名指定、および任意で出力先を修正します。
1つ目のコマンド:
csexport.exe “コネクタ名” 出力パス\ファイル名.xml /f:x
2つ目のコマンド:
CSExportAnalyzer.exe 1つ目で出力したxml形式ファイルのファイルパス > 出力パス\ファイル名.csv

もし、以下のエラーが出力された場合、コネクタ名もしくは、指定したファイルパスまたはファイル名に不備がある可能性があります。
私も実施してよくあったのが2つ目のコマンドでファイルパスまたはファイル名間違いによる例外エラーでした。

正常にコマンドが完了すれば、指定したファイルパスに出力結果のファイルが生成されます。
実際にこのファイルを見てみましょう。

以下のように確認するポイントは大きく2つです。
ひとつは赤枠の”OMODT”列はオブジェクトの変化を表しています。
そしてもう一方の青枠の”AMODT”列は属性の変化を表しています。

以下例では、どちらもAddになっていることから新規追加オブジェクトであることがわかります。
もし、属性だけの更新であれば、OMODTは”Update”、AMODTは”add/Update/Delete”のいずれかになるというわけです。

なお、今回出力したファイルは2つありましたが、それぞれコネクタごとにコマンドを実行していました。つまりは、ADへのエクスポート×ADドメインコネクタ数+AzureADへのエクスポート1つ(xxx-AADという名前)分が出力結果として出力されることになるので、同期元のフォレストドメインが多い環境では確認が少し大変になります。。。

切替前の同期オブジェクトの結果に以上がなければ、最後にステップとして、⑥旧AADCサーバーをステージングモードへ変更、⑦新AADCサーバーをアクティブモードに変更を行えば完了となります。

おまけ

同期対象OU設定方法の差異によるDocumenterツール出力結果の違い

実際にあったのですが、Documenterツールでほんの少しの設定方法による違いで出力結果が異なった例を記載します。

同じように同期対象OUにチェックを入れていることに間違いはありませんが、左の旧AADCはフォレストルートドメインのチェックを外さずに同期対象外のOUを除外する手順で設定しております。

一方、右側の新AADCはフォレストルートドメインのチェックを外し、同期対象OUのみをチェックするという手順です。

この場合、Documenterツールは以下のように出力されます。
左の旧AADCは一つ一つのOUを同期対象から除外する設定であったため、同期対象外OUにはExcludeとして表示されています。

これを新AADCでは、一つ一つのOUを除外する手順ではない方法で設定したため、以下のように差分として出力されていると思われます。


新AADC構築時の設定情報のImportとExportについて(MigrateSettings.ps1)

冒頭で少し触れさせていただきました、以下Microsoft社公開のツールについてですが、実際に使ってみましたが、かなり助かるツールでした。。同期対象OUの設定情報などもほとんどが引き継がれていたため、これまで設定情報などをいちいち、ウィザードで確認しながら設定していた分の工数などが削減されそうです。
ただ、留意事項などもあるので、その点公開情報を確認いただくことに加え、新AADC構築後は本ブログでも掲載している通り、設定情報の比較などの手順は一応実施しておくほうが良いと思います。

すでに以下Microsoft社ブログにて公開されていますが、ざっくり手順を記載します。

Azure AD Connect 移行に伴う設定情報の Export / Import

現在ご利用環境のバージョンが 1.5.4x.0 未満、かつ、別のサーバーに新規に Azure AD Connect インストールし、利用環境の設定情報を復元する場合の方法です。
例えば、現在利用している Azure AD Connect のバージョンが 1.1.647.0 で 1.5.45.0 にスイング アップグレードするために、追加で Azure AD Connect 用にサーバーを構成し、Azure AD Connect の各種設定を行う場合が想定される方法となります。

まず、旧AADCサーバーにて、MigrateSettings.ps1ファイルをダウンロードし、実行します。

実行すると、「C:\ProgramData\AADConnect」配下に”Exported-ServerConfiguration-xxxxxxxx”というフォルダが作成されるため、この配下のファイルを新AADCサーバーへコピーします。

新AADCサーバーにて、AADCインストールモジュールを起動し、「同期設定をインポート」を選択して先ほどコピーしたJSONファイルを選択します。

以降は最低限の設定が必要となるため、表示されたAADC構成ウィザードに従って設定を進めていきます。

設定が完了したら、ステージングモードを有効状態でインストールを開始します。これで新AADCサーバーの構築は旧AADCの設定情報を引き継いだ形で構築することができます。

最後に

今回、色々な公開情報や参考情報が出回っている中、自身がAzure AD Conect(AADC)サーバーの移行に携わることがあったので整理もかねて本記事に掲載いたしました。(結構忘れている部分も多々ありました。。)
また、調べてみると、色々便利なツールが増えていたりしてどんどん移行がしやすくなってきていると感じました。

Azure AD Conect(AADC)サーバーの移行は頻度も多くないですし、そこまで難しくはないかもしれません。
ただ、オブジェクトの同期サーバーだけあって何かあった際は、オブジェクト自体に影響が発生してしまうため、ユーザー影響もかなり大きいです。(一部のサービスに障害が..では済みません。)

なので移行の際は確実に進められるよう、計画的に実行が求められるものだとこれまでの経験を得て感じました。

それではまた。