移行 · ADCS AND NDES
最後の証明書サーバーを廃止する。
ADCSが残り続ける理由は主に三つあります。IntuneのためのNDES、ドメイン参加済みPCの自動登録、そしてドメインコントローラーのKerberos証明書です。SCEPmanはAzureテナントからこの三つをすべてカバーするため、CA、CDP Webサーバー、NDESサーバーをユースケースごとに順番に廃止できます。
- NDESが不要
- クライアントソフトウェア不要のグループポリシー自動登録
- ドメインコントローラー証明書
- 既存ルートCA配下の中間CA
比較
ADCS、NDESおよびSCEPmanの運用に必要なもの
各オプションの作業量をドキュメントに基づいてまとめています。
| PKCSコネクターを使用したMicrosoft CA | SCEPを使用したNDES | SCEPman | |
|---|---|---|---|
| セットアップ | 2 to 3 days and more: CRL配布ポイント、テンプレート、GPO、サービスアカウント、コネクターバージョン | 2 more days and more: 証明書の種類ごとに1台のNDESサーバー、追加テンプレートが2つ、デバッグが困難 | コアサービスのセットアップにunder 30 minutes |
| メンテナンス | CDPの監視、コネクターの監視、OSのアップデート | 上記すべてに加え、登録エージェント証明書の手動更新 | AzureでのHealth監視、App Serviceがプラットフォームをアップデート |
| 失効 | 手動。CAデータベースの検索が難しい | 手動 | Entra ID、IntuneおよびJamfから自動失効。Certificate Masterで手動失効も可能 |
| 可用性 | 複数の障害ポイント: 仮想化、OS、CDP Webサーバー、コネクター | 同上に加えNDES | App Service、オプションでTraffic Manager配下の2リージョン構成 |
| スケーリング | CAクラスターが必要で、手動で構成 | NDESサーバーを複数台用意 | 自動スケーリング、またはわずか数クリック |
| バックアップ | CAデータベース、CAキーおよび設定を定期的にバックアップ | 同上 | コアサービスはステートレス。キーはKey Vaultに保存、ストレージバックアップはオプション |
| 攻撃対象領域 | Tier 0サーバーがコネクター経由でインターネットと通信 | Tier 0資産であるNDESへのインバウンドアクセス | Entra認証済みエンドポイント、プライベートエンドポイント経由のKey VaultとStorage |
| MDM | Intuneのみ | 複数対応、ただし各々にNDESインスタンスが必要 | Intune、Jamf Proおよびその他のMDM |
ENTERPRISE EDITION · 3.0以降
ADCSなしでドメイン参加済みWindowsに証明書を発行
ドメイン内のWindowsクライアントは、グループポリシーが登録サービスを指定し、Kerberosで本人確認を行い、自動登録が残りを処理するという登録の流れをすでに備えています。SCEPmanのActive Directoryエンドポイントがその登録サービスとして機能します。ADにサービスプリンシパルを登録してグループポリシーでSCEPmanを参照先として設定すると、コンピューターとユーザーはWindowsに組み込まれたツールで登録を行います。クライアントへのインストールは不要です。
- user, computer, RDP server and domain controller向けのテンプレートを個別に有効化。
- 有効期間の残りが20%を下回ると、クライアントが自動的に更新。
- 登録を指定したADグループのメンバーに限定。
- SCEPmanはSID拡張を付与するため、KB5014754以降にドメインコントローラーが適用するストロングマッピング要件を証明書が満たします。
KERBEROS
ドメインコントローラーへの証明書発行
Entra参加済みおよびハイブリッド参加済みデバイスがオンプレミスリソースにサインインするためには、ドメインコントローラーにKerberos認証証明書が必要です。ハイブリッドキー信頼のWindows Hello for Businessも同様です。SCEPmanはActive Directoryエンドポイントのドメインコントローラーテンプレートか、専用のDCエンドポイントを通じてこの証明書を発行します。証明書には、クライアント認証、サーバー認証、Kerberos認証、スマートカードログオンの拡張キー使用法が含まれます。
共存
SCEPmanをルートCA配下の中間CAとして追加
初日にルートCAを置き換える必要はありません。Enterprise EditionではSCEPmanを中間CAとして運用できます。既存のルートCAがSCEPmanのCA証明書に署名し、その証明書はKey Vaultに保管されます。ルートCAを信頼するデバイスはSCEPmanの証明書をすぐに信頼するため、ADCSが残りのユースケースを処理し続ける間に、移行を段階的に進めることができます。
5ステップの移行パス
ネットワークチームと順序を計画してください。最初のデバイスがSCEPman証明書を提示する前に、RADIUSサーバーとVPNゲートウェイが新しいルートを信頼している必要があります。
- ルートCAの決定ルートCAの決定新しいSCEPmanルートをMDMとグループポリシーで展開するか、現在のルートCA配下でSCEPmanを中間CAとして運用するかを選択します。
- SCEPプロファイルの追加SCEPプロファイルの追加MDMにSCEPmanを参照先とする新しいSCEPプロファイルを既存プロファイルと並行して追加し、デバイスが新しい証明書を取得したらNDESプロファイルを削除します。
- Windowsの移行Windowsの移行Active Directoryエンドポイントを有効化し、自動登録ポリシーをテンプレートごとに順番に切り替えます。
- サーバーの移行サーバーの移行サーバー証明書はCertificate Master、ESTまたはAPIを通じて、ドメインコントローラーはそれぞれのテンプレートを通じて移行します。
- ADCSの廃止ADCSの廃止残った証明書を失効させ、最後のCRLを公開してから、CA、CDPおよびNDESを廃止します。
ADCSからの移行に関するよくある質問
01SCEPmanとADCSは並行して運用できますか？
できます。両者は別々のCAであるため、移行中はデバイスが両方の証明書を保持できます。
02Enterprise Editionが必要ですか？
Active Directoryエンドポイント、ドメインコントローラー証明書、Certificate Masterおよび中間CAを使用するには、Enterprise Editionが必要です。
03MDMを使用しないユーザーの証明書はどうなりますか？
ドメイン参加済みユーザーはActive Directoryエンドポイントを通じて取得し、それ以外のユーザーはCertificate Masterまたはセルフサービス登録を利用します。
04SCEPmanを社内ネットワークに配置する必要がありますか？
不要です。クライアントはHTTPS経由でアクセスし、Active DirectoryエンドポイントはKerberosと登録済みサービスプリンシパルを使用して認証を行います。
ADCSからの移行を計画する。
最も影響の大きいMDMとNDESの移行から始め、最後のテンプレートが移行し終わるまでADCSを維持してください。