Web サイトにアクセスするための単純なクライアント ソケット アプリケーションがあります。クライアントがインターネットにアクセスするには、HTTP プロキシ サーバーを経由する必要があります (Microsoft Forefront Threat Management Gateway を使用しています)。プロキシ サーバーは認証を必要とし、GSSAPI 経由で Kerberos を受け入れるように構成されています。
私のクライアントでは、Microsoft の SSPI を使用しています。
まず、成功して返されるAcquireCredentialsHandleを呼び出しますSEC_E_OK
次に、InitializeSecurityContextを呼び出します。これも成功して戻りますSEC_E_OK
ここまでは順調ですね。しかし今、承認のためにトークンをプロキシサーバーに送信する必要があります。これが問題を引き起こしている部分です。
Internet Explorer を使用してプロキシ サーバーに接続すると、Wireshark を介してパケット交換を監視できます。IE は Kerberos とチケットをネゴシエートし、Proxy-Authorization ヘッダーを介して送信するように見えます。ヘッダーの内容は base64 でエンコードされているようです。
から返されたトークンを単に取得し、InitializeSecurityContextそれを base64 エンコードして、結果を のようなヘッダーを介してプロキシ サーバーに送信するとProxy-Authorization: Negotiate <base64Data>、認証は失敗します。
近づいたような気がしますが、まだ何かが欠けています。あるサイトでは、送信前にトークンで EncryptMessage を使用することについて説明していました。相互認証の使用について別の議論がありました (IE が相互認証を使用しているとは思いません。なぜなら、クライアントは認証を 1 回しか送信していないようで、サーバーからのフィードバック データがないためです ( InitializeSecurityContext2 回目に呼び出す)。別のサイトでは、トークンをさまざまなSEC_BUFFERタイプ（パディング、データなど）と暗号化方法に関するドキュメントがあまり見つからないため、これが必要なことだと思います。
洞察や提案をいただければ幸いです。
UPDATE 7/19/2014: 明確にするために、SSPI を使用して「base64Data」フィールドを計算する方法を尋ねています (上記参照)。SECBUFFER_TOKEN のバッファに含まれるコンテンツの base64 エンコーディングを計算することは私の最初の推測でしたが、サーバーは結果を受け入れないため、明らかに無効です。
さらなる調査によると、トークンを「ラップ」する必要があり (別名、SSPI を介して「EncryptMessage」)、GSSAPI と互換性のある方法で暗号化するには、3 つのバッファーを使用する必要があります (順序: SECBUFFER_TOKEN、SECBUFFER_DATA、および SECBUFFER_PADDING)。これは昨日ですが、成功しませんでした。