Azure Portalからドメインコントローラを停止するとADが壊れる

Azure Portalからドメインコントローラを停止することは非推奨である、という情報を見つけたのでどういうことなのか調べてみました。

調査結果

先に調査結果をまとめますと以下のような結論が得られました。

• ドメインコントローラが1台構成であればAzure Portalから停止しても特に問題はない
• ドメインコントローラが2台以上の冗長構成の場合、全台停止しなければ壊れない。Azure Portalから全台停止すると同期異常が発生する

情報ソース

Azure Portalからドメインコントローラを停止することは非推奨であるということはこちらに記載があります。

Azure仮想ネットワークに AD DS をデプロイする - 管理の容易性

Azure ポータルを使用してドメイン コントローラー VM をシャットダウンすることはお勧めしません。 代わりに、ゲスト オペレーティング システムをシャットダウンして再起動します。 Azure ポータルを使用してドメイン コントローラーをシャットダウンすると、VM の割り当てが解除され、ドメイン コントローラー VM を再起動すると次の効果が発生します。
　
・Active Directory リポジトリの VM-GenerationID と invocationIDがリセットされます。
・現在のActive Directory相対識別子 (RID) プールが破棄されます。
・sysvol フォルダーを非認証としてマークします。

検証してみた

Azure上に2台冗長構成のドメインコントローラを構築して実際に試してみました。
FSMOの役割は全て1号機に持たせています。

Azure Portalからドメインコントローラを1台だけ停止

停止前にVM-Generation IDとRIDプールをADSIエディタから確認します。

Azure Portalから停止します。

起動後にイベントログを確認するとVM-Generation IDが変更されたログとSYSVOL同期に関するログが出ていることが確認できました。

VM-Generation IDとRIDプールをADSIエディタから確認するとVM-Generation IDは変更され、RIDプールも破棄されて新しいプールが取得されていることが確認できました。rIDNextRIDはプールサイズ既定値の500増えています。

Azure Portalから停止すると本当にVM-Generation IDが変更され、スナップショットからリストアした時と近しい挙動になってしまうことが確認できました。1台だけ停止して起動した場合は動作中のドメインコントローラと同期処理がされて問題なく使える状態になります。

Azure Portalからドメインコントローラを2台とも停止

次にドメインコントローラを2台とも停止した場合どうなるかを確認しました。

2台ともAzure Portalから停止して、まずは1号機のみ起動してみます。
起動後、VM-Generation IDが変更されたログとSYSVOL同期に関するログが出ているのは同じです。加えてFSMOの役割を起動できない趣旨のログも出ています。FSMOは重複起動を避けるため、他のDCと初期レプリケーションをしないと起動してこないようになっています。

FSMOが起動していないということはRIDマスターが起動していないため、新規RIDプールを取得できず、rIDNextRIDの値が0になっています。

新規ユーザを試しに作成してみると、やはりRIDプールを取得できていないためエラーとなりました。

それでは2号機を起動します。
2号機を起動すると初期レプリケーションがおこなわれ、FSMOの役割が起動して新規RIDプールが払い出されました。新規ユーザを作成できるようになり、一見するとちゃんと起動できているように見えますが、以下のような事象が発生しました。

• 1号機で作成したユーザは2号機に同期されるが、2号機で作成したユーザが1号機に同期されない
• SYSVOLが同期されておらず、GPOを追加しても2号機にコピーされない。意図的に2号機へGPOエディタを接続し、2号機でGPOを新規追加したら1号機には反映されない

Azure Portalから全台停止するとお互いがお見合い状態になり、異常な状態になってしまうことが確認できました。この状態から復旧するにはDFSRのAuthoritative Restoreが必要です。

1号機上でdsa.mscを起動し、[表示] メニューの [コンテナーとしてのユーザー、連絡先、グループ、コンピューター] および [拡張機能] をオンにします。

左ペインの[Domain Controllers] – [1号機] - [DFSR-LocalSettings] - [Domain System Volume] の順に展開します。続いて右ペインの [SYSVOL Subscriptions] を右クリックし、[プロパティ] をクリックします。

[属性エディター] タブの [属性] 列が [msDFSR-Options] となっている行をダブルクリックします。[値] に 1 と入力し、[OK] をクリックし、もう1回OKをクリックします。

管理者権限でコマンドプロンプトを起動し、下記コマンドでDFS Replicationサービスを再起動します。

net stop dfsr && net start dfsr

DFSRのAuthoritative RestoreをすることでSYSVOLの同期異常、ユーザオブジェクトの同期異常双方とも解決しました。

まとめ

Azure Portalからドメインコントローラを停止することは非推奨であることがよくわかりました。特に冗長構成を組んでいて全台停止させると同期異常が発生するため、ADが壊れるといっても過言ではないと思います。

なかなか危険な内容ですが、あまり周知の事実ではないという印象です。本番運用ではそもそも全台停止することが稀ですし、検証環境だとコスト抑制のために1台しか用意しないことが多いからでしょうか。とはいえ、本番運用環境でもメンテナンスのために全台停止するケースもゼロではないかと思うので、このナレッジは留意しておいた方がよいでしょう。

この問題が顕在化する可能性が高いのは冗長構成をちゃんと組んでいる検証環境でしょうか。コスト抑制のためにAzurePortalから完全停止していることは多いと思います。コストがかかりますが最低1台は起動したままにするのが一番手っ取り早い対処策となりそうです。

補足：RIDプール払い出しに対する考慮

Azure Portalから停止して起動するとRIDプールが破棄、新規払い出しされます。これの影響についてですが、RIDプールの上限は約10億のため、基本的には無視できるものとなります。しかし、以下のような環境だと考慮が必要になると考えらえます。

• 停止対象のドメインコントローラの台数が多い、停止頻度が高い
• RIDプール払い出し時の数を500から意図的に増やしている
• 過去経緯でRIDプールの残りに余裕がない

RIDプールが完全枯渇するとユーザなどの新規オブジェクト作成が不能となり、ドメイン移行やフォレスト復旧をしないといけないという影響度が大きすぎる対応が必要となってしまうため、気を付けておく必要があります。

参考：RID 発行の管理