証明書登録 Web サービスは、ユーザーとコンピューターが HTTPS プロトコルを使用して証明書の登録を実行できるようにする Active Directory 証明書サービス (AD CS) 役割サービスです。 証明書登録ポリシー Web サービスと共に、これにより、クライアント コンピューターがドメインのメンバーでない場合、またはドメイン メンバーがドメインに接続されていない場合に、ポリシー ベースの証明書の登録が有効になります。 証明書登録 Web サービスは、HTTPS プロトコルを使用して証明書要求を受け入れ、発行された証明書をネットワーク クライアント コンピューターに返します。 証明書登録 Web サービスは、DCOM プロトコルを使用して証明機関 (CA) に接続し、要求者に代わって証明書の登録を完了します。
HTTPS 経由での証明書の登録により、次のことが可能になります。
- フォレスト境界を越えて証明書を登録し、企業内の CA の数を減らす
- モバイル ワーカーとビジネス パートナーに証明書を発行するためのエクストラネット展開
この記事では、認証の種類、負荷分散に関する考慮事項、構成オプションに関する情報など、証明書登録 Web サービスの概要について説明します。
認証の種類
証明書登録 Web サービスでは、次の 3 種類の認証がサポートされています。
Windows 統合認証
クライアント証明書の認証
ユーザー名とパスワード認証
これらの認証の種類については、次のセクションで詳しく説明します。
Windows 統合認証
Windows 統合認証では、Kerberos または NT LAN Manager (NTLM) を使用して、内部ネットワークに接続され、ドメインに参加しているデバイスにシームレスな認証フローが提供されます。 この方法は、Active Directory Domain Services (AD DS) 内に存在する既存のインフラストラクチャを使用し、証明書クライアント コンピューターの変更を最小限に抑える必要があるため、内部展開に適しています。 この認証方法は、クライアントが内部ネットワークに直接接続されている間に Web サービスにアクセスするだけで済む場合に使用します。
クライアント証明書の認証
証明書がコンピューターにプロビジョニングされている場合、クライアント コンピューターはクライアント証明書認証を使用できます。 クライアント証明書認証では、企業ネットワークへの直接接続は必要ありません。 クライアント証明書認証は、より安全な認証方法を提供するため、ユーザー名とパスワードの認証よりも優先されます。 ただし、この方法では、 最初は x.509 証明書 を個別の手段でクライアントにプロビジョニングする必要があります。 クライアント認証用のデジタル X.509 証明書をユーザーに提供する場合は、この認証方法を使用します。 この認証方法を使用すると、Web サービスをインターネットで使用できるようになります。
ワークグループで構成されているコンピューター、またはフォレストの信頼関係がないドメインのメンバーであるコンピューターに対して、ドメインの外部から証明書ベースの認証を使用する場合は、次の操作も行う必要があります。
- CA がメンバーであるフォレスト内に、証明書を受け取るコンピューターと同じ名前のコンピューター アカウントが存在することを確認します。
- 証明書を発行するコンピューターに適した名前を使用して証明書を発行します。
- 発行された証明書を、ドメイン内のコンピューターから、ワークグループで構成されているか、フォレストの信頼関係がないドメインのメンバーである適切なコンピューターに手動で転送します。
ユーザー名とパスワード認証
認証の最も簡単な形式は、ユーザー名とパスワードです。 この方法は、通常、内部ネットワークに直接接続されていないクライアントにサービスを提供するために使用されます。 これは、クライアント証明書を使用するよりも安全性の低い認証オプションですが、クライアントに証明書をプロビジョニングする必要がないため、多くの場合、クライアント証明書認証よりも実装が簡単です。 ユーザーが Web サービスに対して認証するためにユーザー名とパスワードを入力する場合は、この認証方法を使用します。 この認証方法は、内部ネットワークまたはインターネット経由で Web サービスにアクセスするときに使用できます。
委任の要件
委任を使用すると、サービスは、ネットワーク全体のリソースにアクセスするために、ユーザー アカウントまたはコンピューター アカウントを偽装できます。 サービスが委任に対して信頼されている場合、そのサービスはユーザーを偽装して他のネットワーク サービスを使用できます。
次のすべてが当てはまる場合は、証明書登録 Web サービス アカウントに委任が必要です。
CA が証明書登録 Web サービスと同じコンピューター上にない
証明書登録 Web サービスは、証明書の更新要求のみを処理するのではなく、初期登録要求を処理できる必要があります
認証の種類が Windows 統合認証またはクライアント証明書認証に設定されている
次の場合、証明書登録 Web サービスの委任は必要ありません。
CA と証明書登録 Web サービスが同じコンピューター上にある
ユーザー名とパスワードは認証方法です。
証明書登録 Web サービスが組み込みのアプリケーション プール ID として実行されている場合は、サービスをホストしているコンピューター アカウントで委任を構成する必要があります。 証明書登録 Web サービスがドメイン ユーザー アカウントとして実行されている場合は、まず適切なサービス プリンシパル名 (SPN) を作成してから、ドメイン ユーザー アカウントに委任を構成する必要があります。
構成する必要がある委任の特定の種類は、証明書登録 Web サービスに対して選択された認証方法によって異なります。
- Windows 統合認証を選択した場合は、Kerberos のみを使用するように委任を構成する必要があります。
- サービスがクライアント証明書認証を使用している場合は、任意の認証プロトコルを使用するように委任を構成する必要があります。
負荷分散とフォールト トレランスのベスト プラクティス
Microsoft による広範なパフォーマンス テストによると、スループットに影響を与える最大の要因は、ネットワーク待機時間です。 ネットワーク負荷分散 (NLB) テクノロジに依存するのではなく、証明書登録ポリシー Web サービスおよび証明書登録 Web サービス クライアント コンポーネントには、負荷分散とフォールト トレランス ロジックが組み込まれています。 たとえば、クライアントは提供されているエンドポイントの一覧を自動的にランダム化し、最初のエンドポイントが応答しない場合にリストを反復処理しようとします。 複数の均一なリソース識別子 (URI) が公開されている限り、基本的な負荷分散とフォールト トレランスが組み込まれます。
NLB は、ポリシーまたは Web サービスが停止または使用できないホストにトラフィックをルーティングする可能性があるため、フォールト トレランスや高可用性を提供するために NLB を使用しないでください。 すべてのエンドポイントが単一の NLB バランス URI の背後に発行されている場合、組み込みのクライアント ロジックで次の URI を試すことはできません。そのため、特別な負荷分散がまったく使用されていない場合よりもフォールト トレラントなソリューションが少なくなります。
ポリシーと登録 Web サービスの負荷分散に関する一般的なベスト プラクティスは次のとおりです。
- 一意の DNS 名を持つ複数の登録 URI とポリシー URI を発行し、必要に応じて異なるネットワーク パスで使用できます。を使用すると、組み込みのクライアント ロジックで負荷分散とフォールト トレランスを提供できます。
- 1 つの URI の背後に複数の URI を発行しないでください (その URI がネットワーク層とアプリケーション 層対応の両方のデバイスの背後で負荷分散されている場合を除く)。
- DNS ラウンド ロビンや、アプリケーション層のインテリジェンスとルーティングを提供しない他の DNS 負荷分散手法は使用しないでください。
構成オプション
次のセクションでは、証明書登録 Web サービスのさまざまな構成オプションについて説明します。
1 つのフォレストを含むイントラネット
最も単純な展開シナリオには、イントラネットに接続されたクライアントを持つ単一のフォレストが含まれます。 この設計では、証明書登録ポリシー Web サービスと証明書登録 Web サービスを発行元の CA にインストールできますが、別のコンピューターにインストールすることをお勧めします。 証明書登録ポリシー Web サービスと証明書登録 Web サービスが別々のコンピューターで実行されている場合、証明書登録ポリシー Web サービスは LDAP を使用して AD DS と通信できる必要があります。 証明書登録 Web サービスは、DCOM を使用して CA に接続できる必要があります。 イントラネット シナリオでは、Kerberos または NTLM が一般的な認証の種類です。
複数のフォレストを含むイントラネット
より高度なイントラネット シナリオでは、一元化された発行サービスを持つ複数のフォレストが、そのうちの 1 つ (または一部) にのみ含まれます。 この設計では、フォレストは双方向のフォレスト信頼に接続され、CA と証明書登録 Web サービスは同じフォレストでホストされます。 このモデルの利点は、複数のフォレスト環境で高度な統合を実現できる点です。 以前は、各フォレストで自動登録に独自の CA が必要になりました。すべての PKI サービスが一元化され、必要な CA の合計数が大幅に削減される可能性があります。 ここでも、これはイントラネット シナリオであるため、最も一般的な認証スキームは Kerberos または NTLM です。
境界ネットワークと支店
この展開シナリオでは、組織のネットワークに直接接続されていない、または仮想プライベート ネットワーク (VPN) 経由で接続されていないユーザーとコンピューターを登録する機能が提供されます。 この設計では、証明書登録ポリシー Web サービスと証明書登録 Web サービスの両方が境界ネットワークに配置され、インターネット ベースのクライアントが HTTPS 経由でこれらのエンドポイントに登録されます。 このデプロイ モデルは、リモートで作業することが多いドメイン ユーザーや、企業ネットワークへの VPN または直接接続が信頼できないブランチ オフィスのシナリオに最適です。
必要に応じて、読み取り専用ドメイン コントローラー (RODC) を使用できます。 外部クライアント (リモート ユーザー) は、書き込み可能なドメイン コントローラーまたは CA への Corp ファイアウォール経由でアクセスできません。 登録およびポリシー Web サービス サーバーは、書き込み可能なドメイン コントローラーにアクセスできません。 ただし、証明書登録 Web サービスは、ファイアウォール経由で DCOM 経由で CA に接続できるようにする必要があります。
更新専用モード
証明書登録 Web サービスが CA から証明書を要求できるようにするには、呼び出し元の偽装中に CA に呼び出しを委任する必要があります。 つまり、証明書登録 Web サービス アカウントで委任が有効になっている必要があります。 インターネットに接続する証明書登録 Web サービス エンドポイントの場合は、インターネットベースの脅威にさらされるレベルが高くなるため、これは推奨されない場合があります。
このリスクを軽減するために、更新専用モードでは、証明書登録 Web サービスが委任を有効にせずに証明書の更新要求のみを処理できます。 証明書登録 Web サービスは、内部ネットワーク内からプロビジョニングされた元の証明書を使用して、インターネット経由で送信された更新要求を認証します。 その後、証明書登録 Web サービスは、独自の資格情報で CA に要求を送信し、CA は元の証明書の要求元の Active Directory 情報または元の証明書のサブジェクト情報に基づいて証明書を更新します。 このモードでは、証明書登録 Web サービスによって新しい証明書登録要求が拒否され、CA に到達することはありません。
ネットワーク設計の観点から、このシナリオでは、前に説明した内部ネットワーク モデルと境界ネットワーク モデルの両方を組み合わせています。
キーによる更新
キーベースの更新モードでは、既存の有効な証明書を使用して独自の更新要求を認証できます。 これにより、内部ネットワークに直接接続されていないコンピューターは、既存の証明書を自動的に更新できます。
キーベースの更新を使用すると、AD DS フォレスト外の証明書クライアント コンピューターが有効期限が切れる前に証明書を更新できます。 これには、ワークグループで構成されているクライアントや、他の AD DS フォレストのメンバーであるクライアントが含まれます。 最初の証明書を取得するには、CA のフォレスト内のアカウントを使用する必要があります。 ただし、その証明書がクライアントに配布されると、キーベースの更新では、証明書の更新を許可するためにフォレストの信頼は必要ありません。
たとえば、ワークグループで構成された Web サーバーに発行された証明書は、エンタープライズ CA ドメイン メンバーによって更新できます。 このような構成の例を次の図に示します。
Web1 は、証明書の更新を要求する前に、信頼されたルート証明機関ストアにルート CA 証明書を持っている必要があります。 Web1 では、証明書登録 Web サービスを使用して、キーベースの更新が有効になっている場合に証明書を自動的に更新します。 また、Web1 の管理者は、証明書登録ポリシー Web サービスの URI が Web1 で構成されていることを確認する必要があります。
注
キーベースの更新を有効にする場合は、証明書登録 Web サービスのクライアント証明書認証を有効にする必要があります。
認証局 Web 登録役割サービスとの違い
CA Web 登録と証明書登録 Web サービスはどちらも HTTPS を使用しますが、基本的に異なるテクノロジです。 CA Web Enrollment には、特定のクライアント コンポーネントや構成を必要としない個々の証明書を要求するブラウザー ベースの対話型メソッドが用意されています。 CA Web 登録では、要求元が Web サイトを介して手動で作成およびアップロードする対話型要求のみがサポートされます。 たとえば、管理者が Linux オペレーティング システムを実行している Apache Web サーバーに証明書をプロビジョニングする場合、OpenSSL を使用して作成された PKCS #10 要求をアップロードできます。 CA が要求を発行した後、ブラウザーを使用して証明書をダウンロードできます。
証明書登録ポリシー Web サービスと証明書登録 Web サービスは、ネイティブ クライアントを使用した自動証明書要求とプロビジョニングに重点を置きます。 証明書登録 Web サービスと CA Web 登録は補完的なテクノロジです。 CA Web 登録では、証明書要求とクライアント オペレーティング システムの広範なセットがサポートされます。 証明書登録 Web サービスでは、クライアント コンピューターの要求と証明書のプロビジョニングが自動化されます。