ADMT 3.0でユーザー移行時にSIDヒストリ生成が失敗する

1日の教育コース「Windows環境マイグレーション実践」を実施していて気付いたことがあります。

ADMTで、アカウントを移行(複製)するとき、最後に移行元の管理者アカウントを聞いてきます。既に管理者権限があるのに、なんで聞いてくるのか分かりませんが、確認のためなのでしょう。

Windows Server 2003上でADMT 3.0を実行した場合、管理者パスワードを間違えても、その時はエラーにならず、以下のような現象が出ます。

• 移行時にエラーが出る
• ユーザーアカウントの複製は完了
• ただしSIDヒストリが生成されない(エラーメッセージはこれ)

ADMTのデータベースには「移行済み」マークが付くので、再移行はできませんし、SIDヒストリの更新もできないという状態になってしまいます。

ユーザーの権利やグループのメンバーシップ情報などは、更新もできるのですが、SIDヒストリは更新の対象になっていません。

しかし、ADMT 3.2 QFE をWindows Server 2012 R2上で実行した場合は、管理者アカウント情報を間違えた時点で適切なエラーが表示され、先には進めませんでした。

よかった。

なお、移行に失敗してしまった場合、以下の2つ解決方法がありそうですが、どちらも問題があります。

• 移行先のユーザーを削除し、別のマシンにADMTをインストールして再移行
  移行自体は成功しますが、ADMTのデータベーステーブルにある「移行先ユーザーの新SID」が適切な値にならず、セキュリティ変換などに支障をきたします。
• 移行先のユーザーを削除し、ADMTのデータベースを直接操作して、移行しなかったことにする
  これができればいいのですが、ADMTのデータベーススキーマが公開されていません。

ところで、先日、デモ中に、クライアントPCの移行に失敗したのですが、単にNT4互換の暗号化アルゴリズム指定が抜けていたためでした。テキストの手順通りに実行すれば問題なく移行できます。

▲マイグレーションと言えば、アフリカ大陸で毎年見られる「ヌーの大移動」
(写真は移動の時期ではありません)

Hyper-VのDHCPガードの意味

Windows Server 2012以降のHyper-Vには「DHCPガード」という機能があります。説明には「承認されていない仮想マシンからのDHCPサーバーメッセージを削除します」とあります。

実際に、このチェックボックスをオンにすると、DHCPパケットが仮想マシン外に飛びません(DHCPサーバーとして実用的な動作はしません)。

▲DHCPサーバーガードの構成は仮想マシン単位で行う

Windows ServerにはDHCPサーバーをActive Directoryで承認する機能があるため、この「承認」も何らかの操作を指すと思っている人が多いようです。

実は、ここでいう「承認」は「管理者が正しいと判断する」という意味です。つまり、管理者が、正しいDHCPサーバーを立てたと思ったらチェックを外すという手順を意味します。

存在しない機能を探すのは難しいのですが、一応、それらしいものがありました。英語版TechNet Forumの「How to configure DHCP guard in Hyper-V 2012?」では、モデレータのBrian Ehlertさんがこう答えています。

Unauthorized and Authorized is a procedural / process phrase. It is not a technical phrase or any setting that can be applied.  It is the business decision to call machine authorized or not.

意訳

「承認されていない/承認されている」は手続きの順序を意味しており、技術的な方法や設定手順を意味するものではありません。「承認されている/いない」は、仮想マシンを構成するときのビジネス的な判断(DHCPサーバーにするかしないかを管理者が決めること)を意味します。

Hyper-V管理者と、仮想マシン管理者が同一の場合は意味を持ちませんが、以下のような運用を想定しています。

1. Hyper-V管理者が仮想マシンVMを作成
2. VM管理者はDHCPサーバーでないことをHyper-V管理者に通知
3. Hyper-V管理者が仮想マシンVMのDHCPガードを有効化
4. 誤ってVMにDHCPサーバーをインストールしてもDHCPパケットは廃棄される

物理マシンの認証を仮想マシンのドメインコントローラーで行うには

マイクロソフト製品の多くは、Active Directoryドメインサービスを必要とします。しかし、ドメインコントローラーはIDとセキュリティ管理の要なので、構築や複製が何かと面倒です。

特にVDI環境を構築するときは、物理マシンをドメインのメンバーにする必要があり、通常は物理マシンを2台必要とします。

何とか1台でできないものでしょうか。

ksakakiさんのブログ「More Than One Way」の記事「世界のブログから - 「ドメイン コントローラーどうしよう」に、ドメインコントローラーを仮想マシンとして構成し、その仮想マシンホストをメンバーとする手順が掲載されています。

詳細はksakakiさんのブログを読んでいただくとして、要点だけを整理してみましょう。

1. ドメインコントローラー仮想マシン(DC)は自動起動
   既定値は[サービスが停止したときに実行されていた場合は自動起動する]
2. ドメインコントローラー仮想マシン(DC)は最初に起動
   既定値は0
3. ドメインコントローラー仮想マシン(DC)は自動シャットダウン
   既定値は[保存]
4. 万一に備えて物理マシンのローカル管理者アカウントを正しく構成
   ドメインコントローラーが動かないと、ドメインのユーザーでログオンできません。セキュリティ対策としてローカル管理者Administratorの名前を変えたり、無効化する場合もありますが、Hyper-Vホストには必ずローカル管理者としてログオンできるようにしておいてください。

上記1から3は、以下のPowerShellコマンドレットで構成できます(`は継続行の印)。

Set-VM -VMName 仮想マシン名  `
    -AutomaticStartAction Start   `
    -AutomaticStartDelay 0          `
    -AutomaticStopAction ShutDown

しかし、これだけでは起動時のタイミングによってはエラーが出ます。追加の設定が「世界のブログから - Hyper-Vとドメイン コントローラーに関してもう一つ」として公開されています。

1. 確実に認証させるため、資格情報のキャッシュを停止
   物理マシンで以下のようにレジストリを変更します(PowerShellの場合)。
   Set-ItemProperty `
       'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon' '
        -Name cachedlogonscount –Value 0
   (`は継続行の印)
2. 起動時の待ち時間を回避するため、サービス起動順序を構成
   ドメインコントローラー(つまり仮想マシン)で以下のコマンドを実行
   sc config netlogon depend= LanmanWorkstation/LanmanServer/DNS
   (現在の依存関係は sc qc コマンドで表示できます)

以上の構成をしたら、あとは物理マシンの優先DNSに仮想マシンのDNSサーバーアドレスを指定し、通常どおりドメインに参加してください。

だいたいこれで大丈夫なのですが、VDIを構成する場合は以下のようなトラブルがありました。

• 仮想化ホストの構成時に警告が出る
  仮想化ホストの構成時に、ローカルグループの設定に失敗することがあります。管理ツールで見ると、ローカルグループは正しく構成されているようです。実際、そのままでも動作しましたが仮想化、念のためホストをVDIから削除して、再構成した方が無難です。
• 複数のNICがあると、クライアントOSの展開に失敗する
  仮想化ホスト(物理マシン)に、NICが2枚構成されていると(たとえば外部ネットワークと内部ネットワーク)、クライアントOSの展開に失敗しました。同じ構成で成功したこともあるので、詳細は分かりません。

前者はVDIの再構成で、後者は内部ネットワークをやめ、VLANで物理ネットワークを分離することで解決しました。ただ、そもそもなぜ複数NICで問題が発生したかは分かりませんので、もう少し調べてみます。