憑證需求和列舉

• 適用於:

  ✅ Windows 11, ✅ Windows 10, ✅ Windows Server 2022, ✅ Windows Server 2019, ✅ Windows Server 2016

本主題適用於 IT 專業人員和智慧卡開發人員，說明如何管理憑證並用於智慧卡登入。

插入智慧卡時，會執行下列步驟。

注意

除非另有提及，否則所有作業都會以無訊息方式執行， (CRYPT_SILENT 傳遞至 CryptAcquireContext) 。

1. 智慧卡資源管理員資料庫會搜尋智慧卡的密碼編譯服務提供者 (CSP) 。

2. 限定的容器名稱是使用智慧卡卡片讀取器名稱所建構，並會傳遞給 CSP。 格式為 \\.<Reader name>\

3. 呼叫 CryptAcquireContext 以擷取預設容器的內容。 如果發生失敗，智慧卡將無法用於智慧卡登入。

4. 使用 PP_CONTAINER 參數搭配 CryptGetProvParam 來擷取容器的名稱。

5. 使用步驟 3 中取得的內容，會查詢 CSP 以取得 PP_USER_CERTSTORE 參數。 如需詳細資訊，請參閱 智慧卡架構。 如果作業成功，則會傳回證書存儲的名稱，而程式流程會跳至步驟 8。

6. 如果步驟 5 中的作業失敗，則會查詢步驟 3 中的預設容器內容，以取得AT_KEYEXCHANGE鍵。

7. 然後使用 KP_CERTIFICATE，從密鑰內容查詢憑證。 憑證會新增至記憶體內部證書存儲。

8. 針對步驟 5 或步驟 7 中證書存儲中的每個憑證，會執行下列檢查：

   1. 憑證必須是有效的，根據計算機系統時鐘 (未過期或有效，且未來日期)
   2. 憑證不得位於容器的AT_SIGNATURE部分
   3. 憑證必須具有有效的用戶主體名稱 (UPN)
   4. 憑證必須具有數位簽名金鑰使用方式
   5. 憑證必須有智慧卡登入 EKU

   符合這些需求的任何憑證都會顯示給具有憑證 UPN (或電子郵件位址或主旨的使用者，視憑證擴充功能是否存在而定)

9. 然後，此程式會選擇憑證，並輸入 PIN

10. LogonUI.exe 封裝資訊，並將其傳送至 Lsass.exe 以處理登入嘗試

11. 如果成功，則 LogonUI.exe 會關閉。 這會導致發行步驟 3 中取得的內容

Windows 中的智慧卡登入流程

驗證期間的大部分問題都會因為會話行為變更而發生。 發生變更時，本地安全機構 (LSA) 不會重新取得會話內容;而是依賴密碼編譯服務提供者來處理會話變更。

憑證的 (SAN) 欄位中 subjectAltName 未包含 UPN 的用戶端憑證可以啟用登入，其支援更廣泛的憑證，並支援相同卡片上的多個登入憑證。

默認會啟用對相同卡片上多個憑證的支援。 新的憑證類型必須透過 群組原則 啟用。

如果您啟用 [ 允許簽章密鑰對登入 認證提供者有效] 原則，登入畫面上會列出智慧卡上具有僅限簽章密鑰的任何憑證。 這可讓用戶選取其登入體驗。 如果停用或未設定原則，登入畫面上就不會列出智慧卡簽章密鑰型憑證。

下圖說明智慧卡登入在支援的 Windows 版本中的運作方式。

智慧卡登入流程

以下是智慧卡登入期間所執行的步驟：

1. Winlogon 要求登入 UI 認證資訊

2. 智慧卡資源管理員會以異步方式啟動，而智慧卡認證提供者會執行下列動作：

   1. 取得認證資訊 (已知認證清單，或如果沒有認證存在，Windows 偵測到的智慧卡卡片讀取器資訊)
   2. 使用 WinSCard API) 取得智慧卡卡片讀取器 (清單，以及每一個智慧卡插入的清單
   3. 列舉每張卡片，以確認 群組原則 所控制的登入憑證存在。 如果憑證存在，智慧卡認證提供者會將它複製到計算機或終端機上的暫時、安全快取中

   注意

   智慧卡快取專案是針對具有主體名稱或具有主體密鑰標識碼的憑證所建立。 如果憑證具有主體名稱，則會使用以主體名稱和憑證簽發者為基礎的索引來儲存。 如果使用另一個具有相同主體名稱和憑證簽發者的憑證，它會取代現有的快取專案。 此行為的變更可讓您在憑證沒有主體名稱時，使用以主體密鑰標識碼和憑證簽發者為基礎的索引來建立快取。 如果另一個憑證具有相同的主體密鑰標識碼和憑證簽發者，則會取代快取專案。 當憑證沒有主體名稱或主體密鑰標識碼時，就不會建立快取的專案。

   1. 通知登入UI有新的認證

3. 登入UI會向智慧卡認證提供者要求新的認證。 作為回應，智慧卡認證提供者會將每個登入憑證提供給登入UI，並顯示對應的登入磚。 用戶選取智慧卡登入憑證磚，而 Windows 會顯示 PIN 對話方塊

4. 使用者輸入 PIN，然後按 ENTER 鍵。 智慧卡認證提供者會加密 PIN

5. 位於LogonUI系統中的認證提供者會收集 PIN。 在智慧卡認證提供者中封裝認證時，數據會封裝在KERB_CERTIFICATE_LOGON結構中。 KERB_CERTIFICATE_LOGON結構的主要內容是智慧卡 PIN、CSP 資料 (，例如讀取器名稱和容器名稱) 、用戶名稱和功能變數名稱。 如果登入網域不在相同的樹系中，則需要使用者名稱，因為它可讓憑證對應至多個用戶帳戶

6. 認證提供者會將數據包裝 (，例如加密的 PIN、容器名稱、讀取器名稱和卡片密鑰規格) ，並將它傳送回 LogonUI

7. Winlogon 會以 LSALogonUser 中的使用者資訊，將數據從 LogonUI 呈現至 LSA

8. LSA 會 (Kerberos SSP) 呼叫 Kerberos 驗證套件，以建立 Kerberos 驗證服務要求 (KRB_AS_REQ) ，其中包含 RFC 4556： 適用於 Kerberos (PKINIT) ) 中初始驗證的公鑰密碼 編譯中所指定的預先驗證器 (。

   如果驗證是使用使用數位簽名的憑證來執行，則預先驗證數據會包含使用者的公用憑證，以及使用對應私鑰進行數位簽署的憑證。
   如果驗證是使用使用金鑰加密的憑證來執行，則預先驗證數據會包含使用者的公用憑證，以及使用對應私鑰加密的憑證。

9. 若要根據 RFC 4556) 以數位方式 (簽署要求，會呼叫對應的 CSP 進行私鑰作業。 由於此案例中的私鑰會儲存在智慧卡中，因此會呼叫智慧卡子系統，並完成必要的作業。 結果會傳回給 Kerberos 安全性支援提供者 (SSP) 。

10. Kerberos SSP 會針對每個 RFC 4556) 的票證授與票證 (TGT) (傳送驗證要求， (域控制器上執行的 KDC) 服務。

11. KDC 會在 Active Directory 網域服務 (AD DS) 中尋找使用者的帳戶物件，如客戶端憑證需求和對應中所述，並使用使用者的憑證來驗證簽章。

12. KDC 會驗證使用者的憑證 (時間、路徑和撤銷狀態) ，以確保憑證來自信任的來源。 KDC 會使用 CryptoAPI 來建置從用戶憑證到根證書頒發機構單位的認證路徑， (CA) 位於域控制器根存放區中的憑證。 KDC 接著會使用 CryptoAPI，在預先驗證數據欄位中包含的已簽署驗證器上驗證數位簽名。 域控制器會驗證簽章，並使用用戶憑證中的公鑰來證明要求源自對應至公鑰的私鑰擁有者。 KDC 也會驗證簽發者是否受到信任，並出現在 NTAUTH 證書存儲中。

13. KDC 服務會從 AD DS 擷取使用者帳戶資訊。 KDC 會建構 TGT，這是以它從 AD DS 擷取的使用者帳戶資訊為基礎。 TGT 的授權數據欄位包含使用者的安全識別碼 (SID) 、使用者所屬的通用和全域網域群組的 SID，以及在多域環境中 () 用戶所屬任何通用群組的 SID。

14. 域控制器會將 TGT 傳回至客戶端，作為KRB_AS_REP回應的一部分。

    注意

    KRB_AS_REP封包包含：

    • PAC) (許可權屬性憑證
    • 使用者的 SID
    • 使用者為其成員之任何群組的 SID
    • TGS (票證授與服務的要求)
    • 預先驗證數據

    TGT 會使用 KDC 的主要金鑰進行加密，而且會話金鑰會使用暫存金鑰加密。 此暫存金鑰是根據 RFC 4556 衍生而來。 使用 CryptoAPI 時，暫存密鑰會解密。 在解密過程中，如果私鑰位於智慧卡上，則會使用指定的 CSP 來呼叫智慧卡子系統，以擷取對應至使用者公鑰的憑證。 (憑證的程式設計呼叫包括 CryptAcquireContext、CryptSetProvParam 與 PIN、CryptgetUserKey 和 CryptGetKeyParam.) 取得暫存密鑰之後，Kerberos SSP 會解密會話密鑰。

15. 用戶端會 (時間、路徑和撤銷狀態) 驗證來自 KDC 的回復。 它會先從 KDC 的憑證路徑建構成受信任的根 CA 來驗證 KDC 的簽章，然後使用 KDC 的公鑰來驗證回復簽章。

16. 現在已取得 TGT，用戶端會取得服務票證，用來登入本機計算機。

17. 成功之後，LSA 會儲存票證，並將成功訊息傳回給 LSALogonUser。 發出此成功訊息之後，會選取並設定裝置的使用者配置檔、具現化 群組原則 重新整理，並執行其他動作。

18. 載入使用者配置檔之後，證書傳播服務 (CertPropSvc) 偵測到此事件、從智慧卡讀取憑證 (包括跟證書) ，然後將它們填入使用者的證書存儲 (MYSTORE)

19. CSP 與智慧卡資源管理員通訊會在 LRPC 通道上進行。

20. 成功驗證時，憑證會由憑證傳播服務 (CertPropSvc) 以異步方式傳播至使用者的存放區。

21. 拿掉卡片時，會移除暫存安全快取存放區中的憑證。 憑證已無法再登入，但會保留在使用者的證書存儲中。

注意

在本機安全性帳戶資料庫或 AD DS 內建立使用者帳戶或組帳戶時，會為每個使用者或群組建立 SID。 即使使用者或組帳戶已重新命名，SID 也不會變更。

如需 Kerberos 通訊協定的詳細資訊，請參閱 Microsoft Kerberos。

根據預設，KDC 會確認客戶端的憑證包含智慧卡客戶端驗證 EKU szOID_KP_SMARTCARD_LOGON。 不過，如果啟用，[允許沒有擴充密鑰使用方式憑證的憑證] 屬性 群組原則 設定可讓 KDC 不需要 SC-LOGON EKU。 以公鑰為基礎的帳戶對應不需要 SC-LOGON EKU。

KDC 憑證

Active Directory 憑證服務提供三種類型的證書範本：

• 域控制器
• 域控制器驗證
• Kerberos 驗證

視域控制器的設定而定，其中一種憑證會當做AS_REP封包的一部分傳送。

客戶端憑證需求和對應

憑證需求會依 Windows 作業系統的版本列出。 憑證對應描述如何將憑證中的資訊對應至用戶帳戶。

憑證需求

元件	需求
CRL 發佈點位置	不需要
金鑰使用方式	數字簽名
基本條件約束	不需要
擴充金鑰使用 (EKU)	不需要智慧卡登入物件標識碼。 注意 如果 EKU 存在，它必須包含智慧卡登入 EKU。 沒有 EKU 的憑證可用於登入。
主體別名	智慧卡登入不需要電子郵件標識碼。
主體	不需要
金鑰交換 (AT_KEYEXCHANGE 欄位)	如果已啟用 群組原則 設定，智慧卡登入憑證就不需要。 (預設不會啟用 群組原則 設定。)
Crl	不需要
Upn	不需要
附註	您可以讓智慧卡認證提供者看到任何憑證。

用戶端憑證對應

憑證對應是以憑證的 subjectAltName (SAN) 欄位中所包含的 UPN 為基礎。 也支援不包含 SAN 欄位中資訊的客戶端憑證。

SSL/TLS 可以對應沒有 SAN 的憑證，而對應是使用客戶端帳戶上的 AltSecID 屬性來完成。 SSL/TLS 用戶端驗證所使用的 X509 AltSecID 格式為 “X509：。 <Issuer Name><Subject Name 和 <Issuer Name><Subject Name> 取自用戶端憑證，並以 『\r』 和 『\n』 取代為 『，』。

證書吊銷清單發佈點

[主體別名] 欄位中的 UPN

[主旨] 和 [簽發者] 字段

除了其他六種對應方法之外，KDC 也支援此帳戶對應。 下圖示範 KDC 所使用的用戶帳戶對應邏輯流程。

登入的憑證處理高階流程

系統會剖析憑證物件，以尋找要執行使用者帳戶對應的內容。

• 當憑證提供用戶名稱時，會使用使用者名稱來尋找帳戶物件。 這項作業最快，因為會進行字串比對
• 只提供憑證物件時，會執行多個作業來找出用戶名稱，以將使用者名稱對應至帳戶物件
• 當沒有任何網域資訊可供驗證時，預設會使用本機網域。 如果要使用任何其他網域進行查閱，則應提供功能變數名稱提示來執行對應和系結

無法根據泛型屬性進行對應，因為沒有可從憑證擷取屬性的泛型 API。 目前，找到帳戶的第一個方法會成功停止搜尋。 但是當用戶端未透過對應提示提供用戶端名稱時，如果兩種方法將相同的憑證對應至不同的用戶帳戶，就會發生組態錯誤。

下圖說明藉由檢視憑證中的各種項目，對應用戶帳戶以登入目錄的程式。

憑證處理邏輯

NT_AUTH原則最適合在 CertVerifyCertificateChainPolicy 函式的 CERT_CHAIN_POLICY_NT_AUTH 參數一節中說明。 如需詳細資訊，請參閱 CertVerifyCertificateChainPolicy。

單一使用者的智慧卡登入，其中一個憑證可登入多個帳戶

單一用戶憑證可以對應至多個帳戶。 例如，使用者可能能夠登入用戶帳戶，也可以以網域系統管理員身分登入。 對應是根據來自用戶端帳戶的屬性，使用建構的 AltSecID 來完成。 如需如何評估此對應的資訊，請 參閱客戶端憑證需求和對應。

注意

因為每個帳戶有不同的使用者名稱，建議您啟用 [允許使用者名稱提示 群組原則 設定 (X509HintsNeeded 登錄機碼) ，以提供可讓使用者輸入其使用者名稱和網域資訊以登入的選擇性字段。

根據憑證中可用的資訊，登入條件如下：

1. 如果憑證中沒有UPN：
   1. 如果具有一個憑證的單一使用者需要登入不同的帳戶，登入可能會發生在本機樹系或另一個樹系中
   2. 例如，如果對應不是唯一的 (，則必須提供提示，例如，如果多個用戶對應至相同的憑證)
2. 如果憑證中有 UPN：
   1. 憑證無法對應至相同樹系中的多個使用者
   2. 憑證可以對應至不同樹系中的多個使用者。 若要讓使用者登入其他樹系，必須提供 X509 提示給使用者

多個用戶的智慧卡登入單一帳戶

一組使用者可能會登入單一帳戶 (例如系統管理員帳戶) 。 針對該帳戶，用戶憑證會進行對應，以便啟用登入。

數個不同的憑證可以對應至單一帳戶。 若要讓此作業正常運作，憑證不能有UPN。

例如，如果 Certificate1 具有 CN=CNName1、Certificate2 具有 CN=User1，而 Certificate3 具有 CN=User2，則可以使用 Active Directory 使用者和電腦 名稱對應，將這些憑證的 AltSecID 對應至單一帳戶。

跨樹系的智慧卡登入

若要讓帳戶對應跨樹系運作，特別是在憑證上沒有足夠的資訊可用時，使用者可能會以使用者名稱的形式輸入提示，例如 domain\user 或完整 UPN，例如 user@contoso.com。

注意

若要在智慧卡登入期間顯示提示字段，必須在用戶端上啟用 [允許使用者名稱提示 群組原則 設定 (X509HintsNeeded 登錄機碼) 。

PKINIT 的 OCSP 支援

RFC 2560 中定義的在線憑證狀態通訊協定 (OCSP) ，可讓應用程式及時取得有關憑證撤銷狀態的資訊。 因為 OCSP 回應很小且系結良好，所以受限制的用戶端可能會想要使用 OCSP 來檢查 KDC 上 Kerberos 憑證的有效性、避免傳輸大型 CRL，以及在受限制的網路上儲存頻寬。 如需CRL登錄機碼的相關信息，請參閱智慧卡 群組原則和登錄設定。

Windows 中的 KDC 會嘗試取得 OCSP 回應，並在可用時使用它們。 無法停用此行為。 OCSP 的 CryptoAPI 會快取 OCSP 回應和回應的狀態。 KDC 僅支持簽署者憑證的 OCSP 回應。

Windows 用戶端電腦嘗試要求 OCSP 回應，並在可用時將其用於回復中。 無法停用此行為。

搭配網域登入使用的智慧卡跟證書需求

若要讓登入在智慧卡型網域中運作，智慧卡憑證必須符合下列條件：

• 智慧卡上的 KDC 跟證書在其憑證中必須列出 HTTP CRL 發佈點
• 智慧卡登入憑證的憑證中必須列出 HTTP CRL 發佈點
• 如果適用，CRL 發佈點必須有有效的 CRL 發佈和差異 CRL，即使 CRL 發佈點是空的
• 智慧卡憑證必須包含下列其中一項：
  • 在辨別名稱中包含 DNS 功能變數名稱名稱名稱中包含 DNS 功能變數名稱名稱中包含 D 如果沒有，則適當網域的解析會失敗，因此使用智慧卡的遠端桌面服務和網域登入會失敗
  • 功能變數名稱解析為實際網域的UPN。 例如，如果功能變數名稱是 Engineering.Corp.Contoso，則 UPN 是 username@engineering.corp.contoso.com。 如果省略功能變數名稱的任何部分，Kerberos 用戶端就找不到適當的網域

若要允許智慧卡登入這些版本中的網域，請執行下列動作：

1. 在 CA 上啟用 HTTP CRL 發佈點
2. 重新啟動 CA
3. 重新發出 KDC 憑證
4. 發出或重新發出智慧卡登入憑證
5. 將更新的跟證書傳播至您想要用於網域登入的智慧卡

因應措施是啟用 [允許使用者名稱提示 群組原則 設定 (X509HintsNeeded 登錄機碼) ，這可讓使用者在網域登入的認證使用者介面中提供提示。

如果客戶端電腦未加入網域，或是已加入不同的網域，用戶端電腦只能藉由查看憑證上的辨別名稱而非 UPN 來解析伺服器網域。 若要讓此案例能夠運作，憑證需要完整的主體，包括 DC=<DomainControllerName>，才能解析域名。

若要在目前加入網域的智慧卡上部署跟證書，您可以使用下列命令：

certutil.exe -scroots update

如需命令行工具此選項的詳細資訊，請參閱 -SCRoots。