我目前正在為網路未完全連接的客戶實施企業證書頒發機構；它跨越多個地理站點，其中一些沒有路由到 CA 所在的站點。

為了解決這個問題，我使用了Certificate Enrollment Web Service，它允許通過 HTTPS 進行證書註冊；該服務通過公共名稱和 IP 地址公開，遠端站點中的電腦可以通過這種方式訪問它。

該解決方案適用於各種證書；但是，遠端站點中的域控制器無法使用“Kerberos 身份驗證”模板（最近的 DC 在啟用自動註冊時嘗試使用該模板）獲取證書；該錯誤是通用的“RPC 伺服器不可用”，但它發生在 CA 本身，並記錄了失敗的請求。

這讓我困惑了一會兒，直到我決定查看網路流量；你瞧，似乎當使用模板“Kerberos 身份驗證”請求證書時，CA 嘗試連接回發出請求的域控制器。這在客戶網路中是不可能的，這似乎是請求失敗的原因。

我猜 CA 在某種程度上試圖驗證請求證書的電腦實際上是域控制器；但是，我找不到任何文件，而且這樣的“回調”似乎與證書請求的客戶端/伺服器邏輯相反。

這種行為是否記錄在任何地方？

可以關閉嗎？

CA 上的作業系統是 Windows Server 2019。

---

編輯

AD 森林中有四個域；CA 位於林根域中。

所有域中的所有 DC 的行為都是相同的：每當請求“Kerberos 身份驗證”證書時，無論是手動還是通過自動註冊，CA 都會嘗試在埠 445 和 139 上聯繫請求 DC（奇怪的是，有沒有實際的 LDAP、Kerberos 或 RPC 流量）；當失敗時，請求被拒絕，錯誤“被策略模組拒絕”和狀態程式碼“RPC 伺服器不可用”。

這僅適用於“Kerberos 身份驗證”證書；所有其他證書都可以通過 CES 成功註冊，包括“域控制器身份驗證”和“目錄電子郵件複製”。

我還針對實際上可以與 CA 對話的 DC 進行了測試：如果從 DC 到 CA 的流量被阻止，從而強制請求使用 CES，而不是相反，則請求成功；如果從 CA 到 DC 的流量被阻止，則請求失敗。

根據文件，您所面臨的行為是預期的，是設計的，無法關閉。Kerberos Authentication需要從 CA 到 DC 的 RPC 連接。您有哪些選擇：

1. 啟用 CA 和域控制器之間的 RPC 通信。
2. 使用Domain Contoller Authentication證書模板而不是Kerberos Authentication模板。Domain Contoller Authentication模板不需要 RPC 連接回 DC。

事實上，我不記得所有的細節和對你的讚美，你做了很好的調查並指出了一個失敗的 RPC 回調，這確實減少了可能的原因。關於為什麼會發生這種情況的完整詳細資訊如下。

---

TL;博士

第1部分

首先，關於證書模板：兩者，Domain Controller Authentication和模板用於在證書/智能卡登錄期間Kerberos Authentication提供對LDAP S （LDAP over TLS）和相互認證的支持。

兩者之間的區別在於主題的建構方式或其中包含的內容。Domain Controller Authentication僅在 SAN 擴展中包含域控制器的 FQDN。Kerberos Authentication添加了另外兩個名稱：FDQN 和 NetBIOS 域名。此外，Kerberos Authentication添加了一個KDC AuthenticationEKU。預設模板配置定義在$$ MS-CRTD $$，附錄A。為了更清楚：

• Domain Controller Authentication主題名稱具有 134217728 (0x8000000) 標誌組合，僅轉換為標誌：CT_FLAG_SUBJECT_ALT_REQUIRE_DNS
• Kerberos Authentication主題名稱具有 138412032 (0x8400000) 標誌組合，可轉換為兩個標誌：CT_FLAG_SUBJECT_ALT_REQUIRE_DNS和CT_FLAG_SUBJECT_ALT_REQUIRE_DOMAIN_DNS.

主題名稱標誌儲存在msPKI-Certificate-Name-Flag屬性 ($$ MS-CRTD $$ §2.28).

您問題中的問題是由 SAN 中要求包含域 FQDN 和 NetBIOS 名稱引起的。Kerberos Authenticationtemplate 是唯一使用CT_FLAG_SUBJECT_ALT_REQUIRE_DOMAIN_DNS標誌的預設模板。

第2部分

Windows CA 使用$$ MS-WCCE $$處理請求和頒發證書的協議規範。該協議完整地規定了 Windows CA 的客戶端行為和一小部分互動和行為。$$ MS-WCCE $$§3.2.2.1.3為作為域控制器的客戶端定義了一種特殊行為，並通過在其名稱前加上“\”來準備其名稱以準備 RPC 連接。

第 3 部分

Windows CA 處理CT_FLAG_SUBJECT_ALT_REQUIRE_DOMAIN_DNS中指定的$$ MS-WCCE $$ §3.2.2.6.2.1.4.5.9.

如果CT_FLAG_SUBJECT_ALT_REQUIRE_DOMAIN_DNS設置了標誌，CA 應該：

• CA 應該使用 LsarOpenPolicy 方法檢索資訊策略的句柄（$$ MS-LSAD $$第 3.1.4.4.2 節），SystemName參數集作為dNSHostName請求者電腦對象的屬性，所有欄位ObjectAttributes設置為NULL，DesiredAccess參數設置為POLICY_VIEW_LOCAL_INFORMATION。
• LsarQueryInformationPolicyCA 應該使用以下方法獲取請求者的電腦 DNS 域資訊($$ MS-LSAD $$第 3.1.4.4.4 節），PolicyHandle參數設置為上一步中獲得的值，InformationClass 參數設置為PolicyDnsDomainInformation。
• CA 必須將上一步返回的 DNS 域資訊中的Nameand欄位的值添加到已頒發證書的主題備用名稱擴展中。DNSDomainName

如您所見，LsarOpenPolicycall 確實是 RPC 呼叫，並在成功時返回 RPC 連接句柄。在您的情況下，此呼叫失敗並且 CA 無法呼叫LsarQueryInformationPolicy（這又是 RPC 呼叫！）以獲取插入證書所需的名稱。

底線

可能希望在模板中關閉域 FQDN 和域 NetBIOS 名稱Kerberos Authentication，但我不建議這樣做。也不嘗試將KDC AuthenticationEKU 添加到Domain Controller Authentication，因為首先嚴格依賴於域 FQDN 和 NetBIO 的存在，這會導致您的環境出現問題。

引用自：https://serverfault.com/questions/1005993