イカがKerberos / NTLM認証を壊すのはなぜですか？
プロキシとしてsquid2.6.22（Centos 5 Default）を使用しています。 Squidは、NTLMまたはKerberos認証が必要な場合、Webページの認証プロセスを中断しているようです。 SharePoint 2007でテストし、3つの認証方法（NTLM、Kerberos、Basic）をすべて試しました。イカなしでサイトにアクセスすることは、すべての場合に機能します。 squidで同じページにアクセスすると、基本認証のみが機能します。 IEまたはFirefoxを使用しても違いはありません。Squid自体は誰でも使用できます（auth_paramは構成されていません）。ほとんどのトピックがauth_paramを巡回するため、オンラインで解決策を見つけるのは少し難しいです。 squidの背後にあるWebページに対してユーザーを認証するのではなく、squidに対してユーザーを認証するため。
編集：
申し訳ありませんが、私の最初のテストは完全に失敗しました。間違ったWebサーバーに対してテストしました（自分自身へのメモ：テストする前に必ず仮定を確認してください）。今、私は問題のシナリオが完全に異なっていることに気づきました。
- IE用のKerberosの動作
- KerberosはFirefoxで機能します（about：configの「network.negotiate-auth.trusted-uris」を変更した後）
- NTLMはIEで動作します
- NTLMはFirefoxでは機能しません（about：configで「network.automatic-ntlm-auth.trusted-uris」を変更した後でも）
ちなみに、squidでNTLMパススルーを提供する機能は「接続の固定」と呼ばれ、HTTPヘッダーは「プロキシサポート：セッションベースの認証」と呼ばれます。
Firefoxにバグがあり、特定の条件でNTLMが失敗します。 Squidをプロキシとして使用すると、ほとんどの場合、これらの条件を満たすことになります。 https://bugzilla.mozilla.org/show_bug.cgi?id=602814 を参照してください
私はあなたが尋ねることは非常に関連していると思います Apacheを基本認証に設定する方法、またはプロキシ中にntlmを許可する方法は？ 。特に、プロキシとリモートサイトの両方に対して認証する場合、それは不可能です（クライアントがCONNECTを使用しない限り）。
Squidに対して認証するのではなく、リモートサイトに対してのみ認証するという状況の場合、Squidは何らかの形で正しいことを行っていると思います。自分自身を認証して取得したリソースがキャッシュに入ると、それも利用できるようになります。他のクライアントに対する認証されていない要求の場合。より正確には、このフローを見てください。
- ユーザーAは、一部の
/index.htmlでリソースthat.server.comを要求し、認証情報を提供しました。 - サーバーはHTTPステータス200を返し、Squidはリソース
/index.htmlをキャッシュしました。 - ここで、ユーザーBが同じリソースを要求し、認証情報を提供していないか、認証された情報を提供しています。
考えられるシナリオ：
- SquidはキャッシュからユーザーBに
/index.htmlを返します。どのユーザーがどのリソースにアクセスできるかを知っているのはサーバーだけなので、これは間違っています。 - Squidは、
/index.htmlと一緒に認証情報をキャッシュしようとします。基本認証の場合、Squidはユーザー名を取得できます。他のメカニズム（NTLM/Kerberos）は、HTTPを介してハッシュのみを送信するため、ユーザー名を学習する方法はありません。 - Squidは
/index.htmlをキャッシュしません。