接続間のセキュリティ コンテキストの維持
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 関数を使用して、メッセージの配信元と整合性を確認します。 詳細については、「 メッセージの保護」を参照してください。