Hyper-Vのライブマイグレーションで「認証はKerberosで」と決めた瞬間、Active Directory側の制約付き委任という宿題が発生します。しかもWindows Server 2025では、これがもはや任意ではなく既定路線になりました。本稿ではSPNと二重ホップの勘所を、現場でハマる順に整理します。
ライブマイグレーションの構築で、多くのエンジニアが最初に軽く見て、あとで長時間ハマるのが認証周りです。メモリの転送やネットワーク設計は目に見えるぶん丁寧に詰めるのに、認証プロトコルの選択は「とりあえずデフォルトで」となりがちです。ところが、この一択がActive Directoryの設計にまで波及します。本稿では、EMWが実際にHyper-Vライブマイグレーション移行およびその専用ADの構築を手掛けた経験から、Kerberos制約付き委任の勘所を、Microsoft Learnの一次情報に沿って掘り下げます。
01なぜCredSSPでなくKerberosなのか
非クラスター構成(フェールオーバークラスタリングを使わない、いわゆる Shared Nothing ライブマイグレーション)では、認証プロトコルとしてCredSSPとKerberosのどちらかを選びます。両者はトレードオフの関係にあり、Microsoft Learnはこう整理しています。CredSSPは制約付き委任のセットアップが不要な代わりに、移行元サーバーへのサインインが必須です。Kerberosはサインイン不要な代わりに、制約付き委任のセットアップが必須です。
CredSSPの「サインイン必須」が現場で厄介なのは、その条件が直感に反する場面があるからです。TestServer01にサインインしてVMをTestServer02へ移動し、次にそのVMをTestServer01へ戻したくなったとします。このとき、戻す前にTestServer02へサインインしておかないと認証は失敗します。運用スクリプトやリモートの管理端末からまとめて操作したい現場では、この「向きごとにサインインが要る」という性質が自動化の足かせになります。
02Windows Server 2025では、もはや選択の余地が狭い
ここが2025年時点で最も重要な変化です。Windows Server 2025からは、ドメインコントローラー以外のドメイン参加サーバーでCredential Guardが既定で有効になります。この結果、Windows Server 2025へアップグレードした後は、CredSSPベースのライブマイグレーションが使えなくなります。Windows Server 2022以前ではCredSSPが既定だったので、アップグレードを機に「今まで動いていた移行が突然通らなくなる」という事故が起こり得ます。
つまりWindows Server 2025世代の基盤では、Kerberos制約付き委任は「セキュリティ上望ましい選択肢」ではなく「実質的に必須の前提」になったと捉えるのが実務的です。新規構築でも移行案件でも、AD側の委任設計を最初から計画に織り込んでおくべきです。バージョン依存の挙動なので、導入時は必ずMicrosoft Learnで最新の既定値を確認してください。
03二重ホップ問題 — なぜ委任が必要になるのか
そもそもなぜ「委任(delegation)」という概念が出てくるのか。ここを腹落ちさせておくと、後のトラブルシュートが一気に楽になります。
ライブマイグレーションでは、あなたが管理端末から移行元ホスト(HostA)に接続し、HostAがあなたの資格情報を使って移行先ホスト(HostB)上でVMを作成したり、SMB経由でストレージにアクセスしたりします。あなた → HostA → HostB と、資格情報が二段階で受け渡される。これがいわゆる二重ホップ(double hop)です。
Kerberosは既定では、この「受け取ったチケットをさらに別のサービスへ横流しする」動きを許しません。HostAは自分に届いたチケットで自分自身へのアクセスは処理できますが、それを使ってHostBへ成りすまし接続することはできない。だからこそ、AD側で「HostAは、あなたの資格情報を使ってHostB上の特定サービスに対してだけ委任してよい」と明示的に許可する必要があります。この「特定サービスに対してだけ」というスコープの絞り込みが、制約付き(constrained)委任という名前の由来です。
04必要なSPN — cifs と Microsoft Virtual System Migration Service
制約付き委任で「どのサービスに対して委任してよいか」を指定するとき、その粒度はサービスプリンシパル名(SPN)単位です。ライブマイグレーションで登録・指定が必要なSPNは2つです。
cifs— ストレージ(SMB / Server Message Block)へのアクセスに使います。VMのストレージも一緒に移動する場合や、ストレージだけを移動する場合に必要です。ホストがHyper-VのストレージとしてSMBを使う構成なら、たいてい既に選択済みになっています。Microsoft Virtual System Migration Service— VMそのものの移行に使います。これは仮想マシン管理サービス(VMMS)の移行機能に対応するSPNです。
この2つは役割が違います。Microsoft Virtual System Migration Serviceだけ設定してcifsを忘れると、VMの状態は動いてもストレージ移動で詰まる、といった中途半端な失敗になりがちです。両方を必ずセットで考えてください。
SPNの登録・確認はsetspnで行います。欠けているSPNの登録はMicrosoft Learn記載の形で次のように行います。
- 登録:
setspn -s "Microsoft Virtual System Migration Service/<FQDN>" <ComputerName> - 確認(ホストに紐づくSPN一覧):
setspn -L <HostName>
setspn -Xでドメイン内のSPN重複を洗い出すのが遠回りに見えて最短です。ホスト名を改名・再構築した基盤で特に踏みやすい罠です。05委任は「双方向」に設定する — 片方向で必ずハマる
ここが設定漏れの最頻出ポイントです。制約付き委任は、関わる全ホストのコンピューターアカウントに対して、相互に設定する必要があります。Microsoft Learnの手順も、移行元サーバーのアカウントで委任先として移行先を指定した後、明確に「移行先サーバーのアカウントについても同じ作業を繰り返し、今度は移行元サーバーの名前を指定する」と指示しています。
具体的な設定手順は次のとおりです(Active Directory ユーザーとコンピュータースナップインの場合)。
- 対象ホストのコンピューターアカウントのプロパティを開き、
委任タブを選ぶ。 - 「指定されたサービスへの委任でのみこのコンピューターを信頼する」を選び、「任意の認証プロトコルを使用する」を選択。
- 「追加」から相手ホスト(移行先)のコンピューターアカウントを指定し、
cifsとMicrosoft Virtual System Migration Serviceを追加。 - 相手ホスト側でも同じ操作を行い、今度は移行元を委任先として指定する。
3台以上のホストを相互にライブマイグレーションさせるなら、原則すべての組み合わせで双方向に設定する必要があります。ホスト台数が増えると設定漏れの確率も上がるので、PowerShellやスクリプトで機械的に流し込む運用に寄せるのが安全です。委任設定の考え方は、クラスターやAD設計とも密接に絡みます。この領域を掘り下げたい方はライブマイグレーション用ADの設計やShared Nothingライブマイグレーションも併せてご覧ください。
06設定漏れで起きる典型エラー
委任やSPNが正しく設定できていないと、ライブマイグレーションは特徴的なエラーコードで失敗します。現場での見分け方を整理します。
0x8009030D(SEC_E_UNKNOWN_CREDENTIALS / 資格情報が認識されない) — 「移行元ホストがKerberosを使う設定になっていて、かつADで制約付き委任が有効になっているか確認せよ」というメッセージが付きます。まさに委任設定漏れの典型です。0x8009030E(SEC_E_NO_CREDENTIALS / 資格情報がない) — CredSSPで「戻す前に移行先へサインインしていない」ときや、Kerberos委任が効いていないときに出ます。0x80090322(SEC_E_WRONG_PRINCIPAL / ターゲットプリンシパル名が正しくない) — SPNの不整合で出ます。ただしMicrosoft Learnでは、クロスクラスターでライブマイグレーションのネットワーク順序が意図せずプライベートネットワークを選んだケースでも報告されており、SPNだけでなくネットワーク経路も疑う値です。0x80070005(General access denied) — 委任 / Kerberos / SPNの設定不備で広く出るアクセス拒否です。
これらのコードを見たら、まず認証系(委任・SPN・Kerberos設定)を疑う、と紐づけて覚えておくと初動が速くなります。
07委任のトラブルシュート — チケットのタイムラグを味方につける
委任やSPNの設定を「正しく直したはずなのに、まだ失敗する」。これは高確率でKerberosチケットのキャッシュが原因です。設定変更が効くのは、変更がドメインコントローラーに複製され、かつDCが新しいチケットを発行してからです。
対処の方向性は明快です。ただしAD既定ではKerberosのTGT・サービスチケットとも有効期間は最大600分(10時間)なので、キャッシュ済みチケットが自然に切れるのを待つのは現実的ではありません。反映を早めたいなら、次のコマンドで古いチケットを明示的に破棄します(再ログオンやgpupdateも有効です)。
- チケット破棄:
KLIST PURGE -li 0x3e7(0x3e7はLocal Systemのログオンセッション)
切り分けの順番としては、まずsetspn -LでSPNの登録を確認し、ADの委任タブで対象サービスが両ホストに双方向で入っているかを目視し、それでも直らなければチケットをパージして再試行、という流れが実務的です。加えて、認証が通っても別要因で失敗している可能性を切り分けるため、Compare-VM -Name <vm_name> -DestinationHost <host_name>で互換性の観点も一度チェックしておくと、犯人を認証系に絞り込めます。
KLIST PURGEでチケットを破棄する(または再ログオン/gpupdate)、を鉄則にしてください。キャッシュ済みチケットは既定で最長約10時間有効なので、切れるのを待つのは非効率です。触っていないのに直る/直らないが変わるのは、たいていチケットの寿命が原因で、設定そのものは合っています。08この知識はAWS移行にも効く
制約付き委任・SPN・二重ホップの理解は、Hyper-V基盤だけの話に留まりません。Windows認証の委任やSPNの考え方は、オンプレADをそのまま持ち込む/managed ADへ寄せるといったAWS移行の設計判断でもそのまま効いてきます。オンプレのWindows基盤を深く理解していればこそ、クラウド移行時に「どの認証を残し、どこをマネージドに委ねるか」を的確に線引きできます。AD前提のワークロードをAWSへ持っていく際の勘所はオンプレADからManaged Microsoft ADへで整理しています。
—まとめ
Hyper-Vライブマイグレーションの認証は、Windows Server 2025世代ではKerberos制約付き委任が実質的な前提です。押さえるべき勘所は、(1) 資格情報が二段階で渡る二重ホップだから委任が要る、(2) SPNはcifsとMicrosoft Virtual System Migration Serviceの2つをセットで、(3) 委任は全ホストに双方向で設定する、(4) 0x8009030D等のコードを見たら認証系を疑う、(5) 直したのに失敗するならチケットをKLIST PURGEする、の5点です。値やバージョン依存の挙動は必ずMicrosoft Learnで最新を確認してください。
EMWは、S2D基盤やHyper-Vライブマイグレーション、その専用ADの構築まで実際に手を動かしてきました。設計から移行、そしてその先のAWS移行まで、現場の勘所を押さえたご支援が可能です。導入事例もご覧ください。