Citrix 非永続VDIでMicrosoft Entra IDハイブリッド参加が失敗する原因と対処法（0x801c005b / error_computer_signature_check_failure）

Citrix の非永続 VDI（MCS クローン端末）を GPO の「Workplace Join」タスクで Microsoft Entra ID（旧 Azure AD）へハイブリッド参加させている環境で、急に登録できなくなり 0x801c005b や error_computer_signature_check_failure が出るケースがあります。原因は「Entra 側に残る証明書」と「クローンが毎回作り直す鍵」の不一致であることが多く、ゴールドイメージ側の作り方を直すことで再発を止められます。

症状：非永続クローンが Microsoft Entra ID に登録されない

現場でよく見えるのは「以前は問題なくハイブリッド参加できていたのに、最近になってクローンだけが Entra に登録されない」というパターンです。イベントログや dsregcmd の出力で、次のような情報が揃っている場合は本記事のシナリオに該当する可能性が高いです。

観測される事象	典型的な見え方	示唆
クローンが Entra に登録されない	サインインやデバイス一覧に出てこない／「保留(Pending)」のまま	デバイス登録(Join/Renew)のどこかで失敗
クライアントエラー	`Client ErrorCode : 0x801c005b`	登録要求がサーバで弾かれている可能性
サーバエラー	`invalid_request` / `error_computer_signature_check_failure`	署名検証（鍵と証明書の整合性）で失敗
AD コンピュータオブジェクトに複数の userCertificate	`userCertificate` が増え続ける／起動のたびに新規が増えるように見える	毎回「新しい鍵ペア＋新しい証明書要求」が走っている疑い
非永続ゆえに次回起動で状況が変わる	同一端末名でも挙動が毎回ブレる	鍵（秘密鍵）の永続化に失敗している疑い

エラーの本質：サーバが「その端末の署名」を検証できない

error_computer_signature_check_failure は、Microsoft Entra のデバイス登録サービス（DRS: Device Registration Service）側が、受け取った登録要求を正当な端末からのものとして検証できなかったことを意味します。ざっくり言うと、DRS は「過去に登録した（または同期されている）その端末の公開鍵（証明書）で、今回の要求に付いている署名が正しく検証できるか」を見ています。

この検証が落ちる典型要因は次の 2 つです。

サーバ側が参照する証明書が想定と違う（AD/Entra 側に同種の証明書が複数残っており、誤った証明書で検証してしまう）
クライアント側の秘密鍵が変わってしまった（非永続クローンのたびに新しい鍵ペアを作り、前回と別物になっている）

今回のように「AD の userCertificate が複数」「クローン起動ごとに新しい証明書が増えるように見える」という条件が揃うと、サーバが持つ“過去の公開鍵”と、クローンが今持っている“新しい秘密鍵”が一致しない状態になり、署名検証が破綻します。

仕組みを理解する：Microsoft Entra ハイブリッド参加（Hybrid Azure AD Join）が行うこと

Microsoft Entra ハイブリッド参加は、端末がオンプレ AD ドメイン参加を維持しつつ、Entra 側にもデバイスとして登録される状態です。登録の過程では、端末が DRS に対して「自分はこの AD コンピュータアカウントに対応する端末である」と示せる証拠（署名）を提示します。

ユーザー環境の観測内容に基づく DRS 側処理の要点は次の通りです。

DRS が見るもの	登録要求に含まれる例	目的
対象ドメイン / デバイス識別	`targetdomainid`, `deviceid`	どのデバイスオブジェクト/端末の話か特定する
署名データ	`SignedBlob`	端末が秘密鍵を持つことを示す
端末 SID のハッシュ	`SHA256(Sid)` 相当	ドメイン内の端末と結びつける
サーバ側に保存された証明書	AD コンピュータオブジェクトの `userCertificate`	公開鍵で署名を検証する

そして DRS は、ディレクトリから対象デバイスを探し、そのデバイスに紐づく証明書（公開鍵）で署名検証を行います。ここで重要なのが、AD 側（≒同期される側）に複数の証明書が残っていると、サーバがどれを拾って検証に使うかが不安定になり得る点です。

Citrix 非永続 VDI で起きやすい落とし穴：鍵の永続化が前提

物理 PC や永続 VM では、デバイス登録で作られた鍵（秘密鍵）がディスクに残るため、次回以降の更新（DeviceRenew）でも同じ鍵で署名できます。しかし、非永続 VDI は OS ディスクがリセットされるため、デバイス登録に使う鍵をどうやって次回起動でも同じものとして扱うかが設計上の最重要ポイントになります。

Citrix MCS の Identity Disk と PvsVmAgent の役割

調査結果として挙がっている通り、Citrix MCS はプロビジョニング時に端末ごとのデバイス鍵ペアを生成し、Identity Disk に永続化します。起動時には PvsVmAgent サービスが Identity Disk 上の情報を OS 上へ復元し、Hybrid Azure AD Join の処理が同一鍵で動ける状態を作る想定です。

つまり、非永続でも「端末ごとに固定の鍵」が成立するのは、Identity Disk → 起動時復元が正しく機能しているからです。

ゴールドイメージに“元になる鍵”が無いと、クローンが毎回鍵を作り直す

今回の核心は、ゴールドイメージ側で Microsoft Software Key Storage Provider 配下に存在すべきキーセット（例：6b30069e-b381-42cc-9fae-421915a9e9f3）が存在していなかった点です。

この状態でクローンを作ると、次のような悪循環に入ります。

段階	非永続クローン側で起きること	AD / Entra 側で起きること	結果
初回起動	鍵が無いので新規鍵ペア生成 → 証明書要求	`userCertificate` が追加される	一見すると登録が進む
再起動（OS リセット）	前回の秘密鍵が失われる → また新規鍵ペア生成	古い `userCertificate` が残ったまま、さらに増える	「新しい秘密鍵」と「古い証明書（公開鍵）」が不一致
更新（DeviceRenew）	新しい秘密鍵で署名して送る	サーバは古い証明書で検証しようとする	`error_computer_signature_check_failure` で失敗

ここでポイントなのは、エラーが出ているのは「証明書が悪い」だけではなく、秘密鍵が毎回変わる（＝署名が一致し得ない）設計になっていることです。AD 側の証明書整理だけでは一時的に改善しても再発しやすく、ゴールドイメージ（と MCS の作り方）まで戻って直す必要が出ます。

最初にやるべき切り分け：3 つの観点で“ズレ”を確認する

修正に入る前に、次の 3 観点で状況を整理すると原因がブレません。

観点	見るポイント	確認例	狙い
クライアント（VDI）	Join 状態、DeviceId、エラー	`dsregcmd /status` `dsregcmd /debug /join`	Join/Renew の失敗理由をログで掴む
AD コンピュータオブジェクト	`userCertificate` の数と内容	ADUC の属性エディタ、または PowerShell で件数確認	証明書が増殖していないか、重複がないかを見る
Citrix（非永続の永続化）	Identity Disk / PvsVmAgent の挙動	PvsVmAgent サービスの起動、MCS の設定、ゴールドイメージの鍵セット有無	「同一鍵を使い回す設計」になっているか確認

特に、再起動のたびに AD の userCertificate が増えるなら、クローンが「既存の鍵を復元できていない」可能性が極めて高いです。この時点で、ゴールドイメージ側の鍵セットや MCS の前提を疑うべきです。

対処の前提：コンピュータアカウントは“固定で再利用”が基本

Microsoft 側のコメントとして強調されている通り、VDI クローンは既存のコンピュータアカウントを再利用する構成が基本です。起動のたびに新しい AD コンピュータアカウントを作成したり、毎回新規登録（新規証明書発行）に寄せると、非永続環境では整合性が崩れやすくなります。

ここがブレると、Join の失敗だけでなく、登録できたとしてもデバイスが増殖して運用が破綻します（デバイス一覧が膨らむ、条件付きアクセスの対象が散る、監査が追えない、など）。

対処：AD / Entra 側の userCertificate を整理して“誤検証”を避ける

根本対策（ゴールドイメージ修正）に入る前に、既に増殖してしまった証明書がある場合は、AD 側の userCertificate を整理しておくとトラブルシュートが進めやすくなります。

注意：証明書を削除すると一時的に登録状態が変わる可能性があります。対象端末の影響範囲（同名端末、同一カタログ、同一 OU）を必ず把握し、実施前にバックアップ（エクスポート）や検証環境での手順確認を推奨します。

PowerShell で userCertificate の件数を確認する

まずは「増殖しているか」を定量化します。

Import-Module ActiveDirectory

$comp = Get-ADComputer -Identity "VDI-001" -Properties userCertificate
($comp.userCertificate | Measure-Object).Count

件数が 2 以上で、しかも短期間に増え続ける場合は要注意です。

証明書の内容（発行者・有効期限など）をざっくり見る

userCertificate はバイナリ（証明書本体）なので、そのままだと見づらいです。以下は「何が何枚入っているか」を把握するための簡易例です。

Import-Module ActiveDirectory

$comp = Get-ADComputer -Identity "VDI-001" -Properties userCertificate

$comp.userCertificate | ForEach-Object {
    $x = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2($_)
    [PSCustomObject]@{
        Subject   = $x.Subject
        Issuer    = $x.Issuer
        NotBefore = $x.NotBefore
        NotAfter  = $x.NotAfter
        Thumbprint= $x.Thumbprint
    }
} | Sort-Object NotAfter

ここで、似たような Subject の証明書が複数あり、発行日時だけが違うように見える場合は「起動のたびに新規発行」が疑わしい状況です。

不要な証明書を削除して 1 つに寄せる

運用要件次第ですが、基本的には「同一端末（同一 deviceId）として期待しているもの」は 1 つに寄せ、不要な古いものを除去します。AD 側で属性をクリアする場合の例です（実行は慎重に）。

# すべての userCertificate をクリア（必要なら事前にエクスポートを推奨）
Set-ADComputer -Identity "VDI-001" -Clear userCertificate

「どれを残すか」判断が難しい場合は、まず検証環境で一度クリアし、正しく再登録される（＝以降増殖しない）状態を作ってから本番へ展開するのが安全です。

証明書チェーン（信頼）も合わせて確認する

証明書の不整合が疑われるときは、クライアント側で証明書チェーンが信頼できるルートまで到達しているかも確認します。環境により格納場所や名称は異なりますが、端末のローカル証明書ストアにデバイス登録関連の証明書（例：MS-Organization-Access 等）が作成されている場合は、そこからチェーンを辿って確認できます。

ただし、今回のエラーの主因は「信頼」よりも「鍵の不一致」であることが多いため、チェーン確認はあくまで並走のチェックとして扱うのが現実的です。

決定打：ゴールドイメージを“正しい鍵を持った状態”に作り直す

最終的に問題を解決した方法は、ゴールドイメージが正しいデバイス鍵セットを保持するように構成し直すことです。ポイントは「Join 状態を残す」のではなく、鍵（秘密鍵）だけを残すことです。

手順の全体像

流れを先にまとめると次の通りです。

ゴールドイメージを一度 Hybrid Azure AD Join（Entra ハイブリッド参加）させ、デバイス鍵セットを生成させる
dsregcmd /leave で Entra 登録状態を解除する（ただし鍵は残す）
そのゴールドイメージから Citrix MCS で非永続クローンを再作成し、Identity Disk 経由で鍵を復元させる

ゴールドイメージで一度ハイブリッド参加させる

ゴールドマシンをオンプレ AD に参加させ、ハイブリッド参加が有効になるように GPO（Workplace Join タスク等）を適用します。目的は「登録が完了すること」そのものではなく、デバイス鍵ペア（鍵セット）を OS 側に生成させることです。

確認例：

dsregcmd /status を実行し、Join の進行状況・エラーの有無を確認する
鍵が作成されるべき領域に、該当するキーセットが存在することを確認する（環境により確認方法は異なる）

ユーザー環境では、問題発生時点で Microsoft Software Key Storage Provider 配下にキーセット（例：6b30069e-b381-42cc-9fae-421915a9e9f3）が存在していなかったことが判明しています。ゴールドイメージを一度ハイブリッド参加させることで、このキーセットが生成される状態に持ち込みます。

参考として、ソフトウェア KSP の鍵がファイルとして保存される場合、保存先として C:\ProgramData\Microsoft\Crypto\Keys が関係することがあります（アクセス権や保護の都合で“見える/見えない”は環境差があります）。

鍵セットは残したまま Entra から離脱する（dsregcmd /leave）

次に、ゴールドマシンで登録状態だけを解除します。

dsregcmd /leave

ここが重要で、登録状態（Entra の紐づき）をクリアしても、ソフトウェアキーストア内のデバイス鍵セット自体は削除されない挙動が期待できます。結果として、ゴールドイメージには「登録状態はクリアだが、鍵は存在している」状態が残ります。

この状態をスナップショット取得し、MCS の元イメージとして固定します。

このゴールドイメージから MCS クローンを再作成する

修正したゴールドイメージを元に、Citrix MCS でクローン（非永続 VDI）を再作成します。ここで、MCS はゴールドイメージに存在する鍵セットを Identity Disk へ反映し、各クローンは起動時に PvsVmAgent により同じ鍵ペアをローカルへ復元できる状態になります。

この結果、クローンは次の状態に戻ります。

起動のたびに同じデバイス鍵で Entra に署名できる
起動のたびに新しい鍵・新しい userCertificate を量産しない
DRS が保持する証明書（公開鍵）と、クローンが持つ秘密鍵が一致し、error_computer_signature_check_failure が解消する

検証環境（UAT）でこの構成を適用したところ、再起動のたびにクローンが即座に Entra に登録されることが確認された、という報告は非常に再現性の高い着地点です。非永続の本質的な問題（鍵の揮発）に対して、Citrix の設計（Identity Disk）を正しく使った修正になっているためです。

再発防止：Citrix 非永続 VDI のハイブリッド参加を安定させる運用ポイント

ゴールドイメージ修正で直った後に再発しないよう、運用面で押さえるポイントを整理します。

アンチパターンと推奨パターン

項目	アンチパターン	推奨パターン	理由
コンピュータアカウント	起動のたびに新規作成／毎回別端末扱い	既存アカウントを固定で再利用	デバイス ID と証明書/鍵の整合性が崩れにくい
Workplace Join タスク	複数トリガーで過剰に再実行される	必要最小限のトリガーに整理	不要な再 Join/再発行が走ると証明書増殖を招く
ゴールドイメージの準備	`dsregcmd /leave` だけを実施し鍵が無い	一度 Join → 鍵生成 → Leave（鍵は残す）	非永続でも“同じ鍵”を Identity Disk に載せられる
証明書の管理	`userCertificate` が増殖しても放置	増殖の兆候を検知し、整理と原因対策をセットで実施	DRS が誤った証明書で検証するリスクを下げる

Workplace Join タスクの「二重実行」を疑う観点

GPO で配布している「Workplace Join タスク」が、起動時・ログオン時・特定イベント発火など複数条件で動くと、非永続 VDI では “毎回 Join をやり直す” 形になりやすいです。次のような観点で見直すと効果的です。

タスクが実行されるタイミング：起動直後に OS 側の準備が整う前に走っていないか
実行ユーザー（SYSTEM か）：Hybrid Join は基本的にシステムコンテキストで動くことが多い
失敗時の再試行設定：短時間に連打されると、証明書発行や更新処理が競合しやすい

タスクの実行ログ（タスクスケジューラの履歴）と dsregcmd /debug /join のタイムラインを突き合わせると、「何がトリガーで何回走っているか」が見えるようになります。

Citrix Cloud の場合に検討したい選択肢

Citrix Cloud を利用している場合、マシンカタログ作成時に Microsoft Entra Join オプション（Entra Join を Citrix 側の統合機能で扱う構成）を使う設計が有効になることがあります。環境によっては、GPO タスクでの Join を続けるよりも、Citrix の統合機能に寄せた方が「非永続での Join 成立条件」を満たしやすいケースがあります。

ただし、どの機能が使えるか・どこまでサポートされるかは、Citrix の管理形態（オンプレ管理 / Cloud 管理）、VDA バージョン、マシンカタログ方式などで変わるため、設計段階で Citrix サポートと認識合わせしておくと安全です。

TPM / vTPM を使う環境の補足（本件は TPM 未使用前提）

本件の解決策は TPM 未使用（ソフトウェア KSP 前提）の構成で成立しています。一方、TPM 保護付きキー（TpmProtection）を使う環境では、鍵の保存先が Software Key Storage Provider（ファイルベース）ではなく TPM / vTPMに寄るため、クローンでの引き継ぎ方が変わります。

項目	TPM 未使用（本記事の前提）	TPM / vTPM 使用
鍵の主な保存先	Software Key Storage Provider（ソフトウェア）	TPM / vTPM（ハード/仮想ハード）
非永続クローンでの課題	Identity Disk 等で鍵を復元できれば安定	TPM 側の鍵をどう“端末ごとに固定”するかが追加論点
現実的な対処の方向性	Join→鍵生成→Leave→MCS 再作成	vTPM を含めたテンプレート設計、または Citrix 側統合に寄せる等を検討

TPM を絡めると、ハイパーバイザや Citrix の実装・vTPM の割り当て方式によって “同じ端末として同じ鍵が維持できるか” の条件が変わります。TPM 前提の Windows 11 などでは特に、Microsoft / Citrix 双方の最新ドキュメントとサポート窓口で構成可否を確認しながら設計するのが安全です。

よくある落とし穴

ゴールドイメージで dsregcmd /leave を先にやってしまい、Join を一度も完了させていない
→ 鍵セットが存在せず、非永続側で毎回鍵が作り直されます。
AD の userCertificate を整理したのに再発する
→ クローン起動で鍵が変わる問題が残っていると、整理してもまた増殖します。
「Pending が残る」ことだけに注目してしまう
→ Pending 自体は結果であり、根本は鍵の永続化・証明書の整合性です。ログと証明書増殖の有無で原因を切り分ける方が早いです。
非永続なのに“更新（Renew）”前提の設計になっていない
→ DeviceRenew は「同じ鍵で署名できる」ことが前提です。鍵が固定できていないと更新のたびに破綻します。

まとめ：error_computer_signature_check_failure を止める最短ルート

error_computer_signature_check_failure の本質は、DRS が保持する証明書（公開鍵）と、クローンが使うデバイス鍵（秘密鍵）の不一致です。
非永続 VDI で userCertificate が増殖している場合、起動のたびに新しい鍵ペアが生成されている可能性が高く、AD 側だけの掃除では再発します。
決定打は、ゴールドイメージを一度ハイブリッド参加させて鍵セットを生成し、dsregcmd /leave で登録状態だけ解除して鍵を残すことです。
そのゴールドイメージから MCS クローンを再作成し、Identity Disk と PvsVmAgent の想定通りに「同じ鍵を復元」できる状態に戻すと、起動のたびの登録失敗を止めやすくなります。

この記事を書いた人

佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。