接続間のセキュリティ コンテキストの維持

Note

Windows 11 22H2 以降、Microsoft は Microsoft Digest (wDigest とも呼ばれます) を非推奨とします。 Microsoft Digest は引き続き、サポートされているバージョンの Windows でサポートされます。 今後のバージョンの Windows には、Microsoft Digest の機能が制限され、最終的には Microsoft Digest は Windows でサポートされなくなります。

ドメイン コントローラーのトラフィックを減らし、パフォーマンスを向上させるために、Microsoft Digest のクライアント側は、サーバーでの認証が成功した後に受信した情報をキャッシュします。 クライアント アプリケーションは、確立された セキュリティ コンテキスト へのハンドルのみをキャッシュする必要があります。 次の表では、セキュリティ パッケージによってキャッシュされる情報について説明します。

Information	説明
サーバー名	ユーザーのセキュリティ コンテキストが正常に作成されたサーバー。
領域/ドメイン	成功した認証で使用されるドメイン名。
Nonce	成功した認証に関連付けられているサーバー nonce。
Nonce count	クライアントがサーバーへの要求に nonce を含める回数。 これは、再生検出に使用されます。
不透明な値	認証が成功した後に不透明ディレクティブに対して返される値。 この値には、ユーザーのセキュリティ コンテキストへの参照が含まれています。

クライアントがサーバーにメッセージを送信する場合、サーバーはクライアントに既存のセキュリティ コンテキストがあるかどうかを判断する必要があります。 これを行うために、サーバーは各クライアント要求を AcceptSecurityContext (General) 関数に渡します。 この関数は、要求 (存在する場合) から不透明なディレクティブの値を抽出し、それを使用してクライアントのセキュリティ コンテキストを検索します。 セキュリティ コンテキストが見つかった場合、コンテキストのハンドルがサーバーに返されます。 関連情報については、「 後続の要求の認証」を参照してください。

スプーフィング攻撃とリプレイ攻撃を検出する手段として、クライアントは、セキュリティ コンテキストを使用してメッセージに署名する MakeSignature 関数を呼び出します。 MakeSignature 関数を使用してメッセージが保護されている場合、サーバーはキャッシュされたコンテキストと共に VerifySignature 関数を使用して、メッセージの配信元と整合性を確認します。 詳細については、「 メッセージの保護」を参照してください。