Microsoft Intuneで証明書配布を使っている場合、今回まず確認すべき点はCertificate Connector for Microsoft Intuneを導入するWindows Serverの前提条件、ネットワーク到達性、証明書テンプレート権限、サービスアカウント権限です。特に2026年5月時点の更新では、証明書コネクタのインストールドライブに対してBitLockerまたは同等のディスク暗号化を有効化する推奨が明確化されています。証明書配布はWi-Fi、VPN、端末認証、社内アプリ認証に直結するため、前提条件の見落としは「証明書が発行されない」「一部端末だけ失敗する」「更新後にコネクタが動かない」といった運用障害につながります。(GitHub)
この記事では、Microsoft Intuneの「Certificate Connector for Microsoft Intune の前提条件」について、管理者が確認すべき変更点、影響範囲、展開・移行時の注意点を実務目線で整理します。新規導入だけでなく、既存環境の棚卸しにも使えるチェック項目として読める内容です。
Microsoft IntuneのCertificate Connectorとは
Certificate Connector for Microsoft Intuneは、Microsoft Intuneとオンプレミスの証明機関、証明書テンプレート、NDESなどを連携させるためのWindows Server上のコネクタです。
Intuneだけで完結するクラウド機能ではなく、社内PKIやActive Directory Certificate Servicesと組み合わせて使うため、サーバー、ネットワーク、証明書テンプレート、サービスアカウントの権限設計が重要になります。
主に次のような証明書配布シナリオで利用されます。
| 利用シナリオ | 主な用途 | 管理者が見るべきポイント |
|---|---|---|
| PKCS | Intune経由で証明書を配布する | 証明書テンプレートへの登録権限、CAへの接続性 |
| PKCSインポート証明書 | PFX証明書をIntuneへ取り込んで配布する | KSPへのアクセス権、キー管理 |
| SCEP | 端末が公開鍵を含む証明書要求を送信する | NDES、IIS、証明書テンプレート、自動登録権限 |
| 証明書失効 | 不要・侵害・退役端末の証明書を失効する | CAに対する失効権限 |
Microsoft Learnの公式ドキュメントでも、前提条件は「どの機能をコネクタインスタンスでサポートするか」によって変わると説明されています。つまり、単にコネクタをインストールできるかではなく、PKCS、SCEP、失効、PFXインポートのどれを使うかで確認項目を分ける必要があります。(Microsoft Learn)
2026年5月更新で管理者が押さえるべき変更点
2026年5月時点で注目すべき実質的な変更は、Certificate ConnectorをインストールするドライブでBitLockerまたは同等のディスク暗号化を有効化する推奨が明記・整理されたことです。GitHub上のMicrosoftDocs履歴では、BitLocker推奨の追加と文言整理に関するコミットが確認できます。(GitHub)
これは「BitLockerを有効にしないと必ずインストールできない」という意味ではありません。ただし、証明書コネクタはPKI要求、証明書発行、PFXインポート、失効処理など、認証基盤に関わる重要な処理を担います。そのため、コネクタを置くサーバーのディスク暗号化は、今後の監査・セキュリティレビューで確認される項目になりやすいと考えるべきです。
変更点の影響範囲
| 影響を受ける担当者 | 確認すべき内容 | 実務での対応 |
|---|---|---|
| Intune管理者 | コネクタサーバーの前提条件、構成ウィザード実行権限 | Intune Administratorロールとライセンスを確認する |
| PKI管理者 | CA、証明書テンプレート、失効権限 | PKCS/SCEP別にテンプレート権限を棚卸しする |
| サーバー管理者 | Windows Server、.NET、TLS、Edge、BitLocker | サーバー構成を標準化し、古いOSの移行要否を判断する |
| ネットワーク管理者 | Intune関連エンドポイント、Azure更新サービスへの通信 | プロキシ、FW、TLS検査の影響を確認する |
| セキュリティ担当者 | ディスク暗号化、サービスアカウント権限、特権管理 | BitLocker、最小権限、監査ログを確認する |
| アプリ・認証基盤担当者 | 証明書ベース認証の継続性 | Wi-Fi、VPN、社内アプリ認証への影響を洗い出す |
特に注意したいのは、証明書コネクタの障害がIntune管理画面だけの問題にとどまらない点です。端末がWi-Fiへ接続できない、VPN認証に失敗する、証明書ベースの条件付きアクセスや社内サービス認証でトラブルが起きるなど、ユーザー影響が広がる可能性があります。
一般的な前提条件で確認すべきポイント
Certificate Connector for Microsoft Intuneをインストールするサーバーには、複数のソフトウェア要件とネットワーク要件があります。公式ドキュメントでは、Windows Server 2012 R2以降、.NET 4.7.2、TLS 1.2、管理対象デバイスと同等のIntuneネットワーク要件、Azure更新サービスへの443番ポート通信などが示されています。(Microsoft Learn)
サーバーOSは「2012 R2以降」だけで判断しない
公式要件上はWindows Server 2012 R2以降が示されています。ただし、ここで見落としやすいのが強力なマッピングのサポート条件です。
Microsoft Learnでは、Microsoft Intune Certificate Connectorの強力なマッピングはWindows Server 2019以降でのみサポートされると明記されています。(Microsoft Learn)
そのため、次のように判断すると安全です。
| 現在のサーバー | そのまま使える可能性 | 判断基準 |
|---|---|---|
| Windows Server 2012 R2 | 限定的 | 最低要件は満たしても、長期運用や強力なマッピングを考えると移行候補 |
| Windows Server 2016 | 限定的 | 強力なマッピング要件がある場合は移行を検討 |
| Windows Server 2019 | 高い | 強力なマッピング対応の観点で有力な選択肢 |
| Windows Server 2022以降 | 高い | 新規導入・移行先として優先しやすい |
既存環境で「要件上は2012 R2以降だから問題ない」と判断している場合は、強力なマッピング、OSサポートライフサイクル、監査要件、セキュリティ基準を含めて再評価してください。
デスクトップエクスペリエンスとMicrosoft Edgeを確認する
Certificate ConnectorをインストールするWindows Serverは、デスクトップエクスペリエンスで構成する必要があります。また、Windows Server 2019以前では、コネクタのセットアップ前にMicrosoft Edgeを手動インストールする必要があるとされています。(Microsoft Learn)
新規構築時は、Server Coreではなくデスクトップエクスペリエンスを選定しているかを確認してください。既存サーバーへ追加導入する場合は、セットアップウィザードや認証画面でつまずく前に、Edgeの有無を確認しておくと切り分けが早くなります。
.NET 4.7.2とTLS 1.2は事前に確認する
公式前提条件には、.NET 4.7.2とTLS 1.2が含まれています。(Microsoft Learn)
特に古いWindows Serverや、セキュリティポリシーを独自に強化している環境では、TLS設定が原因でクラウドサービスとの通信に失敗することがあります。インストール作業の当日に確認するのではなく、変更作業前の事前チェックで確認しておくべき項目です。
自動更新に必要な通信を許可する
Certificate Connectorの自動更新をサポートするには、Azure更新サービスへのアクセスが必要です。公式ドキュメントでは、ポート443、エンドポイント autoupdate.msappproxy.net が示されています。(Microsoft Learn)
プロキシやファイアウォールで外向き通信を制限している企業では、次の点を確認してください。
- コネクタサーバーからインターネット向けHTTPS通信が許可されているか
- プロキシ認証が必要な場合、サービス実行ユーザーで通信できるか
- TLSインスペクションがIntune関連通信に影響していないか
- 自動更新エンドポイントが例外登録されているか
- 通信遮断時に検知できるログ監視があるか
自動更新が止まると、将来の修正や互換性対応に追従できなくなる可能性があります。導入時だけ通信を開けるのではなく、運用中も継続して到達できる設計にしてください。
拡張セキュリティ構成を無効化する
公式前提条件には、拡張セキュリティ構成を非アクティブ化する必要があることも含まれています。(Microsoft Learn)
これはサーバーの安全性を軽視してよいという意味ではありません。コネクタのセットアップやクラウド連携に必要な操作が、過度なブラウザー制限で妨げられないようにするための要件です。実務では、無効化範囲、サーバーへのログオン制限、管理者アクセスの監査、不要なブラウジング禁止などをセットで運用してください。
BitLocker推奨をどう扱うべきか
今回の更新で最も実務上のインパクトが大きいのは、BitLockerまたは同等のディスク暗号化の推奨です。公式ドキュメントでは、Certificate ConnectorがインストールされているドライブでBitLockerまたは同等のディスク暗号化ソリューションを有効にすることが推奨されています。(Microsoft Learn)
新規導入では原則として有効化する
新規にコネクタサーバーを構築する場合、BitLockerを「後でやる」扱いにしないことが重要です。後から有効化しようとすると、変更申請、再起動、回復キー管理、監視設計を追加で調整する必要があります。
新規導入時は、次の順序で組み込むと安全です。
| 手順 | 作業内容 | 注意点 |
|---|---|---|
| 1 | サーバーOSを構築 | 強力なマッピングを考慮するならWindows Server 2019以降を優先 |
| 2 | BitLockerまたは同等の暗号化を有効化 | 回復キーの保管先と復旧手順を決める |
| 3 | .NET、TLS、Edgeなどを確認 | インストール前に確認する |
| 4 | ネットワーク到達性を確認 | Intune関連エンドポイントと自動更新先を確認 |
| 5 | Certificate Connectorをインストール | 必要な機能だけを選択する |
| 6 | 小規模グループで証明書配布を検証 | Wi-Fi/VPN/アプリ認証まで確認する |
既存環境では「暗号化できるか」より「暗号化しても復旧できるか」を確認する
既存のCertificate ConnectorサーバーでBitLockerを有効化する場合、単に設定をオンにするだけでは不十分です。
特に次の点を確認してください。
- 回復キーの保管場所が組織ルールに合っているか
- 遠隔地のサーバーで再起動後に復旧できる体制があるか
- 仮想マシンの場合、ホスト側暗号化やストレージ暗号化との役割分担が明確か
- 監視ツールやバックアップ製品に影響しないか
- 障害時に別サーバーへコネクタを再構成する手順があるか
証明書コネクタは認証基盤に近い位置にあるため、「暗号化したら終わり」ではなく、障害時の復旧手順まで含めて運用設計する必要があります。
PKCSを使う場合の前提条件
PKCSでは、Certificate ConnectorがIntuneサービスキューから要求を取得し、証明書発行処理を行います。公式ドキュメントでは、PKCS要求に使う証明書テンプレートに対して、証明書コネクタサービスアカウントが証明書を登録できる権限を持つこと、証明書テンプレートがCAに追加されていることが要件とされています。(Microsoft Learn)
複数コネクタ構成では権限差が障害になる
PKCSで特に重要なのは、どのコネクタがどの要求を処理するかを管理者側で指定できない点です。公式ドキュメントでは、PKCSをサポートする任意のコネクタインスタンスが保留中のPKCS要求、インポート証明書の処理、失効要求を扱う可能性があり、各要求を処理するコネクタを定義できないと説明されています。そのため、PKCSをサポートする各コネクタには同じ権限が必要で、PKCSプロファイルで定義されるすべてのCAへ接続できる必要があります。(Microsoft Learn)
これは移行時に非常に重要です。
たとえば、旧サーバーと新サーバーを並行稼働させる場合、新サーバーだけに一部CAへの権限がないと、処理するコネクタによって成功・失敗が分かれます。管理者から見ると「同じプロファイルなのに一部端末だけ失敗する」という状態になります。
PKCSで確認すべきチェックリスト
| 確認項目 | OKの判断基準 |
|---|---|
| 証明書テンプレート | CAに公開されている |
| テンプレート権限 | コネクタサービスアカウントに読み取り・登録権限がある |
| CA接続性 | すべてのPKCS対応コネクタから対象CAへ接続できる |
| 複数コネクタ | 権限と到達性が全コネクタでそろっている |
| 移行中の新旧サーバー | 一方だけ権限不足になっていない |
| 証明書プロファイル | Intune側のプロファイル設定とテンプレート名が一致している |
PKCSインポート証明書を使う場合の注意点
PKCSインポート証明書をサポートする場合、コネクタをホストするサーバーには追加構成が必要です。公式ドキュメントでは、コネクタサービスユーザーがキーを取得できるように、キー記憶域プロバイダーへのアクセス構成などが必要になると説明されています。(Microsoft Learn)
実務では、PFXインポートを使う環境ほど「証明書ファイルをアップロードできたから大丈夫」と判断しがちです。しかし、配布処理ではキーへのアクセス権、サービスアカウント、保護された秘密鍵の扱いが関係します。
次の観点で確認してください。
- PFXインポートで使うKSPにサービスアカウントがアクセスできるか
- 秘密鍵の保護方法が社内セキュリティ基準に合っているか
- 証明書の有効期限、更新、失効時の運用手順があるか
- テスト端末で実際に証明書を受け取り、認証先で使えるか
PFXや秘密鍵を扱う場合、Intune管理者だけで判断せず、PKI管理者とセキュリティ担当者を含めて設計するのが安全です。
証明書失効を使う場合の前提条件
証明書失効をCertificate Connector経由で行う場合、証明機関側でコネクタサービスアカウントが証明書を失効できるように構成する必要があります。(Microsoft Learn)
ここでのポイントは、失効権限を広く付けすぎないことです。失効は端末認証やサービス認証に直接影響します。誤った運用で有効な証明書を失効すると、対象端末がネットワークや社内サービスへ接続できなくなる可能性があります。
実務では、次のように分けて考えると安全です。
| 項目 | 推奨される考え方 |
|---|---|
| 失効権限 | 必要なCAに限定して付与する |
| 操作ログ | CA側、コネクタ側、Intune側のログ確認手順を用意する |
| 誤失効対策 | 変更申請、承認、対象確認を運用に入れる |
| 退職・紛失端末 | デバイスライフサイクル管理と連携する |
| 復旧 | 証明書再発行と端末再同期の手順を用意する |
SCEPを使う場合の前提条件
SCEPを使う場合は、PKCSよりも確認項目が増えます。公式ドキュメントでは、SCEP証明書をサポートするWindows Serverは一般的な前提条件に加え、IIS 7以降、Active Directory Certificate Servicesロールの一部であるNetwork Device Enrollment Service、つまりNDESが必要とされています。また、コネクタは発行元CAと同じサーバーではサポートされないとされています。(Microsoft Learn)
NDESと発行CAを同居させない
SCEPでよくある失敗は、サーバー台数を減らすためにNDESやコネクタを発行CAと同じサーバーに置こうとすることです。
公式要件では、コネクタは発行元CAと同じサーバーではサポートされません。SCEP構成では、NDESサーバー、Certificate Connector、CAの役割分担を明確にしてください。(Microsoft Learn)
SCEPで追加される役割と機能
公式ドキュメントでは、SCEP利用時にWindows Serverで追加するサーバーロールや機能として、Active Directory Certificate Services、Web Server IIS、.NET Framework 4.7関連機能、NDES、IISの要求フィルタリング、ASP.NET、IIS管理互換などが示されています。また、NDESには.NET Framework 3.5とHTTP Activationも必要とされています。(Microsoft Learn)
実務での確認表は次のとおりです。
| 分類 | 必要な項目 | 確認のポイント |
|---|---|---|
| IIS | IIS 7以降 | SCEP要求を処理するために必要 |
| AD CS | Network Device Enrollment Service | Microsoft CAでSCEPを使う場合に必要 |
| .NET | .NET Framework 4.7関連機能 | ASP.NET、WCF HTTP Activationを含めて確認 |
| .NET 3.5 | .NET Framework 3.5、HTTP Activation | NDES要件として確認 |
| IIS管理 | IIS管理コンソール、IIS 6管理互換 | NDES構成や管理で必要 |
| 配置 | 発行CAと同居しない | サポート外構成を避ける |
SCEP証明書テンプレートは「登録」ではなく「自動登録」も見る
SCEP証明書テンプレートでは、Certificate Connectorサービスアカウントが証明書を自動登録できるように権限を構成し、テンプレートをCAに追加する必要があります。(Microsoft Learn)
PKCSとSCEPではテンプレート権限の見方が微妙に異なります。SCEPでは、NDESアプリケーションプールユーザーの権限も関係するため、コネクタサービスアカウントだけを見て終わらせないでください。
アカウントと権限の確認ポイント
Certificate Connectorの導入では、複数のアカウントが登場します。権限不足でも過剰権限でも問題が起きるため、役割ごとに整理して確認することが重要です。
公式ドキュメントでは、インストールアカウント、証明書コネクタサービスアカウント、NDESアプリケーションプールユーザー、Microsoft Entraユーザーについて要件が示されています。(Microsoft Learn)
アカウント別の権限整理
| アカウント | 主な用途 | 必要な権限・条件 |
|---|---|---|
| インストールアカウント | コネクタソフトウェアのインストール | Windows Serverのローカル管理者権限 |
| 証明書コネクタサービスアカウント | Intune通信、CAアクセス、PKI要求処理 | サービスとしてログオン、テンプレートの読み取り・登録、必要に応じてCAの発行と管理、KSPアクセス |
| NDESアプリケーションプールユーザー | SCEPでNDESを実行 | SCEPテンプレートの読み取り・登録、IIS_IUSRSグループ所属 |
| Microsoft Entraユーザー | コネクタ構成時の認証 | 組み込みIntune Administratorロール、Intuneライセンス |
証明書コネクタサービスアカウントとしては、SYSTEMまたはWindows Serverの管理者であるドメインユーザーがサポートされています。(Microsoft Learn)
サービスアカウント設計で失敗しやすいポイント
最も多い失敗は、「インストールできたので権限は問題ない」と判断してしまうことです。インストール権限と、証明書発行・失効・PFXインポートに必要な権限は別物です。
以下のような状況では、後から障害が出やすくなります。
- ローカル管理者でインストールしたが、サービスアカウントにテンプレート権限がない
- 失効シナリオを追加したが、CA側で証明書の発行と管理権限を付けていない
- PFXインポートを使うのにKSPへのアクセス権を確認していない
- SCEPでNDESアプリケーションプールユーザーの権限を見落としている
- Microsoft Entra側の構成ユーザーにIntuneライセンスがない
- 一時的な特権アカウントで構成し、後で監査時に所有者が分からなくなる
サービスアカウントは、構築時の都合ではなく、運用・監査・引き継ぎを前提に命名、権限、保管、棚卸しを行ってください。
既存環境で今すぐ確認すべきチェックリスト
既にCertificate Connector for Microsoft Intuneを使っている場合は、次の順番で確認すると効率的です。
| 優先度 | 確認項目 | 見るべきポイント |
|---|---|---|
| 高 | BitLockerまたは同等の暗号化 | コネクタのインストールドライブが暗号化されているか |
| 高 | Windows Serverのバージョン | 強力なマッピング要件を満たすか |
| 高 | 自動更新の通信 | autoupdate.msappproxy.net へ443番で到達できるか |
| 高 | TLS 1.2 | クラウド通信に必要な設定が有効か |
| 高 | サービスアカウント権限 | テンプレート、CA、KSP、失効権限が用途に合っているか |
| 中 | Microsoft Edge | Windows Server 2019以前で手動インストール済みか |
| 中 | デスクトップエクスペリエンス | サポートされるサーバー構成か |
| 中 | SCEPのNDES配置 | 発行CAと同居していないか |
| 中 | 複数PKCSコネクタの権限差 | 全コネクタで同じCA・テンプレートへアクセスできるか |
| 中 | Intune管理者ロール | 構成に使うEntraユーザーがIntune Administratorかつライセンスありか |
このチェックで問題が見つかった場合、すぐに本番変更するのではなく、影響範囲を分けて対応してください。特に証明書テンプレート権限やCA権限の変更は、発行済み証明書、更新処理、失効処理に影響する可能性があります。
新規導入時のおすすめ手順
Certificate Connectorを新規導入する場合は、次の流れで進めると失敗を減らせます。
使う証明書方式を決める
最初に、PKCS、SCEP、PKCSインポート、失効のどれを使うかを決めます。方式によってサーバーロール、NDES、テンプレート権限、KSPアクセス、CA権限が変わるためです。
たとえば、Wi-Fi認証用に端末証明書を配布する場合でも、組織のPKI設計によってPKCSを選ぶかSCEPを選ぶかが変わります。すでにNDES運用があるか、秘密鍵をどこで生成するか、証明書更新をどう管理するかを含めて検討してください。
サーバーを選定する
新規導入では、将来の運用を考えるとWindows Server 2019以降を選ぶのが現実的です。強力なマッピングのサポート条件を満たしやすく、古いサーバーからの移行を後回しにしなくて済みます。
SCEPを使う場合は、発行CAと同じサーバーに置かないことも最初に決めてください。
ネットワークを先に開ける
Certificate Connectorは、インストールできてもIntuneや更新サービスへ通信できなければ機能しません。プロキシ配下の環境では、OSログオンユーザーで通信できてもサービス実行時に通信できないことがあります。
事前に以下を確認します。
- Intune関連エンドポイントへの到達性
- Azure更新サービスへの443番通信
- プロキシ認証の有無
- TLS検査の影響
- ファイアウォールログでの拒否有無
証明書テンプレートとCA権限を準備する
証明書テンプレートは、Intune側の証明書プロファイルと整合している必要があります。名前、用途、サブジェクト、SAN、キー使用法、有効期限、登録権限を確認してください。
PKCSではコネクタサービスアカウントの登録権限、SCEPでは自動登録権限やNDES関連ユーザーの権限も確認します。
小規模グループでテストする
本番全体に展開する前に、必ず小規模グループで検証してください。テストでは「証明書が端末に届いた」だけでは不十分です。
次の流れまで確認します。
- Intuneで対象端末に証明書プロファイルを割り当てる
- 端末に証明書が配布される
- 証明書チェーンが正しく認識される
- Wi-Fi、VPN、社内アプリなど実際の認証先で使える
- 証明書更新や再発行の動作を確認する
- 失効を使う場合は失効後の挙動を確認する
証明書配布は、Intune管理画面だけで完結するテストではありません。認証先まで含めて確認することが重要です。
移行・更新時に注意すべきポイント
既存のCertificate Connectorサーバーを新しいWindows Serverへ移行する場合、特にPKCS構成では慎重に進める必要があります。PKCSをサポートする各コネクタは、すべてのCAへ接続でき、同じ権限を持つ必要があるためです。(Microsoft Learn)
新旧コネクタの並行期間に権限差を作らない
移行中は、新サーバーだけを一部設定した状態で本番に参加させないようにしてください。
悪い例は次のような構成です。
| 旧コネクタ | 新コネクタ | 起きる問題 |
|---|---|---|
| CA-A、CA-Bに接続可能 | CA-Aのみ接続可能 | CA-B向け要求を新コネクタが拾うと失敗する |
| すべてのテンプレート権限あり | 一部テンプレート権限なし | 一部プロファイルだけ失敗する |
| 失効権限あり | 失効権限なし | 失効処理が不安定になる |
| KSPアクセスあり | KSPアクセスなし | PFXインポート処理が失敗する |
移行時は、旧環境と同等の権限・到達性を新環境に設定し、テスト後に段階的に切り替えるのが安全です。
古いOSからの移行は「コネクタだけ」ではなく周辺構成も見る
Windows Server 2012 R2や2016から移行する場合、サーバーOSだけを新しくしても十分ではありません。
以下も一緒に確認してください。
- 証明書テンプレートの権限
- CAへのRPC/DCOM通信などオンプレミス側の到達性
- NDESのアプリケーションプールユーザー
- IISの機能と管理互換
- プロキシ設定
- ウイルス対策・EDRの除外や監視
- BitLocker回復キー管理
- ログ監視とアラート
証明書コネクタは、クラウドとオンプレミスPKIの境界にあるコンポーネントです。OS移行だけでなく、ネットワーク、ID、PKI、運用監視をまとめて確認する必要があります。
管理者・開発者が見落としやすい失敗例
「証明書が配布されない」をIntuneだけで調べてしまう
証明書配布の失敗は、Intune側だけでなく、CA、テンプレート、NDES、IIS、サービスアカウント、ネットワーク、端末側の証明書ストアが関係します。
まずは次のように切り分けます。
| 症状 | 疑うポイント |
|---|---|
| すべての端末で失敗 | コネクタ停止、ネットワーク遮断、Intune通信、CA接続 |
| 一部プロファイルだけ失敗 | 証明書テンプレート権限、CA追加漏れ、プロファイル設定 |
| SCEPだけ失敗 | NDES、IIS、アプリケーションプールユーザー、SCEPテンプレート |
| PFXインポートだけ失敗 | KSPアクセス、秘密鍵、サービスアカウント権限 |
| 失効だけ失敗 | CAの発行と管理権限、失効構成 |
サービスアカウントを強くしすぎる
トラブルを避けるためにサービスアカウントへ広い権限を与えたくなりますが、証明書基盤では過剰権限がリスクになります。
ただし、最小権限を意識しすぎて必要権限を欠くと、証明書発行や失効が失敗します。重要なのは、必要な用途ごとに権限を分け、理由を記録することです。
たとえば、失効を使わない環境でCAの「証明書の発行と管理」権限を安易に付ける必要はありません。一方、失効を使うならその権限が必要になります。
SCEP構成でNDESユーザーを忘れる
SCEPでは、Certificate Connectorサービスアカウントだけでなく、NDESアプリケーションプールユーザーも関係します。公式ドキュメントでは、NDESアプリケーションプールユーザーに対して、各SCEP証明書テンプレートの読み取り・登録権限と、IIS_IUSRSグループのメンバーであることが示されています。(Microsoft Learn)
SCEPの失敗では、Intune側のプロファイルよりもNDES/IIS/テンプレート権限が原因になることがあります。
自動更新通信を一時的にしか許可しない
インストール時だけ通信を開け、その後に閉じてしまう運用は避けてください。自動更新ができないと、将来の修正やサービス側変更に追従できない可能性があります。
セキュリティ要件で外向き通信を絞る場合でも、必要な宛先とポートを例外として明確にし、継続的に監視してください。
実務で使える確認順序
既存環境の棚卸しや新規導入レビューでは、次の順番で確認すると効率的です。
| 順番 | 確認内容 | 目的 |
| -: | ——————————— | —————————— |
| 1 | 使う方式を確認する | PKCS、SCEP、PFXインポート、失効で要件が変わるため |
| 2 | サーバーOSと強力なマッピング要件を確認する | 古いOSの移行要否を判断するため |
| 3 | BitLockerまたは同等の暗号化を確認する | 更新内容とセキュリティ基準へ対応するため |
| 4 | .NET、TLS、Edge、デスクトップエクスペリエンスを確認する | セットアップ失敗を防ぐため |
| 5 | ネットワーク到達性を確認する | Intune通信と自動更新を維持するため |
| 6 | CAと証明書テンプレートを確認する | 証明書発行失敗を防ぐため |
| 7 | サービスアカウント権限を確認する | 発行、失効、KSP、NDESの権限不足を防ぐため |
| 8 | 小規模テストを実施する | 本番展開前にユーザー影響を抑えるため |
| 9 | ログ監視と運用手順を整備する | 障害時の復旧を早めるため |
この順序で見れば、単なるインストール要件の確認ではなく、実運用で証明書が安定して配布されるかまで確認できます。
まとめ：まずはコネクタサーバーと権限の棚卸しから始める
Certificate Connector for Microsoft Intuneの前提条件で管理者が最初に確認すべきなのは、サーバー要件、BitLockerなどのディスク暗号化、ネットワーク到達性、証明書テンプレート権限、サービスアカウント権限です。
2026年5月時点の更新では、BitLockerまたは同等のディスク暗号化の推奨が明確化されており、既存環境でもセキュリティレビューの対象として確認する価値があります。あわせて、Windows Server 2019以降でのみサポートされる強力なマッピング、SCEP利用時のNDES要件、PKCS複数コネクタ構成での権限差にも注意が必要です。
次に取るべき行動は、現在の構成を次の4点で棚卸しすることです。
- コネクタサーバーのOS、暗号化、.NET、TLS、Edge、ネットワーク
- PKCS、SCEP、PFXインポート、失効のどれを使っているか
- 証明書テンプレート、CA、KSP、NDESの権限
- 複数コネクタ構成や移行中環境で権限差がないか
証明書配布は、問題が起きてから調べると影響範囲が広がりやすい領域です。今回の前提条件更新を機に、Certificate Connector for Microsoft Intuneの構成を見直し、証明書発行・更新・失効が安定して動く状態に整えておきましょう。
コメント