0

会社のサーバーの 1 つに対して認証しようとしています。最初に接続しようとすると、ヘッダー付きの 401 が返されます。

www-authenticate: NTLM TlRMTVNTUAACAAAAAAAAACgAAAABggAAVU9wgQTnlrgAAAAAAAAAAA==

base64 部分を解析すると、次のようになります。

0000   4E 54 4C 4D 53 53 50 00 02 00 00 00 00 00 00 00    NTLMSSP.........
0010   28 00 00 00 01 82 00 00 B6 70 AC 57 8C D0 07 44    (........p.W...D
0020   00 00 00 00 00 00 00 00                            ........

これは、次のように解析されます。

Signature = NTLMSSP
msg_type = 2
TargetNameLen = 0
TargetNameMaxLen = 0
TargetNameOffset = 40
NegotiateFlags = 0x8201
ServerChallenge = B6 70 AC 57 8C D0 07 44

これは、私がこれを自分で解析していないことに言及する必要がある場所です。問題はないと思いますが、python_ntlm-1.0.1 と requests-ntlm 0.0.2.1 のコピーを新しくインストールした Python 2.7 を使用しています。パケットが短すぎるため、ntlm モジュールが parse_NTLM_CHALLENGE_MESSAGE ルーチンでクラッシュしています。 . オフセット 0x0020 から始まる、明らかに 16 バイトの予約領域があり、その後に 3 つの 32 ビット整数が続きます。代わりに、予約領域には 16 進数の 00 が 8 バイトしかなく、他の数字はありません。基本認証以上のものが必要になったのはこれが初めてです。TargetNameLen が 0 であることは何か特別なことを意味していると思いますが、python_ntlm のメンテナーにバグ レポートを提出する前に、取得しているデータの解釈を手伝ってもらえますか?

ありがとう！

4

1 に答える 1

2

問題は NegotiateFlags フィールドの解釈方法にあることが判明しました。Microsoft が公開している仕様によると、興味深い点が 2 つあります。NTLMSSP_REQUEST_TARGET フラグが設定されていない場合、TargetName は必要ありませんが、NTLMSSP_NEGOTIATE_TARGET_INFO が設定されていない場合、TargetInfo は必要ありません。ただし、何年にもわたるパケットのフォーマットの進化により、TargetName フィールドは NegotiateFlags より前にあるため、無視された場合でも存在し、ゼロで埋められる必要があります。一方、TargetInfo フィールドは NegotiateFlags フィールドの後に表示されるため、省略して短いパケットを残すことができます。python-ntlm プロジェクトにパッチを提出しましたが、すべてがすぐに修正されるはずです。将来、他の誰かが独自の認証コードを書いてつまずいた場合に備えて、このソリューションを提供しています。

于 2013-02-06T14:36:07.787 に答える