Windows 7、HTTPS WebDav：パスワードを2回要求して失敗します。回避策はありますか？
PHP SabreDav（code.google.com/p/sabredav/wiki/Windows）でDavサーバーを実行しています）HTTPSで保護されたURLのCherokeeで。httpsを使用するように設定されており、ダイジェスト認証を使用しています。複数のブラウザーといくつかのサードパーティクライアント（BitKinexおよびJava AnyClient can connect and参照してください、以下の警告）。
しかし、Windows 7でログインしようとすると（サプライズ、サプライズ）、パスワードを2回要求され、その後、フォルダーが無効であると通知されます。
- サーバーがダイジェスト認証を使用していることを確認しました。
- サードパーティのソフトウェアが接続できることを複数回確認しました。
- 私は外に出てGoDaddy SSL証明書を購入したので、SSLはもう自己署名されません。
- ここでレジストリハックを適用しました：support.Microsoft.com/kb/943280（この記事では、Windowsの「修正プログラム」はすでに存在していることに注意してください7、私はそれを機能させるために魔法のレジストリハックスが必要です）
- ここでレジストリハックを適用しました：support.Microsoft.com/kb/941050
- ここでレジストリハックを適用しました：support.Microsoft.com/kb/841215（おそらく適用されないはずの基本認証を許可しますが、その理由ない？）
まったく役に立たない。 Windowsは引き続きパスワードを2回要求し、「入力したフォルダーは有効ではないようです。別のフォルダーを選択してください。」と述べます。
コマンドラインを試してみますか？承知しました：
- Net Use " https://dav.example.com/ " password/USER：me（システムエラー59）でアクセスしようとしました
- Net Use " https://dav.example.com/ "でアクセスを試みました（システムエラー1790）
- Net Use " https://dav.example.com/subdir/ " password/USER：me（システムエラー59）でアクセスしようとしました
- Net Use " https://dav.example.com/subdir/ "でアクセスを試みました（システムエラー1790）
- 幸運を祈ります：ping dav.example.com ...は動作します。繰り返しになりますが、Webブラウザーは共有に問題なくアクセスできるため、サードパーティのツールもアクセスできます。
この時点で言えることは、「HAHA、WINDOWS 7でのWebDAVはありません」です。これは、このアプリケーションを使用するすべての人を除いて問題ありません。Windows7を使用しています。ほとんどの場合、私ほど永続的ではありません。
Googleの最初の10ページで、思いつくすべての検索語句に出くわしたすべてのランダムな提案に目を通したような気がします。何か案は？ Webdavである必要があり、HTTPS経由である必要があります。また、Windows 7からアクセスする方法が本当に必要です。
追加の詳細：
しかし、私が試した「サードパーティ」プログラムは、バグが多いか、不完全であるか、または愚かな...「グリッチ」でした。たとえば、BitKinexは送信されたすべてのhttpエラーコードを修正するようです。そのため、ディレクトリBAMを読み取るグリッチがある場合、そのディレクトリは常に空で表示されます。転送パネルにディレクトリリストがまだ実行中であると表示されていても、長いディレクトリリストも空白として表示されます。
いずれにせよ、BitKinexは上記の理由により、開発目的には役に立たない。さらに、このdav共有を「通常の方法」で機能させたいと思う人以外の人のために、これを構築しています。
WebDAVは嫌いです。
私は、ファイルサービングクラスターにWebDAVサポートを取得するプロセス中にこの憎悪を獲得しました。これは、Server 2008/IIS7に基づいており、IIS用のWebDAVプラグインを備えています。それは不格好で、そこにある個々のWebDAVクライアントはそれぞれ、以下の独自のカスタムミックスを介してWebDAVサーバーと通信できることを期待しています。
- トランスポートメカニズム：HTTPまたはHTTPS
- セッション追跡：CookieまたはHTTPヘッダー
- Authentication：基本、ダイジェスト、Kerberos、またはNTLM認証
- カスタムポートのサポートが含まれる場合と含まれない場合があります。
- ルートディレクトリに接続する機能が存在する場合と存在しない場合があります。 WinXPは確かに
http://davhost.example.com/に接続できません。http://davhost.example.com/root/に接続する必要があります
WinXPとWin7の動作は異なります。初期のWinXPバージョンは、HTTPSをまったくうまく通信できません。一部のWindowsバージョンでは、現時点ではHTTPヘッダーを介したセッショントラッキングしか実行していません。私の環境には多くのOSXがあるため、10.3、10.4、10.5、および10.6はすべて、サーバー機能の面でサポートするものを微妙に変更します。そしてもちろん、Gnomeには独自の要件があり、少数のLinuxユーザーを悩ませています。
I.ただ。できません。勝つ。
現在、IIS7からWebDAVを提供するときに、Windows 7とWinXPが正常に動作しています。多くのバールがかかりましたが、機能しています。 OSXは主に新しいバージョンで動作します。他の誰もが自分のチャンスを利用します。
Windowsでは、特定のWebDAV動詞が使用可能であると想定しています。 Win7クライアントが接続してエラーをバックトラックしようとしたときに何が得られるかを確認します。受け取っていない場合は、Windowsホストが何らかの理由で環境を好きではないことを示しています。おそらく、セッション追跡方法を変更する必要があるか、DAVホストが正しいIEセキュリティゾーンにあることを確認する必要があります。 WebDAVサーバー。
IISからWindowsクライアントにWebDAVを実行するのは簡単だと思いますが、私のように誤解されます。
私は同じ問題に遭遇し、それを解決しました。簡単に言えば、問題のいくつかの一般的な原因があります。
- dAVレスポンスの名前空間の問題
- 接続の問題
私は 私のブログ でこの問題を詳細に説明しました：
Windows 7ミニリダイレクターでダイジェスト認証が失敗する理由
2014年6月2日
ここに問題があります：WebDAVサーバーがあり、ダイジェスト認証を使用する場合、Windows 7ミニリダイレクターを除くほぼすべてのWebDAVクライアントで動作します。
確かに、ダイジェスト認証を選択し、それ自体がWindows 7ミニリダイレクターにこだわるのは議論の余地があるかもしれません。この記事では、このようなデザインオプションについては説明しません。それは私がMicrosoftのWebDAVクライアントで苦労して学んだことを共有することだけを目的としており、他の人々が将来的に代金を払わないようにしています。
Win7からWebDAVサーバーに接続する通常の方法は、Windowsエクスプローラーウィンドウを開き、ネットドライブをサーバーのURLにマップすることです。サーバーがダイジェスト認証で保護されている場合は、ユーザー名とパスワードの入力を求められます。入力して送信すると、別のボックスがポップアップ表示され、資格情報を再度要求されます。正しい資格情報を3回入力し続けると、Windowsでは試行を続けることができなくなります。
これが私が直面していた問題です。物事をより面白くするために、WebデバッガーのFiddlerが存在する場合、問題がマスクされる可能性があります。つまり、フィドラーが真ん中の人であるときはいつでも、それは機能します。そうしないと、機能しなくなります。
この記事の後半で取り上げるさまざまな方向からこの問題に取り組みましたが、すべてが問題を解決することはできませんでした。
Fiddlerに「クライアント接続を再利用する」と「サーバー接続を再利用する」という2つの接続関連オプションがあることを発見したとき、私は大きな前進でした。パフォーマンスの理由から、どちらもデフォルトでオンになっていると思います。前に説明した動作/動作しないシナリオは、Fiddlerを完全にシャットダウンせずに、[クライアント接続を再利用]をオン/オフに切り替えることで再現できます。
私のセッションの接続パターンをWindows 7クライアントとApacheの間のセッションと比較すると、特に400シリーズのHTTPステータスコード（例：401 Unauthorized）を返すと、WebDAVサーバーは常に接続をドロップすることがわかりました。修正は簡単で、401で接続を維持することで問題はすぐに解決されます。
経験豊富な開発者である私の同僚は、これはMicrosoftの古代のバグであり、12年以上存在していたが、彼らがそれを修正したことはないと言った。クライアントはTCP接続、Cを開始し、プレーンHTTPリクエストを送信します。サーバーは、ダイジェスト情報を含む「WWW-Authenicate」ヘッダーとともに401応答を生成し、それを返信しますこの特定の瞬間に、サーバーには、「接続」、「キープアライブ」ヘッダーの以前の内容に関係なく、接続を維持するか、接続をドロップするかの選択肢があります。サーバーが接続をドロップすることを決定したとしましょう、401応答がwin 7クライアントに到達すると、ダイジェスト認証に必要な「Authorization」ヘッダーが計算されますが、win 7クライアントは、以前に作成された接続Cを介してこのヘッダーを送信するように要求します。Cが壊れている場合は、新しい接続C 'を開始し、「Authorization」ヘッダーなしでプレーンリクエストを送信します。この時点で、次に何が起こるかを予測し、複数のログインの問題が発生する理由を説明できるはずです。
上記のプロセスを要約すると、Win 7クライアントは次の2つの条件の場合にのみ「Authorization」ヘッダーを送信します。1。資格情報を送信した直後、つまり「Authorization」ヘッダーが初めて作成されたとき。 2.接続は、元の単純な要求を送信して401応答を取得したときと同じ接続でした。
HTTPはステートレスプロトコルであり、クライアントもサーバーも接続ステータスなどの状態に依存するべきではありません。 WebDAVモジュールを有効にしたApacheなどの堅牢なサーバー、またはCadaverなどの堅牢なクライアントは、win 7クライアントなどの固定クライアント、または私のサーバーなどの固定サーバーに対応できます。
Digestを使用したWebDAVを正しく設定するのは困難です。これまでのところ、2つのサーバーが正しく機能することを確認しました。1つは人気のあるApache DAVモジュールで、もう1つはこのバグを修正した後のサーバーです。
勝利7 WebDAVサポートは確かに安っぽいです。顧客には他にも多くの選択肢があります。 CadaverはLinux/Unixプラットフォーム上の優れたオープンソースWebDAVクライアントであり、MacにはWebDAVサポートが組み込まれており、Cyber Duck、BitKinexなどのサードパーティクライアントはすべて適切な選択肢です。ただし、顧客の大部分が依然としてWindowsプラットフォームに依存しているために、Win7ミニリダイレクターがWebDAVサーバーにアクセスする最も便利な方法である場合でも、顧客のために機能させる必要がある場合があります。ダイジェスト認証が機能しない可能性のある他のいくつかの原因を次に示します。
- 認証ロジックが正しく実装されていないため、正しい認証情報も受け入れられません
- DAVレスポンスボディはデフォルトの名前空間を使用します。詳細については、以下のリンクを参照してください。 http://www.greenbytes.de/tech/webdav/webdav-redirector-list.html#issue-namespace-handling = https://issues.Apache.org/bugzilla/show_bug.cgi?id=49428
- 「Authentication-Info」ヘッダーを送信する場合は、必ず機能するようにしてください>すべての「Authentication-Info」ヘッダーを送信する場合は、必ず機能するようにしてください
これらすべてが役に立たない場合は、根本的な原因を探すときに役立ついくつかのアプローチを以下に示します。1. Fiddler、ngrepを使用してトラフィックをキャプチャおよび調査します。2。ベースリファレンスとしてオープンソースのクライアントとサーバーを使用します。コードを読むことでプロセスの仕組みを知ることができます。コードは十分にテストされ、信頼性があります3.視点を広げます。 HTTP通信が機能しない場合は、トラフィック（コンテンツ）、タイムアウト（タイミング）、接続（コンテキスト）などが原因である可能性があります。 4.古い事実を思い出してください。HTTPはステートレスです。追加された州に基づいて仮定を行うことはできません。5. RFCを注意深く読み、オンラインで質問することをためらわないでください。
まとめると、ダイジェスト認証はベーシックよりも強力なスキームです。 Basicは文字通り、今日のセキュリティテクノロジーに関しては保護を提供していません。ダイジェストは、中間者攻撃に対して本質的に脆弱です。どのセキュリティコンテキストを使用しているかを慎重に検討してください。
Windows WebDAVクライアントが壊れていることを除いて、WebDAVは素晴らしい働きをします。たとえば、Windowsミニリダイレクターのダイジェスト認証が壊れています。なんらかの理由で、コマンドラインからクライアントをマッピングできるようです。
次のページでこれについて詳しく説明します。 http://barracudaserver.com/products/BarracudaDrive/tutorials/mapping_windows_drive.lsp
別のWebDAVクライアントを使用するか、セッションURLを実装するBarracudaDriveなどのWebDAVサーバーを使用します。ブラウザを使用してログインし、ドライブをマッピングするときにブラウザから提供されたセッションURLを使用します。
Microsoft.comにkbがあり、URLに https://www.example.com/webdav などの子ディレクトリがあるかどうかを示しています。これはwebdavですが、親はwebdavではありませんwin7とwin server 08は、webdavではない親に対して認証を試みます。修正はここにあります： http://support.Microsoft.com/kb/2560598
このように設定すると、意図したとおりに動作することを確認しました。他のオプションは、webdavディレクトリを指す https://webdav.example.com などのwebdavサブドメインを使用することだと思います。
apacheリバースプロキシの背後にあるサーバーにhttps webdavがあります。 Windowsでwebclientサービスが開始されず、マウントが0x80070043ネットワーク名で失敗する...
これを解決するには、最初の要求vom windows Explorerの応答をリダイレクト302ではなく200 OKに書き換えます。その後、webclientが起動し、マウントが成功します。
Apacheルールの例：
RewriteEngine On
RewriteCond %{REQUEST_URI} ^(/)$ [NC]
RewriteCond %{REQUEST_METHOD} OPTIONS
RewriteRule ^(.*)$ $1 [R=200,L]
更新：2回のログインで同じ問題が発生しましたが、Apache vhost構成（リバースプロキシ上）に以下を追加することで解決しました。
DefaultType None
BitKinexは、Windows 7で自己署名証明書にwebdavを実行できる唯一のプログラムです。Cyberduckにいくつかの希望がありましたが、同じ問題があり、パスワードを2回要求し、表示されなくなりました。どうやらBitKinexの人々は、秘密結社の特定のメンバーにのみ公開されている自己署名付きのwin7 webdavのいくつかの暗い秘密を発見しました。 LOL BitKinexは素晴らしい仕事をしており、スケジューラーとすべてを持っています。
基本認証とダイジェスト認証（https経由）の両方を試しましたが、Windows 7クライアントでは何も動作しませんでした。
これまでにサードパーティのクライアントなしでWindows 7でこれを機能させる唯一の方法は、ユーザー名/パスワード認証を破棄して、クライアント証明書認証に置き換えることでした。私のディレクトリスタンザは次のようになります。
<Directory /dav/dir>
AllowOverride None
Options Indexes -Includes FollowSymLinks
DirectoryIndex None
SSLRequireSSL
SSLVerifyClient require
SSLVerifyDepth 10
SSLRequire %{SSL_CLIENT_S_DN_O} eq "Org 1" or \
(%{SSL_CLIENT_S_DN_O} eq "Org 2" and %{SSL_CLIENT_S_DN_OU} eq "Org Unit 1")
DAV On
</Directory>
SSLRequireスタンザは、独自の要件に従って 変更 にする必要があります。
これが完了したら、クライアント側に証明書をインストールします。 TinyCA2 を使用して自分の証明書を生成して配布しています。または、サードパーティの認証局を使用します。