1. サイトに紐づいたActive Directory Certificate Services（AD CS）

1. AD CSとは

エンタープライズ環境で、Active Directory Certificate Services（AD CS）を使って、各種証明書を一元管理されている企業様は、多数いらっしゃると思います。
AD CSとは「Active Directory証明機関」のことで、証明書（暗号化や身元保証に使われます）を一元的に発行・管理するための権威機関を提供するサーバーサービスとなります。標準的なPKI仕様に添って運用されますが、Active Directory環境では「証明書自動発行」といったオートメーション機能も持っています。詳細な情報については、 Active Directory 証明書サービスとは | Microsoft Learnなどをご参照くださればと思います。
余談ですが、AD CSはAzureクラウド環境でも利用されるケースがあります。Azure Certificate-Based Authentication（Azure証明書ベース認証）と呼ばれ、パスワードの代わりにユーザー証明書による認証でAzure AD参加／ハイブリッドAzure AD参加クライアントやAzureポータルにサインインできる機能です。ご興味がある方は、 Azure AD の証明書ベースの認証の概要 - Microsoft Entra | Microsoft Learnなどをご参照ください。

2. AD CSを複数管理する

PKI仕様では、大元となる「ルート証明機関」はただ1つのサービスが対象となり、実務的に発行を行う「下位証明機関」が必要数設置されます。エンタープライズ環境では閉塞かつ簡略化のため1つであることが多いのですが、複数置かれるケースもあります。管理上の問題で発行機関を分割したい、あるいは単純に「ネットワーク的に遠い場所」にアクセスさせたくない、といった場合です。このほか、証明機関の移行・差し替えの目的で「完全新規」に作成し、期間限定で並列運用するというケースも、ないわけではありません。
AD CSでは「特定証明機関を指定して」証明書発行を行うことは、原則的にはあまり想定していません。コマンド「certutil.exe」では一応用意されていますが（ certutil | Microsoft Learnを参照）、Active Directoryでの自動発行の場合、何の設定も行わないと、任意の証明機関にアクセスしてしまいます。

今回は、Active Directoryでの自動発行時に、任意の証明機関にアクセス可能な方法について、お話ししたいと思います。

3. AD CSをActive Directoryサイトに紐づける

AD CSはActive Directory上で、証明書発行のための配布ポイントが登録されています。具体的には"CN=testdom-CHABDRCS-CA,CN=Enrollment Services,CN=Public Key Services,CN=Services,CN=Configuration,DC=testdom,DC=local"といったかたちで、Configurationパーティションに記録されています。（[Active Directoryサイトとサービス]スナップインから[サービスノードの表示]で表示することができます。）
その配布ポイントのオブジェクトに含まれる「msPKI-Site-Name」属性にActive Directoryサイト名が存在する場合、その属性値に合致したサイトに所属するクライアントが証明書発行依頼をしてくる、ということになります。
なおActive Directoryサイトとは、コンピューターやネットワークの物理境界を表わす概念・設定となり、物理的・ネットワーク的に同一な環境をグルーピングできる便利な機能です。詳細については、サイトの機能 | Microsoft Learnなどをご参照ください。

設定の方法は非常に簡単です。certutilコマンドで、以下のように実行します。
certutil -f -setcasites set
それぞれ別の証明機関に対して実行したい場合、以下のように実行します。
certutil -f -setcasites -config "<サーバー名>\<CA名>" "<(紐づける)サイト名>"

4. AD CSを複数管理する場合の注意点

AD CSは、Active Directory上で自動配布を行うエンタープライズCAのケースでは、ルート証明機関の複数同時運用はあまり推奨されない理解です。完全に別の証明機関のため、管理が非常に煩雑になってしまううえに、一部の情報（証明書テンプレート）を両方のCAで共有利用するかたちになってしまうためです。
証明書テンプレートは配布する証明書を定義するためのひな型であり、Active Directoryデータベースに埋め込まれています。そのまま使うこともできますが、カスタマイズも可能です。しかしひとつの証明機関からのカスタマイズが想定されているので、他の証明機関からどのように扱われるのか、筆者も試したことはありません。不測の動作をどうしても避けたい、というのであれば、無理に採用しないことをお奨めします。1つの証明機関を機能はそのまま、別のサーバーに移したい、という場合、簡単に実行できるからです。機会があれば、お話しさせていただきます。
話を戻しまして、以下、上記に関する検証結果を、掲載したいと思います。

2. Site Awareness for AD CS検証結果について

1. 検証環境要件

本件における、環境要件について、記載する。

なお本環境については、AD DS Site Awareness for AD CS and PKI Clients - TechNet Articles - United States (English) - TechNet Wiki (microsoft.com)資料を参考に検証を行った。

1.1. Active Directory構成

[Default-First-Site-Name] [Default-Second-Site-Name]それぞれ異なるサブネットも構成した。

2. 検証作業の詳細

検証作業については、以下のように実行した。あわせて確認ポイントを記載する。

2.1. [Default-Second-Site-Name]側CAのサイト紐づけ

2.2. [Default-First-Site-Name]側CAのサイト紐づけ

上記CAマシンのコマンドプロンプトを起動し、以下コマンドを入力実行

2.3. [Default-Second-Site-Name]側CAのサイト紐づけ解除

2.4. すべてのCAのサイト紐づけ

任意のCAマシンのコマンドプロンプトを起動し、以下コマンドを入力実行

3. 検証結果

上記4つの検証から、以下の結果が得られた。