現在、SharePointサイトでの認証で問題が発生しています。通常、ユーザーアカウント(一度に1つ程度)はロックアウトされ、401の不正なエラーが発生します。 SharePointの実装では、ローカルユーザーアカウントのみを使用し、SSLおよびNTLM認証を使用しています。正確なネットワーク構成はわかりませんが(私はネットワーク管理者ではありません)、プロキシが関係している可能性があります。ネットワーク管理者が問題を調査するまでに、アカウントは再び機能しています。断続的です。これに関する私の質問は次のとおりです。
1.)誰かが以前にこれに遭遇したことがありますか?
2.)基本認証に切り替えると、これは解決しますか?プロキシが関与している場合、WSSでNTLMマングリングの短いささやきがあります。
3.)そもそもSSLとIWAは一緒に少しやり過ぎですか?とにかく、パスワードとログインはSSLを使用した基本認証で暗号化されて送信されるということですか?また、ドメイン以外のエクストラネットでのIWAの利点は、私には役に立たないようです。
IISログファイルをチェックして、パターンがあるかどうかを確認することをお勧めします-401を取得する特定のリソースであるか、それとも汎用であるかを確認します。
通常の問題は、特定のリソースがサーバー(ファイルシステム)フォルダーにある可能性があり、すべてのユーザーがそれらにアクセスできるとは限らないことです。これらのリソースは特定のページからのみリンクされる可能性があるため、エラーが断続的に発生する可能性があります。 SharePointは、デフォルトで偽装されたコンテキストで要求を実行することを忘れないでください。
Kerberosの場合、ネゴシエートが表示されると思います(または、間違っていると思いますか?)
ネゴシエートは、kerberosまたはntlmである可能性があります。 ntlmは間違いなくntlmを意味します。
使用した認証方法を確認するには、認証ヘッダーの最初の文字を確認してください。 「T」の場合はntlmです。 「Y」の場合はケルベロスです。
http://support.Microsoft.com/kb/891032
IISをNTLMを要求するように構成できますが、その逆は機能しません(kerberosが必要です)。ただし、それは素晴らしいことです。
コンテンツを暗号化する必要がある場合、SSLはやり過ぎではありません。 SSLなしのKerberosは認証には十分安全ですが、コンテンツを暗号化しません。
「ローカル」アカウントとはどういう意味ですか?エクストラネットにスタンドアロン/非ドメインのSharePointサーバーがあり、ユーザーは非ドメイン/ローカルアカウントでログオンしますか?
NTLM認証がプロキシを介して失敗する場合がいくつかありますが、ほとんどのプロキシでその動作が修正されていることを願っています。
WSSサイトが信頼済みサイト/イントラネットとして設定されており、認証資格情報が自動的に渡されるようにブラウザが設定されていることを確認します。それが実際にドメイン上にある場合はおそらく役立つでしょうが、そうではないようです。
いつでも基本認証にフォールバックできますが、そのルートを使用する場合は必ずSSLを使用してください。
つまりね。 Sharepointは偽装を使用します。つまり、NTLMをまったく使用しないでください。Kerberosを使用する必要があります。それは非常に大きな違いです。 NTLMは、「統合Windows認証」を意味するものではありません。
だからここにあなたがする必要があることです。セキュリティイベントログの下のSharepointサーバーに移動します。ここでは、すべてのユーザーが「NTLMSSP」ではなく「Kerberos」を使用して認証されていることがわかります。人々がNTLMを使用してアクセスを許可されていることがわかった場合、それはおそらく(80%の確率で)Sharepointのサービスプリンシパル名を定義する必要があることを意味します。 SharePointサイトをエイリアスで実行している場合、IE7には間違ったSPNのチケットを断続的に要求するバグがあるため、そのエイリアスのサービスプリンシパル名も設定する必要があります。
だから私の3つのヒントは次のとおりです。