HTTP経由でサーバーと通信する.Netでクライアントアプリケーションをプログラミングしています。
NTLMおよびKerberos認証の場合、異なる要求バッファリングオプションを設定する必要があります。
NTLMまたはKerberosが使用されているかどうかを確認するにはどうすればよいですか?'WWW-Authenticate:Negotiate'ヘッダーをなんとかしてデコードすることは可能ですか?
HTTP経由でサーバーと通信する.Netでクライアントアプリケーションをプログラミングしています。
NTLMおよびKerberos認証の場合、異なる要求バッファリングオプションを設定する必要があります。
NTLMまたはKerberosが使用されているかどうかを確認するにはどうすればよいですか?'WWW-Authenticate:Negotiate'ヘッダーをなんとかしてデコードすることは可能ですか?
ここに答えがあります。
簡単な答えは次のとおりです。
1.Capture some successfully authorized request using Fiddler tool.
2.Choose "Inspectors" -> "Headers" tab.
3.Pay attention at "Cookies / Login" section, "Authorization" header.
Authorizationトークンが「YII」で始まる場合はKerberosが使用されますが、「TlR」で始まる場合はKerberosは使用されません。
例:Kerberos:
Authorization: Negotiate YIIVDAYGKwYBE...
Kerberosではありません:
Authorization: Negotiate TlRMTVNTUA...
Negotiateヘッダーの解析は、ASN.1 DERを使用して構築されているため、退屈な作業の一種です。
とは言うものの、ペイロードについて適切な仮定をするために、必ずしもこれをデコードする必要はないかもしれません。GSSAPI for NTLMにはメカニズムがありますが(詳細は以下を参照)、私の経験では、クライアントは実際にはそれを使用せず、単にNTLMヘッダーを送信します。私の(確かに厳密に制御された)環境ではAuthorization: NTLM ...
、これがNTLMであることが保証されています。私が見るならAuthorization: Negotiate ...
、これはKerberosであることが保証されています。
厳密に言えば、メカニズムがNTLMであるかKerberosであるかを判断するには、ヘッダーのメカニズムリストを確認する必要があります。既製のASN.1デコーダーを使用するか、Microsoftのデコード例を確認することをお勧めします。SPNEGO OID(1.3.6.1.5.5.2
)を探してから、その中のメカニズムタイプシーケンスを探します。シーケンスの最初のメカニズムは応答トークンのペイロードに対応しているため、そのOIDを調べてメカニズムを判別できます。Kerberosの既知のOIDは次のとおりです。
1.2.840.113554.1.2.2 (Kerberos 5)
1.2.840.48018.1.2.2 (Microsoft Kerberos 5)
1.3.5.1.5.2 (Kerberos 5 OID 2)
私の知る限り、NTLMの唯一のOIDは(このブログから参照):
1.3.6.1.4.1.311.2.2.10 (NLMP NTLM)
サーバーがユーザーNegotiateにアドバタイズする場合、Kerberosを自由に使用できます。NTLMまたは何かがSPNEGOによってサポートされています。ただし、サーバーがクライアントから送信されたすべてのラップされた認証メソッドをサポートするという保証はありません。
はい; Base64でデコードするだけで、「NTLM」または「HTTP」が表示されます。
C#
v = BitConverter.ToString(Convert.FromBase64String(v.Replace("Negotiate: ","")));
if (v.indexOf("NTLM") > -1) {
//...
}