証明書の要件と列挙

[アーティクル]
01/16/2024
適用対象:

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

IT プロフェッショナルおよびスマートカード開発者向けのこのトピックでは、スマートカードサインインに証明書を管理して使用する方法について説明します。

スマートカードが挿入されると、次の手順が実行されます。

注

特に説明がない限り、すべての操作はサイレントで実行されます (CRYPT_SILENTは CryptAcquireContext に渡されます)。

スマートカードリソースマネージャーデータベースは、スマートカードの暗号化サービスプロバイダー (CSP) を検索します。
修飾コンテナー名は、スマートカードリーダー名を使用して構築され、CSP に渡されます。形式は \\.<Reader name>\
既定のコンテナーにコンテキストを取得するために、CryptAcquireContext が呼び出されます。エラーが発生した場合、スマートカードはスマートカードサインインでは使用できません。
コンテナーの名前は、CryptGetProvParam で PP_CONTAINER パラメーターを使用して取得されます。
手順 3 で取得したコンテキストを使用して、CSP は PP_USER_CERTSTORE パラメーターに対してクエリを実行します。詳細については、「スマートカードアーキテクチャ」を参照してください。操作が成功すると、証明書ストアの名前が返され、プログラムフローは手順 8 にスキップされます。
手順 5 の操作が失敗した場合、手順 3 の既定のコンテナーコンテキストがAT_KEYEXCHANGE キーに対してクエリされます。
その後、証明書は、KP_CERTIFICATEを使用してキーコンテキストから照会されます。証明書は、メモリ内の証明書ストアに追加されます。
手順 5 または手順 7 の証明書ストア内の証明書ごとに、次のチェックが実行されます。
1. 証明書は、コンピューターのシステムクロックに基づいて有効である必要があります (有効期限が切れていないか、将来の日付で有効)。
2. 証明書がコンテナーのAT_SIGNATURE部分に含まれていない
3. 証明書には有効なユーザープリンシパル名 (UPN) が必要です
4. 証明書にはデジタル署名キーの使用法が必要です
5. 証明書にはスマートカードログオン EKU が必要です
これらの要件を満たす証明書は、証明書の UPN (または証明書拡張機能の存在に応じて電子メールアドレスまたは件名) を持つユーザーに表示されます。
その後、プロセスによって証明書が選択され、PIN が入力されます
LogonUI.exe 情報をパッケージ化し、Lsass.exe に送信してサインイン試行を処理します
成功した場合は、 LogonUI.exe を閉じます。これにより、手順 3 で取得したコンテキストが解放されます

認証中のほとんどの問題は、セッションの動作の変更が原因で発生します。変更が発生した場合、ローカルセキュリティ機関 (LSA) はセッションコンテキストを再取得しません。これは、代わりに暗号化サービスプロバイダーに依存してセッションの変更を処理します。

証明書の [(SAN)] フィールドに subjectAltName UPN が含まれていないクライアント証明書は、さまざまな証明書をサポートし、同じカードで複数のサインイン証明書をサポートするサインインに対して有効にすることができます。

同じカードでの複数の証明書のサポートは、既定で有効になっています。新しい証明書の種類は、グループポリシーを使用して有効にする必要があります。

[ログオン資格情報プロバイダーの有効な署名キーを許可する] ポリシーを有効にすると、署名専用キーを持つスマートカードで使用できる証明書がサインイン画面に一覧表示されます。これにより、ユーザーはサインインエクスペリエンスを選択できます。ポリシーが無効になっているか、構成されていない場合、スマートカード署名キーベースの証明書はサインイン画面に一覧表示されません。

次の図は、サポートされているバージョンの Windows でスマートカードサインインがどのように機能するかを示しています。

スマートカードサインインフロー。

スマートカードサインイン中に実行される手順を次に示します。

Winlogon がサインイン UI 資格情報を要求する
非同期的に、スマートカードリソースマネージャーが起動し、スマートカード資格情報プロバイダーによって次の処理が実行されます。
1. 資格情報 (既知の資格情報の一覧、または資格情報が存在しない場合は、Windows によって検出されたスマートカードリーダー情報) を取得します。
2. (WinSCard API を使用して) スマートカードリーダーの一覧と、それらのそれぞれに挿入されたスマートカードの一覧を取得します
3. 各カードを列挙して、グループポリシーによって制御されるサインイン証明書が存在することを確認します。証明書が存在する場合、スマートカード資格情報プロバイダーは、コンピューターまたはターミナル上の一時的なセキュリティで保護されたキャッシュにコピーします
注

スマートカードキャッシュエントリは、サブジェクト名またはサブジェクトキー識別子を持つ証明書に対して作成されます。証明書にサブジェクト名がある場合は、サブジェクト名と証明書発行者に基づくインデックスが格納されます。同じサブジェクト名と証明書発行者を持つ別の証明書を使用すると、既存のキャッシュされたエントリが置き換えられます。この動作の変更により、証明書にサブジェクト名がない場合の条件が許可され、サブジェクトキー識別子と証明書発行者に基づくインデックスを使用してキャッシュが作成されます。別の証明書にサブジェクトキー識別子と証明書発行者が同じ場合、キャッシュエントリが置き換えられます。証明書にサブジェクト名とサブジェクトキー識別子がない場合、キャッシュされたエントリは作成されません。
1. サインイン UI に新しい資格情報があることを通知します
サインイン UI は、スマートカード資格情報プロバイダーから新しい資格情報を要求します。応答として、スマートカード資格情報プロバイダーはサインイン UI に各サインイン証明書を提供し、対応するサインインタイルが表示されます。ユーザーがスマートカードベースのサインイン証明書タイルを選択すると、Windows に [PIN] ダイアログボックスが表示されます
ユーザーが PIN を入力し、Enter キーを押します。スマートカード資格情報プロバイダーは PIN を暗号化します
LogonUI システムに存在する資格情報プロバイダーは、PIN を収集します。スマートカード資格情報プロバイダーでの資格情報のパッケージ化の一環として、データはKERB_CERTIFICATE_LOGON構造でパッケージ化されます。 KERB_CERTIFICATE_LOGON構造体のメインの内容は、スマートカード PIN、CSP データ (リーダー名やコンテナー名など)、ユーザー名、ドメイン名です。サインインドメインが同じフォレスト内にない場合は、証明書を複数のユーザーアカウントにマップできるため、ユーザー名が必要です
資格情報プロバイダーは、データ (暗号化された PIN、コンテナー名、リーダー名、カードキー仕様など) をラップし、LogonUI に送信します
Winlogon は、LSALogonUser のユーザー情報を使用して LogonUI から LSA にデータを表示します
LSA は Kerberos 認証パッケージ (Kerberos SSP) を呼び出して、(RFC 4556 で指定されている) 事前認証子を含む Kerberos 認証サービス要求 (KRB_AS_REQ) を作成します (RFC 4556: Kerberos での初期認証の公開キー暗号化 (PKINIT))。

デジタル署名を使用する証明書を使用して認証を実行する場合、事前認証データは、ユーザーの公開証明書と、対応する秘密キーでデジタル署名された証明書で構成されます。
キー暗号化を使用する証明書を使用して認証を実行する場合、事前認証データは、ユーザーの公開証明書と、対応する秘密キーで暗号化された証明書で構成されます。
(RFC 4556 に従って) 要求にデジタル署名するには、秘密キー操作の対応する CSP に対して呼び出しが行われます。この場合、秘密キーはスマートカードに格納されるため、スマートカードサブシステムが呼び出され、必要な操作が完了します。結果は Kerberos セキュリティサポートプロバイダー (SSP) に返送されます。
Kerberos SSP は、チケット許可チケット (TGT) (RFC 4556 ごと) の認証要求を、ドメインコントローラーで実行されるキー配布センター (KDC) サービスに送信します。
KDC は、「クライアント証明書の要件とマッピング」で詳しく説明されているように、Active Directory Domain Services (AD DS) でユーザーのアカウントオブジェクトを検索し、ユーザーの証明書を使用して署名を確認します。
KDC は、ユーザーの証明書 (時間、パス、失効状態) を検証して、証明書が信頼できるソースからのものであることを確認します。 KDC は CryptoAPI を使用して、ユーザーの証明書から、ドメインコントローラーのルートストアに存在するルート証明機関 (CA) 証明書への認定パスを構築します。次に、KDC は CryptoAPI を使用して、事前認証データフィールドに含まれていた署名付き認証子のデジタル署名を検証します。ドメインコントローラーは署名を検証し、ユーザーの証明書の公開キーを使用して、要求が公開キーに対応する秘密キーの所有者から送信されたことを証明します。 KDC は、発行者が信頼されていることも確認し、NTAUTH 証明書ストアに表示されます。
KDC サービスは、AD DS からユーザーアカウント情報を取得します。 KDC は、AD DS から取得するユーザーアカウント情報に基づいて TGT を構築します。 TGT の承認データフィールドには、ユーザーのセキュリティ識別子 (SID)、ユーザーが属するユニバーサルドメイングループとグローバルドメイングループの SID、および (マルチドメイン環境では) ユーザーがメンバーであるユニバーサルグループの SID が含まれます。
ドメインコントローラーは、KRB_AS_REP応答の一部として TGT をクライアントに返します。
注

KRB_AS_REP パケットは次で構成されます。
- 特権属性証明書 (PAC)
- ユーザーの SID
- ユーザーがメンバーである任意のグループの SID
- チケット付与サービス (TGS) の要求
- 事前認証データ
TGT は KDC のマスターキーで暗号化され、セッションキーは一時キーで暗号化されます。この一時キーは RFC 4556 に基づいて派生します。 CryptoAPI を使用すると、一時キーが復号化されます。暗号化解除プロセスの一環として、秘密キーがスマートカードにある場合は、指定した CSP を使用してスマートカードサブシステムに対して呼び出しを行い、ユーザーの公開キーに対応する証明書を抽出します。 (証明書のプログラムによる呼び出しには、CryptAcquireContext、PIN を使用した CryptSetProvParam、CryptgetUserKey、CryptGetKeyParam が含まれます)。一時キーが取得されると、Kerberos SSP によってセッションキーが復号化されます。
クライアントは、KDC からの応答 (時刻、パス、失効状態) を検証します。最初に KDC の証明書から信頼されたルート CA への認定パスを構築することによって KDC の署名を検証し、次に KDC の公開キーを使用して応答署名を確認します。
TGT が取得されたので、クライアントは、ローカルコンピューターへのサインインに使用されるサービスチケットを取得します。
成功すると、LSA はチケットを格納し、LSALogonUser に成功メッセージを返します。この成功メッセージが発行されると、デバイスのユーザープロファイルが選択されて設定され、グループポリシー更新がインスタンス化され、その他のアクションが実行されます。
ユーザープロファイルが読み込まれた後、Certification Propagation Service (CertPropSvc) によってこのイベントが検出され、スマートカード (ルート証明書を含む) から証明書が読み取られ、ユーザーの証明書ストア (MYSTORE) に設定されます。
CSP からスマートカードリソースマネージャーへの通信は、LRPC チャネルで行われます。
認証が成功すると、証明書は証明書伝達サービス (CertPropSvc) によって非同期的にユーザーのストアに伝達されます。
カードが削除されると、一時的なセキュリティで保護されたキャッシュストア内の証明書が削除されます。 [証明書] はサインインに使用できなくなりましたが、ユーザーの証明書ストアに残ります。

注

SID は、ユーザーアカウントまたはグループアカウントがローカルセキュリティアカウントデータベース内または AD DS 内で作成された時点で、ユーザーまたはグループごとに作成されます。ユーザーまたはグループアカウントの名前が変更されても、SID は変更されません。

Kerberos プロトコルの詳細については、「 Microsoft Kerberos」を参照してください。

既定では、KDC は、クライアントの証明書にスマートカードクライアント認証 EKU szOID_KP_SMARTCARD_LOGONが含まれていることを確認します。ただし、有効にした場合、[拡張キー使用法証明書属性を持たない証明書を許可する] グループポリシー設定では、KDC で SC-LOGON EKU を必要としません。 SC-LOGON EKU は、公開キーに基づくアカウントマッピングには必要ありません。

KDC 証明書

Active Directory 証明書サービスには、次の 3 種類の証明書テンプレートが用意されています。

ドメインコントローラー
ドメインコントローラー認証
Kerberos 認証

ドメインコントローラーの構成に応じて、これらの種類の証明書のいずれかがAS_REP パケットの一部として送信されます。

クライアント証明書の要件とマッピング

証明書の要件は、Windows オペレーティングシステムのバージョン別に一覧表示されます。証明書マッピングは、証明書の情報がユーザーアカウントにどのようにマップされるかを示します。

証明書の要件

コンポーネント	要件
CRL 配布ポイントの場所	任意
主な使用法	デジタル署名
基本的な制約	任意
拡張キー使用法 (EKU)	スマートカードサインインオブジェクト識別子は必要ありません。メモEKU が存在する場合は、スマートカードサインイン EKU が含まれている必要があります。 EKU のない証明書は、サインインに使用できます。
サブジェクトの別名	スマートカードサインインには電子メール ID は必要ありません。
サブジェクト	任意
キー交換 (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

[サブジェクトの別名] フィールドの UPN。

[件名] フィールドと [発行者] フィールド

[件名] フィールドと [発行者] フィールド。

このアカウントマッピングは、他の 6 つのマッピングメソッドに加えて、KDC でサポートされています。次の図は、KDC によって使用されるユーザーアカウントマッピングロジックのフローを示しています。

サインインの証明書処理の概要フロー。

証明書オブジェクトが解析され、ユーザーアカウントマッピングを実行するコンテンツが検索されます。

ユーザー名に証明書を指定すると、アカウントオブジェクトの検索にユーザー名が使用されます。文字列の一致が発生するため、この操作は最も高速です
証明書オブジェクトのみを指定すると、ユーザー名をアカウントオブジェクトにマップするユーザー名を特定するための複数の操作が実行されます。
認証に使用できるドメイン情報がない場合、ローカルドメインは既定で使用されます。他のドメインを参照に使用する場合は、マッピングとバインドを実行するためにドメイン名ヒントを指定する必要があります

証明書から属性を取得する汎用 API がないため、ジェネリック属性に基づくマッピングは不可能です。現在、アカウントを検索する最初のメソッドは、検索を正常に停止します。ただし、クライアントがマッピングヒントを介してクライアント名を指定しない場合、2 つの方法で同じ証明書を別のユーザーアカウントにマップすると、構成エラーが発生します。

次の図は、証明書内のさまざまなエントリを表示して、ディレクトリにサインインするためのユーザーアカウントをマッピングするプロセスを示しています。

証明書処理ロジック

証明書処理ロジック。

NT_AUTHポリシーは、CertVerifyCertificateChainPolicy 関数の CERT_CHAIN_POLICY_NT_AUTH パラメーターセクションで最もよく説明されています。詳細については、「 CertVerifyCertificateChainPolicy」を参照してください。

1 つのユーザー証明書を複数のアカウントにマップできます。たとえば、ユーザーがユーザーアカウントにサインインしたり、ドメイン管理者としてサインインしたりできる場合があります。マッピングは、クライアントアカウントの属性に基づいて構築された AltSecID を使用して実行されます。このマッピングの評価方法については、「クライアント証明書の要件とマッピング」を参照してください。

注

各アカウントには異なるユーザー名があるため、[ユーザー名ヒントのグループポリシーを許可する] 設定 (X509HintsNeeded レジストリキー) を有効にして、ユーザーがサインインするユーザー名とドメイン情報を入力できるオプションのフィールドを指定することをお勧めします。

証明書で使用できる情報に基づいて、サインイン条件は次のとおりです。

証明書に UPN が存在しない場合:
1. 1 つの証明書を持つ 1 人のユーザーが別のアカウントにサインインする必要がある場合、サインインはローカルフォレストまたは別のフォレストで発生する可能性があります
2. マッピングが一意でない場合は、ヒントを指定する必要があります (たとえば、複数のユーザーが同じ証明書にマップされている場合)
証明書に UPN が存在する場合:
1. 証明書を同じフォレスト内の複数のユーザーにマップすることはできません
2. 証明書は、異なるフォレスト内の複数のユーザーにマップできます。ユーザーが他のフォレストにサインインするには、X509 ヒントをユーザーに提供する必要があります

ユーザーのグループは、1 つのアカウント (管理者アカウントなど) にサインインできます。そのアカウントでは、ユーザー証明書がマップされ、サインインが有効になります。

複数の個別の証明書を 1 つのアカウントにマップできます。これを適切に機能させるには、証明書に UPN を含めることはできません。

たとえば、Certificate1 に CN=CNName1、Certificate2 に CN=User1、Certificate3 に CN=User2 がある場合、これらの証明書の AltSecID は、Active Directory ユーザーとコンピューター名マッピングを使用して 1 つのアカウントにマップできます。

アカウントマッピングをフォレスト間で機能させるには、特に証明書に十分な情報がない場合、ユーザーは 、domain\user などのユーザー名や、などの完全修飾 UPN user@contoso.comの形式でヒントを入力する場合があります。

注

スマートカードサインイン中にヒントフィールドを表示するには、クライアントで [ユーザー名ヒントのグループポリシーを許可する] 設定 (X509HintsNeededed レジストリキー) を有効にする必要があります。

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 ドメイン名を含むサブジェクトフィールド。解決されない場合は、適切なドメインへの解決が失敗するため、リモートデスクトップサービスとスマートカードでのドメインサインインは失敗します
- ドメイン名が実際のドメインに解決される UPN。たとえば、ドメイン名がの Engineering.Corp.Contoso場合、UPN はです username@engineering.corp.contoso.com。ドメイン名の一部を省略すると、Kerberos クライアントは適切なドメインを見つけることができません

これらのバージョンのドメインへのスマートカードサインインを許可するには、次の操作を行います。

CA で HTTP CRL 配布ポイントを有効にする
CA を再起動する
KDC 証明書を再発行する
スマートカードサインイン証明書を発行または再発行する
ドメインサインインに使用するスマートカードに更新されたルート証明書を反映する

回避策は、[ユーザー名ヒントのグループポリシーを許可する] 設定 (X509HintsNeeded レジストリ キー) を有効にして、ユーザーがドメインサインインの資格情報ユーザーインターフェイスにヒントを指定できるようにすることです。

クライアントコンピューターがドメインに参加していない場合、または別のドメインに参加している場合、クライアントコンピューターは、UPN ではなく証明書の識別名を調べることによってのみ、サーバードメインを解決できます。このシナリオを機能させるには、ドメイン名の解決のために、証明書には、を含む DC=<DomainControllerName>完全なサブジェクトが必要です。

現在参加しているドメインのスマートカードにルート証明書を展開するには、次のコマンドを使用します。

certutil.exe -scroots update

コマンドラインツールのこのオプションの詳細については、「 -SCRoots」を参照してください。

証明書の要件と列挙

KDC 証明書