Safari 7がHTTP認証を使用してイントラネットに接続できない


9

内部で行われている実際のHTTPリクエストに関する新しい情報については、以下のUPDATEを参照してください。

10月に新しい仕事を始めました。ほとんどがWindowsショップであり、IISとActive Directoryを使用して社内でさまざまな作業を行っています。彼らはイントラネットサイトを持っていintranet.companyname.comます。

Chrome on Mavericksでは、そこに行くと、予想される小さなHTTP認証ドロップダウンが表示されます。

Chromeの機能;  これは、私がSafariで取得すべきものです

ユーザー名とパスワードを入力できます。私はActive Directoryにあまり慣れていませんmsgdが、現在使用しているActive Directoryドメインであるためmsgd\lheidbreder、パスワードを入力すると、Chromeに正常にログインできます。

10月にさかのぼって、初めてSafariでこれを試したとき、私は奇妙な振る舞いをしました。たとえば、パスワードを確認したのですが、資格情報を入力しても機能しませんでした。それが何をしたのか正確には覚えていません。

しかし、その最初の試行の後、それ以降のすべての試行で、に移動しようとするとintranet.companyname.com、Safariに空白の画面が表示されます。

イントラネットに接続しようとしたときにMavericksのSafari 7が行うこと

画面は変化せず、進行状況バーが約20%いっぱいになり、そのまま残ります。


更新

私はHTTPリクエストをスヌープするアプリを実行しましたが、これが裏で何をしているのかを知りました。そこに座っているだけではありません。Safariは実際に1秒あたり約1000回ページをリクエストしており、毎回401エラーと「このページを表示する権限がありません」というタイトルのHTMLエラーページが表示されます。

ロード試行の途中からのリクエストの例では、Safariは次のAuthorizationヘッダーを送信します。

Negotiate YEgGBisGAQUFAqA+MDygDjAMBgorBgEEAYI3AgIKoioEKE5UTE1TU1AAAQAAAAUCiGIAAAAAGAAAAAAAAAAYAAAABgGwHQ8AAAA=

そしてサーバーはこのWWW-Authenticateヘッダーで応答します:

Negotiate oYIBIzCCAR+gAwoBAaEMBgorBgEEAYI3AgIKooIBCASCAQROVExNU1NQAAIAAAAOAA4AOAAAAAUCiWKPhp0o8/Y/9gAAAAAAAAAAvgC+AEYAAAAFAs4OAAAAD0EAUgBJAFMAVwBFAEIAAgAOAEEAUgBJAFMAVwBFAEIAAQAMAE4ARQBXAFcARQBCAAQAKgBhAHIAaQBzAHcAZQBiAC4AYQByAGkAcwB0AG8AdABsAGUALgBuAGUAdAADADgATgBFAFcAVwBFAEIALgBhAHIAaQBzAHcAZQBiAC4AYQByAGkAcwB0AG8AdABsAGUALgBuAGUAdAAFACoAYQByAGkAcwB3AGUAYgAuAGEAcgBpAHMAdABvAHQAbABlAC4AbgBlAHQAAAAAAA==

次のリクエストで、Safariは同じAuthorizationヘッダーを送信し、サーバーはわずかに異なるWWW-Authenticateヘッダーで応答します。

Negotiate oYIBIzCCAR+gAwoBAaEMBgorBgEEAYI3AgIKooIBCASCAQROVExNU1NQAAIAAAAOAA4AOAAAAAUCiWLa6vytPOG0owAAAAAAAAAAvgC+AEYAAAAFAs4OAAAAD0EAUgBJAFMAVwBFAEIAAgAOAEEAUgBJAFMAVwBFAEIAAQAMAE4ARQBXAFcARQBCAAQAKgBhAHIAaQBzAHcAZQBiAC4AYQByAGkAcwB0AG8AdABsAGUALgBuAGUAdAADADgATgBFAFcAVwBFAEIALgBhAHIAaQBzAHcAZQBiAC4AYQByAGkAcwB0AG8AdABsAGUALgBuAGUAdAAFACoAYQByAGkAcwB3AGUAYgAuAGEAcgBpAHMAdABvAHQAbABlAC4AbgBlAHQAAAAAAA==

無限に繰り返します。


intranetキーチェーンアクセスで一致するものをすべて削除し、キャッシュ/ Cookieをすべてクリアして、元の奇妙な動作を復元できるかどうかを確認しようとしましたが、機能しませんでした。

ある種のファンキーなドメインが進行中ですか?これを診断するために他に何を試すことができますか?


キーチェーンの問題ではなく、おそらくCookieに関連しています。Safariの設定ペインの「プライバシー」セクションからそれらを削除してみてください。
ケント

いいえ。以下の答えについてコメントしました。キャッシュ、Cookie、すべてをクリアしましたが、まったく同じことを実行します。HTTP認証ポップアップが表示されるはずなので、Cookieが直接関係することはないと思います。
第75トロンボーン

ランダムだと思いました... iCloudキーチェーンも確認しましたか(キーチェーンをiCloudにリンクしている場合はそうですか)。キーチェーンアクセスでは、ログインキーチェーンとiCloudキーチェーンに個別のエントリがあります
ithos67 2014年

良い考えですが、私はこのコンピューターでiCloudキーチェーンをオフにしており、いずれにしても、キーチェーンアクセスでの検索では、利用可能なすべてのキーチェーンが検索されます。
75回目のトロンボーン

1
役に立たないことはわかっていますが、Safari 7.0.4とイントラネットSharePointでまったく同じ問題があることを発見しました。ChromeとFirefoxで正常に接続できますが、Safariは、あなたが説明したようにロードを開始し、そのままそこに座っています。とてもうるさい。
nemesys

回答:


7

現在のすべてのMac OS X MavericksアップデートがインストールされているSafari 7.0.2(9537.74.9)でも同じ問題が発生することを確認できます。(上記と同じ種類のコンテンツを持つ1秒あたり数千のリクエストパケット。)

ただし、これが元の投稿者に役立つかどうかはわかりませんが、この問題が発生するのは、Windowsサーバーで統合Windows認証(NTLM認証も呼ばれます)ネゴシエート認証が有効になっている場合のみです。

次に、サーバーは次の2つのヘッダーを送信します。

WWW-Authenticate: Negotiate
WWW-Authenticate: NTLM

Safariが返信します。

Authorization: Negotiate YEgGBisGAQUFAqA+MDygDjAMBgorBgEEAYI3AgIKoioEKE5UTE1TU1AAAQAAAAUCiGIAAAAAGAAAAAAAAAAYAAAABgGwHQ8AAAA=

そして、そこからループが始まります。

ただし、サーバーでネゴシエート認証が有効になっていない場合、WWW-Authenticateヘッダーは1つしかありません。

WWW-Authenticate: NTLM

そして、Safariの返信は次のようになります。

Authorization: NTLM TlRMTVNTUAABAAAAB4IIAAAAAAAAAAAAAAAAAAAAAAA=

これは問題なく動作します。基本的に、NegotiateはSafariで壊れているように見え、サーバーは最初にNegotiateを送信して優先順位を示しているため、Safariはそれを試行して無限ループに入り、NTLMにフォールバックしないようにします。

そのため、サーバー管理者が認証設定でネゴシエートをオフにするように説得できれば、問題は解決する可能性があります。

サーバーがNTLMに加えてネゴシエートを提供するかどうかに関係なく、Firefoxが "Authorization:NTLM ..."ヘッダーを送信することを付け加えます。おそらく、NegotiateはFirefoxに実装されていません。


更新

Safari 7.0.3(9537.75.14)でも同じ問題が発生します。

以前はbugreport.apple.comでバグとして問題を報告していましたが、バグは以前のバグの複製としてクローズされました。

アップデート2

認証がSafari 7.0.4(9537.76.4)で機能するというhaunsの発見を確認できます。

アップデート3

この問題はSafari 7.0.5(9537.77.4)で再び発生します。

アップデート4

この問題は、ハウンスが指摘しているように、cifsまたはsmbボリュームがマウントされているSafari 7.0.6(9537.78.2)にも存在します。


情報をありがとう。公式のバグレポートをOpen Radarにコピーして、ここにリンクすることを検討してください。
75番目のトロンボーン

1
この問題はOS X 10.11.5で解決されて
クラウスヨルゲンセンを

3

Safari 7.0.5にはまだ問題があります。SMB:(またはCIFS :)を介してファインダーがネットワークリソースを共有すると、認証が失敗します。接続されているすべてのネットワークボリュームがマウント解除されると、Safariは適切な認証を再開します。

回帰:

  1. ヨセミテ10.10.1 / Safari 8.0.2に存在
  2. El Capitan 10.11.2 / Safari 9.0.2に存在
  3. Safari 10.0.1に存在

対応するAppleバグ22990203はまだアクティブです。人間はそれを見ることができません(cf.bugreporter.apple.com)

参照:https : //discussions.apple.com/message/27727310#27727310


1

同じ問題が発生しています。したがって、なぜMacをまだMavericksにアップグレードしていないのか。ドメイン資格情報なしでイントラネットにログインしようとするようです(イントラネット\ '空白')。domain \ usernameを使用する必要があります。これはイライラするかもしれませんが、サファリでは認証が欠落しているようです。

ほんの数秒でログが吹き飛ばされます。

Firefoxはうまく機能しているようです。


1
「私はほんの数秒でログを吹き飛ばします」—本当に?Console.appに何も記録しないようにしています。どのログに書き込まれますか?
第75トロンボーン

ログにはSolarwindsを使用します。ただし、イントラネットサーバーのシステムログにヒットします。
ダニエル

1

これは長いショットかもしれませんが、Kerberosチケット(別のサービスへのサインインから)がある場合、Safariがそれを使用しようとしている可能性があります。

/ System / Library / CoreServices / Ticket Viewer.appを開いて、Kerberosチケットがあるかどうかを確認します。その場合は、チケットをクリックしてIDを削除してから、もう一度やり直してください。

または、何も表示されない場合は、IDの追加を使用して、それがSafariで機能するかどうかを確認してください。

FirefoxとChromeはKerberosを使用していないと思います。そのため、資格情報の入力を個別に求められます。


1
そこには何も表示されていません。資格情報を入力しようとすると、「パスワードが正しくありません」と表示されます。
75回目のトロンボーン

1
チケットを追加するとき、ユーザー名としてmsgd \ lheidbrederを使用していますよね?
可燃性

1
はい、そうです。
第75トロンボーン

0

キーホルダーはいいアイデアでしたが、あなたは十分に行きませんでした。

SafariでSafariメニューの下を見るReset Safari...と、[これを選択] が表示され、いくつかのキャッシュがクリアされます。

今オープンSafari> Preferences> AutofillとオフUser names and passwords。次にPasswords、そこにリストされているパスワードを選択して削除します。を選択PrivacyしてクリックしRemove All Website Dataます。を選択しExtensions、拡張機能がインストールされている場合は拡張機能をに切り替えOffます。

さあ、あなたのウェブサイトを試してみてください。試行が完了しPrivacyたら、Cookieが残っているPasswordsかどうか、Safariがパスワードを保存したかどうかを確認します。

これにより、ソリューションに近づく可能性があります。その後どうなるか教えてください。Chromeが機能する場合、それが何をしているのかを正確に知りたいです。もう少しスヌーピングが必要になるでしょうか?

ちょっと笑って、URLを試してみてhttp://username:password@intranet.example.com/(明らかにビットを置き換えて)、何が起こるか確認してください。


intranet.companyname.comサイトのパスワードやCookieはありませんでしたが、いずれにしてもそれらをすべてクリアしました。期待どおり、まったく同じ動作をします。取得する必要があるのはブラウザのHTTP認証モーダルであるため、それがどこにでもある場合は、Cookieではなくキーチェーンアクセスにあることに注意してください。
75回目のトロンボーン

1
それは私に来て、もう少し追加しました。
トニーウィリアムズ

1
そのURL形式を試しても何も起こりません。
75回目のトロンボーン

1
https://同様にそれを試してください。
トニーウィリアムズ

0

私のオフィスでも同様の問題がありました。重要なのは、私のDNSルックアップでローカル(会社/イントラネット)サイトがDNSアドレスを探すために出かけることを確実に除外することでした。それが私のシステムがプロキシに出て行こうとし、常にログイン画面が表示される原因でした。起こっていたのは、intranet.company.comのURLに対する私の要求がプロキシサーバーによって取得され、Webに送信されていたことです。メインのWebサーバーは、会社のIPを介して接続していることを確認し、プロキシによって取り除かれた資格情報を探して応答します。

基本的に、イントラネットサイトがプロキシに送信されていないことを確認すると、問題が解決しました。その上、Chromeをデフォルトのブラウザにするだけです...


0

使用チケットViewer.appを/System/Library/CoreServices/Ticket Viewer.appと、新しいチケットを追加します。

新しいチケットで、イントラネットURLの認証にユーザー名とパスワードを使用します。


1
上記のように、そのアプリに新しいチケットを追加しようとすると、ユーザー名とパスワードの組み合わせが間違っていることがわかります。私は両方lheidbredermsgd\lheidbreder私のユーザー名として試してみました。運がない。
75回目のトロンボーン

これは実際に私のために働いた。イントラネットがあったドメインのIDを追加する必要がありました。たとえば、ドメインパスワードを使用して「domainusername @ workdomain」を追加しました。
tjeerdhans

0
  1. Macで新しいユーザーを作成します。
  2. この新しいユーザーに切り替えます。現在のセッションを開いたまま、これを行うことができます。
  3. Safariを起動します。これは未使用のSafariです。
  4. サイトに接続してみてください。通常、認証ダイアログが表示されます。

0

これは役立つかどうかはわかりませんが、自分以外のsmb共有に接続すると、OS 10.9.2を実行しているSafari 7.0.3で認証ウィンドウが失われることがわかりました

自分のActive Directoryログインとパスワードと同じです。Active Directoryサーバーにバインドされています。

バインドされていないマシンではこれをテストしていません。私はChromeとFireFoxもテストしましたが、これらのアプリは問題なく動作します。Auroraはどちらの方法でも動作しません。

別のユーザーによる編集:

これが問題の原因のようです。これは、Mavericksを実行し、現在はヨセミテを実行している非バインドマシンでテストされています。SMB共有に接続した後、Safariは認証ダイアログを表示しなくなります。Mavericksでは、SMB共有から切断するとすぐにダイアログが表示され、会社のSharepoint 2013イントラネットサイトにログインできます。Sharepoint 2007やその他のイントラネットサイトでは問題ありません。

Yosemiteでは、最大2つのSMB共有に接続でき、Safariは引き続き機能するようです。3つ以上のSMB共有に接続している場合、問題が発生します。それが共有の数であるのか、あるいは異なる共有が状況に影響を与える可能性のある異なるアクセス許可を持っているのかどうか、私にはまだわかりません。その前に、もっと厳密なテストをする必要があります。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.