AD CS の自動登録が進まないとき、真っ先に疑うべきなのは CA の故障よりも、GPO、証明書テンプレートの公開、テンプレート権限、承認待ち設定、CA との通信です。特に「そもそも証明書が端末に来ない」「CA の Pending Requests に溜まる」「既存証明書はあるのに更新だけ止まる」で見る場所が変わります。AD CS の自動登録は Enterprise CA、証明書テンプレート、Group Policy を前提に動くため、この前提を順に崩していくのが最短です。 (Microsoft Learn)
この記事では、AD CS の自動登録が進まない原因を、GPO、テンプレート、権限、更新、RPC/DCOM の順で整理し、現場でそのまま使える復旧手順までまとめます。
まずは症状を3つに分ける
設定変更に入る前に、症状を次の3つに分けてください。
- 端末に証明書が出てこない
GPO 未適用、テンプレート未公開、Read/Enroll/Autoenroll 権限不足を先に疑います。 (Microsoft Learn) - CA の Pending Requests に要求が残る
要求は飛んでいますが、発行条件のせいで止まっています。特に承認待ち設定が典型です。 (Microsoft Learn) - 初回発行はできるのに更新だけ止まる
自動登録 GPO の更新系チェックボックス、テンプレート差し替え、旧証明書の扱いを確認します。 (Microsoft Learn)
この切り分けを先にやるだけで、無関係な設定を触って遠回りするのをかなり防げます。
自動登録の前提が揃っているかを確認する
Enterprise CA になっているか
証明書テンプレートは AD DS に保存され、テンプレートベースの発行は Enterprise CA が前提です。スタンドアロン CA を使っている場合、AD CS の一般的な自動登録手順どおりには進みません。さらに、テンプレートを作っただけでは足りず、CA 側でそのテンプレートを発行対象として公開する必要があります。 (Microsoft Learn)
テンプレートの世代が古すぎないか
Microsoft の整理では、version 2 テンプレートが autoenrollment をサポートし、version 1 は制限があります。ユーザー証明書で既定テンプレートをそのまま使っていると詰まりやすいため、実務では既存テンプレートを複製して v2/v3 ベースで作るほうが安全です。 (Microsoft Learn)
ユーザー証明書か、コンピューター証明書か
ここは本当に見落とされます。自動登録 GPO は Computer Configuration と User Configuration で別管理です。コンピューター証明書を配りたいのに User 側だけ設定している、あるいはその逆だと、いつまで待っても配布されません。 (Microsoft Learn)
原因別に見る、起きやすい詰まり方と対処
GPO の自動登録設定が足りない
AD CS の自動登録でまず確認すべき GPO は、Certificate Services Client - Auto-Enrollment です。Microsoft の手順では、次の2項目を有効にしています。 (Microsoft Learn)
Renew expired certificates, update pending certificates, and remove revoked certificates(Microsoft Learn)Update certificates that use certificate templates(Microsoft Learn)
特に後者は、テンプレート変更後の再評価に関わるため、初回は取れるのに更新や差し替えが進まないときに効いてきます。設定変更後は次回の Group Policy 更新で反映されるので、すぐ結果が出ないこと自体は珍しくありません。 (Microsoft Learn)
テンプレートを作っただけで、CA に公開していない
これは AD CS でかなり多いミスです。テンプレートを複製して AD DS 上に作成しても、それだけではクライアントは証明書を取得できません。Certification Authority コンソールで Certificate Template to Issue に追加して、CA がそのテンプレートを発行できる状態にする必要があります。 (Microsoft Learn)
また、テンプレートは AD DS に格納されてドメイン コントローラーへ自動レプリケートされます。仕組み上、特定サイトだけ見え方が違う、一部端末だけ新テンプレートを認識しないなら、レプリケーション遅延や不整合も候補です。 (Microsoft Learn)
Read / Enroll / Autoenroll 権限が不足している
自動登録では、対象ユーザーまたは対象コンピューターを含むグループに Read、Enroll、Autoenroll が必要です。ユーザー証明書の Microsoft 手順でも、テンプレートの Security タブで Enroll と Read、Autoenroll を許可するよう明記されています。 (Microsoft Learn)
実務で多いのは、次のような権限ミスです。
- 旧テンプレートには権限があるが、新しく複製したテンプレートにはない (Microsoft Learn)
Domain Usersや独自グループを差し替えたあと、Autoenroll を入れ忘れた (Microsoft Learn)- supersede した新テンプレート側の権限だけ抜けている (Microsoft Learn)
Pending Requests に溜まる
CA 側の Pending Requests に残っているなら、原因はかなり絞れます。Microsoft の仕様例では、テンプレートに CT_FLAG_PEND_ALL_REQUESTS が設定されていると、CA は要求をデータベースに記録し、要求状態を pending として返します。その後、管理者が承認して初めて発行されます。 (Microsoft Learn)
つまり、自動登録向けテンプレートなのに Pending に溜まるなら、まず Issuance Requirements の承認待ち設定 を疑うべきです。セキュリティ要件上どうしても承認が必要なテンプレートを除けば、ここが有効だと「自動登録が進まない」ように見えて当然です。 (Microsoft Learn)
CA との通信や RPC/DCOM で失敗している
イベントに 0x800706ba が出るなら、テンプレート設定だけ見ても解決しません。Microsoft の KB では、証明書登録失敗の原因として次が整理されています。 (Microsoft Learn)
Access this computer from the network/Deny access to this computer from the networkの GPO (Microsoft Learn)- CA サーバーの
UsersグループからNT AUTHORITY\Authenticated Usersが欠けていること (Microsoft Learn) Certificate Service DCOM Accessローカルグループの不備 (Microsoft Learn)- COM Security の Access / Launch and Activation 権限の欠落 (Microsoft Learn)
EnableDCOMがYになっていないこと (Microsoft Learn)
CA 側では System ログの DistributedCOM 10027、Application ログの event 82 が手掛かりになります。テンプレートを直す前に、CA に到達できるか、DCOM 権限が崩れていないかを見てください。 (Microsoft Learn)
テンプレート設計が自動登録向きではない
標準的なドメイン参加端末の自動登録では、Subject / SAN を AD 情報から組み立てる設計のほうが安定します。Microsoft のユーザー証明書手順では Build from this Active Directory information、NPS/802.1X 向けのサーバー・クライアント証明書手順でも同じく Build from this Active Directory information を使い、ユーザーなら UPN、コンピューターなら DNS 名を SAN に入れる構成を案内しています。 (Microsoft Learn)
一方で、Supply in the request は無条件に悪いわけではありません。Microsoft も、gMSA を使う登録エージェント証明書や CEP/CES の key-based renewal のような特殊シナリオでは Supply in the request を明示しています。つまり、通常の自動登録テンプレートに手入力前提の Subject 設計を持ち込むなら、そのテンプレートの更新方式と本当に合っているかを先に確認すべきです。 (Microsoft Learn)
変更や更新のあとに進まないときの注意点
「前は動いていたのに、テンプレート更新後から進まない」というケースでは、設定の差分だけでなく古い証明書や旧テンプレートの残り方も見ます。Microsoft のトラブルシュート文書では、supersede した新テンプレートで新証明書が配布されても、現行 Windows では XP/Windows Server 2003 時代と同じ挙動で古い公開情報が消えるわけではありません。 (Microsoft Learn)
そのため、更新系トラブルでは「新テンプレートが配布されたか」と「旧証明書が残っているか」を分けて確認するのが大切です。新規発行は成功しているのに、運用側が旧証明書を見続けているだけということもあります。確認は certlm.msc や certutil -q -v -store my が速いです。 (Microsoft Learn)
迷ったら、この順で復旧する
1台のテスト端末で強制再評価する
まず 1 台だけを対象にして、GPO と自動登録を強制再評価します。
gpupdate /force
certutil -pulsecertreq -autoenroll -q で自動登録を強制する方法もあります。設定変更直後に広範囲へ展開する前に、1 台で再現と解消を確認するほうが安全です。 (Microsoft Learn)
端末側で「証明書がない」のか「別の証明書がある」のかを見る
ローカル コンピューター証明書は certlm.msc、詳細確認は certutil -q -v -store my が速いです。イベント ビューアーでは Application and Services > Microsoft > Windows > CertificateServices-Lifecycles-System に自動登録イベントが出るので、どのテンプレートで発行されたかまで追えます。 (Microsoft Learn)
CA 側で公開テンプレートと Pending Requests を見る
クライアントに何も来ていないときは、CA 側で テンプレート公開の有無 を確認します。Pending Requests に要求があるなら承認待ち、そもそも要求がないなら GPO・権限・通信側を優先して見ます。ここで原因の半分以上は切り分けできます。 (Microsoft Learn)
0x800706ba なら CA サーバーの権限と DCOM を見る
RPC エラー系は、クライアントで何度 pulse しても直りません。CA サーバー側の GPO、Certificate Service DCOM Access グループ、COM Security、EnableDCOM を順に確認してください。 (Microsoft Learn)
コマンドで素早く切り分ける
gpresult /h report.html
適用されている GPO と Winning GPO を確認したいときに使います。自動登録 GPO が本当に当たっているかを見るのに有効です。 (Microsoft Learn)certutil -ping -config "CAサーバー\CA名"
AD CS の要求インターフェイスへの接続を試します。CA への到達性確認の第一歩です。 (Microsoft Learn)certutil -CATemplates -config "CAサーバー\CA名"
その CA が発行できるテンプレート一覧を確認します。テンプレート未公開の確認に向きます。 (Microsoft Learn)certutil -TemplateCAs <TemplateName>
指定テンプレートをどの CA が発行するかを確認できます。複数 CA がある環境で便利です。 (Microsoft Learn)certutil -dsTemplate <TemplateName>
AD DS 上のテンプレート属性を確認します。レプリケーションやテンプレート差分を追うときに使えます。 (Microsoft Learn)certutil -q -v -store my
端末に入っている証明書の詳細確認に使います。テンプレート名、拇印、EKU の確認がしやすいです。 (Microsoft Learn)
先に潰すと効率がいい失敗ポイント
- ユーザー証明書なのに Computer Configuration 側しか見ていない (Microsoft Learn)
- テンプレートは作ったが CA に公開していない (Microsoft Learn)
- ACL に Read / Enroll はあるが Autoenroll がない (Microsoft Learn)
- 新テンプレートへ切り替えたのに旧テンプレート側の想定で見ている (Microsoft Learn)
- Pending Requests を見ずに「要求が飛んでいない」と思い込んでいる (Microsoft Learn)
- 0x800706ba をテンプレート問題だと誤認している (Microsoft Learn)
まとめ
AD CS の自動登録が進まないときは、GPO → テンプレート公開 → Read/Enroll/Autoenroll 権限 → Pending Requests → RPC/DCOM の順で見るのが最短です。特に、ユーザー証明書とコンピューター証明書で GPO の場所が違う点、テンプレートを作っただけでは CA は発行しない点、承認待ち設定があると Pending で止まる点は、最初に押さえておくべきポイントです。 (Microsoft Learn)
次にやるべきことはシンプルです。1 台のテスト端末で gpupdate /force と certutil -pulse を実行し、証明書ストア・イベントログ・CA の Pending Requests を確認することです。そこで「要求が出ていない」「要求は出ているが保留」「通信で失敗」のどれかに分けられれば、復旧はかなり速くなります。 (Microsoft Learn)
コメント