Windows 7, HTTPS WebDav: Fragt zweimal nach dem Kennwort und schlägt fehl. Problemumgehungen?

Ich habe einen Dav-Server mit PHP SabreDav ( code.google.com/p/sabredav/wiki/Windows ) auf Cherokee unter einer HTTPS-gesicherten URL. Es ist auf https eingestellt und verwendet die Digest-Authentifizierung. Ich kann mich mit mehreren Browsern und einigen Clients von Drittanbietern anmelden (BitKinex und Java AnyClient können ebenfalls eine Verbindung herstellen und surfen, siehe unten).

Wenn Sie jedoch versuchen, sich mit Windows 7 anzumelden (Überraschung, Überraschung), werden Sie zweimal nach meinem Kennwort gefragt und es wird mir mitgeteilt, dass mein Ordner ungültig ist.

• Ich habe überprüft, dass der Server die Digest-Authentifizierung verwendet.
• Ich habe mehrmals überprüft, ob Software von Drittanbietern eine Verbindung herstellen kann.
• Ich habe sogar ein GoDaddy-SSL-Zertifikat gekauft, damit mein SSL nicht mehr selbst signiert wird.
• Ich habe die Registrierungs-Hacks hier angewendet: support.microsoft.com/kb/943280 (Beachten Sie, dass der Artikel besagt, dass das "Update" bereits für Windows 7 vorhanden ist. Ich benötige nur magische Registrierungs-Hacks, damit es funktioniert.)
• Ich habe die Registrierungshacks hier angewendet: support.microsoft.com/kb/941050
• Ich habe die Registrierungshacks hier angewendet: support.microsoft.com/kb/841215 (Erlaubt angeblich Basic Auth, was nicht zutreffen sollte, aber warum nicht?)

Alles ohne Erfolg; Windows fragt weiterhin zweimal nach meinem Kennwort und gibt dann an, dass "Der von Ihnen eingegebene Ordner nicht gültig zu sein scheint. Bitte wählen Sie einen anderen aus."

Versuchen Sie die Befehlszeile? Sicher:

• Ich habe versucht, mit NET USE " https://dav.example.com/ " Passwort / USER: me (Systemfehler 59) zuzugreifen.
• Ich habe versucht, mit NET USE " https://dav.example.com/ " zuzugreifen (Systemfehler 1790)
• Ich habe versucht, mit NET USE " https://dav.example.com/subdir/ " Passwort / USER: me (Systemfehler 59) zuzugreifen.
• Ich habe versucht, mit NET USE " https://dav.example.com/subdir/ " zuzugreifen (Systemfehler 1790)
• Für viel Glück: ping dav.example.com ... funktioniert. Auch hier können Webbrowser problemlos auf die Freigabe zugreifen, ebenso Tools von Drittanbietern.

Das Beste, was ich an dieser Stelle sagen kann, ist "HAHA, KEIN WEBDAV FÜR SIE AUF WINDOWS 7", was in Ordnung wäre, außer jeder, der diese Anwendung verwendet ... verwendet Windows 7. Und die meisten sind nicht so hartnäckig oder kämpferisch wie ich.

Ich habe das Gefühl, dass ich jeden zufälligen Vorschlag, den ich irgendwo auf den ersten 10 Seiten von Google gefunden habe, in jedem Suchbegriff durchgebrannt habe, den ich mir vorstellen kann. Irgendwelche Ideen? Ich brauche es Webdav, ich muss es über HTTPS sein, und ich brauche wirklich eine Methode, um von Windows 7 darauf zuzugreifen.

ZUSÄTZLICHES DETAIL:

Die "Drittanbieter" -Programme, die ich ausprobiert habe, waren entweder fehlerhaft, unvollständig oder haben dumme ... "Pannen". Beispielsweise scheint BitKinex alle gesendeten http-Fehlercodes zu korrigieren. Wenn also ein Fehler beim Lesen eines Verzeichnisses (BAM) auftritt, wird dieses Verzeichnis immer leer aufgeführt. Lange Verzeichnislisten werden ebenfalls leer angezeigt, obwohl im Übertragungsfenster angezeigt wird, dass die Verzeichnisliste noch stattfindet.

In jedem Fall ist BitKinex aus den oben genannten Gründen für Entwicklungszwecke unbrauchbar. Und außerdem baue ich dies für andere Leute als mich selbst, Leute, die wollen, dass dieser Dav-Anteil "normal" funktioniert.

Ich hasse WebDAV.

Ich habe mir diesen Hass verdient, als ich WebDAV-Unterstützung für meinen File Serving-Cluster erhalten habe. Dies basiert auf Server 2008 / IIS7 mit dem WebDAV-Plugin für IIS. Es ist klobig und jeder einzelne WebDAV-Client erwartet, mit dem WebDAV-Server über eine eigene Mischung aus Folgendem kommunizieren zu können:

• Transportmechanismus : HTTP oder HTTPS
• Sitzungsverfolgung : Cookies oder HTTP-Header
• Authentifizierung : Standard-, Digest-, Kerberos- oder NTLM-Authentifizierung
• Benutzerdefinierte Portunterstützung kann enthalten sein oder nicht.
• Die Möglichkeit, eine Verbindung zu einem Stammverzeichnis herzustellen, kann vorhanden sein oder nicht. WinXP kann sicherlich keine Verbindung herstellen http://davhost.example.com/, es muss eine Verbindung herstellenhttp://davhost.example.com/root/

WinXP und Win7 verhalten sich unterschiedlich. Frühe WinXP-Versionen können HTTPS überhaupt nicht gut sprechen. Einige Windows-Versionen, die ich im Moment vergessen habe, haben nur die Sitzungsverfolgung über HTTP-Header durchgeführt. Da ich viel OSX in meiner Umgebung habe, ändern 10.3, 10.4, 10.5 und 10.6 auf subtile Weise, was sie in Bezug auf die Serverfunktionen unterstützen. Und natürlich hat Gnome seine eigenen Anforderungen, die unsere wenigen Linux-Benutzer plagen.

Ich habe gerade. Kippen. Sieg.

Im Moment funktionieren Windows 7 und WinXP einwandfrei, wenn WebDAV über IIS7 bereitgestellt wird. Es hat viel Brechstange gekostet, aber es funktioniert. OSX funktioniert hauptsächlich für neuere Versionen. Alle anderen gehen ihr Risiko ein.

Windows erwartet, dass bestimmte WebDAV-Verben verfügbar sind. Überprüfen Sie, was Ihre Win7-Clients erhalten, wenn sie versuchen, eine Verbindung herzustellen und den Fehler zurückzuverfolgen. Wenn sie keine bekommen, ist dies ein Zeichen dafür, dass der Windows-Host die Umgebung aus irgendeinem Grund nicht mag. Möglicherweise müssen Sie die Sitzungsverfolgungsmethoden ändern oder sicherstellen, dass sich Ihre DAV-Hosts in der richtigen IE-Sicherheitszone befinden. Durch das Betrachten der Zugriffsprotokolle konnte ich zurückverfolgen, was Windows von einem WebDAV-Server erwartet hatte.

Sie würden denken, dass es einfach wäre, WebDAV über IIS auf Windows-Clients auszuführen, aber Sie würden sich wie ich irren.

WebDAV funktioniert hervorragend, außer dass die Windows-WebDAV-Clients defekt sind. Beispielsweise ist die Digest-Authentifizierung des Windows Mini Redirector fehlerhaft. Aus irgendeinem Grund scheint es möglich zu sein, den Client über die Befehlszeile zuzuordnen.

Auf der folgenden Seite wird dies ausführlich erläutert: http://barracudaserver.com/products/BarracudaDrive/tutorials/mapping_windows_drive.lsp

Verwenden Sie einen anderen WebDAV-Client oder einen WebDAV-Server wie BarracudaDrive, der Sitzungs-URLs implementiert. Sie melden sich mit einem Browser an und verwenden die vom Browser bereitgestellte Sitzungs-URL, wenn Sie das Laufwerk zuordnen.

Ich bin auf dasselbe Problem gestoßen und habe es gelöst. Einfach ausgedrückt gibt es mehrere häufige Ursachen für das Problem.

1. dav Antwort Namespace Problem
2. Verbindungsprobleme

Ich habe dieses Problem in meinem Blog ausführlich erklärt :

Warum die Digest-Authentifizierung in Windows 7 Mini-Redirector fehlschlägt

2. Juni 2014

Hier ist das Problem: Sie haben einen WebDAV-Server, der mit fast allen WebDAV-Clients außer Windows 7 Mini-Redirector funktioniert, wenn die Digest-Authentifizierung verwendet wird.

Zugegeben, warum die Wahl der Digest-Authentifizierung und das Festhalten an Windows 7 Mini-Redirector an sich eine Debatte sein könnte. In diesem Artikel werden solche Entwurfsoptionen nicht behandelt. Es soll nur mitteilen, was ich im Kampf mit dem WebDAV-Client von Microsoft gelernt habe, damit andere Leute den Preis in Zukunft nicht mehr zahlen.

Die übliche Möglichkeit, von Win7 aus eine Verbindung zu einem WebDAV-Server herzustellen, besteht darin, ein Windows Explorer-Fenster zu öffnen und der URL des Servers ein Netzlaufwerk zuzuordnen. Wenn der Server durch Digest-Authentifizierung geschützt ist, werden Sie aufgefordert, Ihren Benutzernamen und Ihr Kennwort einzugeben. Sie geben ein, senden es und es erscheint ein weiteres Feld, in dem Sie erneut nach Anmeldeinformationen gefragt werden. Sie geben dreimal die richtigen Anmeldeinformationen ein, und Windows lässt Sie nicht weiter versuchen.

Dies ist das Problem, mit dem ich konfrontiert war. Um die Sache interessanter zu machen, könnte das Problem maskiert werden, wenn Fiddler, der Web-Debugger, vorhanden ist. Das heißt, wann immer Fiddler der Mann in der Mitte ist, funktioniert es; Andernfalls funktioniert es nicht mehr.

Ich habe versucht, dieses Problem aus vielen Richtungen anzugehen, die ich später in diesem Beitrag behandeln werde, aber alle haben das Problem nicht gelöst.

Ich war ein großer Schritt vorwärts, als ich herausfand, dass Fiddler zwei verbindungsbezogene Optionen hat: "Client-Verbindung wiederverwenden" und "Server-Verbindung wiederverwenden". Beide sind aus Leistungsgründen standardmäßig aktiviert. Die zuvor beschriebenen Arbeits- / Nicht-Arbeitsszenarien können reproduziert werden, indem „Client-Verbindung wiederverwenden“ ein- und ausgeschaltet wird, ohne den Fiddler vollständig herunterzufahren.

Beim Vergleich der Verbindungsmuster meiner Sitzung mit der Sitzung zwischen Win 7-Client und Apache stellte sich heraus, dass mein WebDAV-Server die Verbindung immer trennt, insbesondere wenn 400 HTTP-Statuscode-Serien zurückgegeben werden, z. B. 401 Unauthorized. Die Lösung ist einfach: Wenn Sie die Verbindung bei 401 am Leben erhalten, wird das Problem sofort behoben.

Mein Kollege, ein erfahrener Entwickler, sagte mir, dies sei ein uralter Fehler von Microsoft, der seit über 12 Jahren besteht, aber nie behoben wurde. Der Client startet eine TCP-Verbindung, C, und sendet dann eine einfache HTTP-Anforderung. Der Server generiert eine 401-Antwort zusammen mit dem Header "WWW-Authenicate", einschließlich der Digest-Informationen, und sendet sie an den Client zurück. In diesem bestimmten Moment hat der Server die Wahl, die Verbindung entweder am Leben zu halten oder zu trennen, unabhängig davon, was der Header "Verbindung", "Keep-Alive" zuvor sagt. Angenommen, der Server hat beschlossen, die Verbindung zu trennen. Wenn die 401-Antwort an den Win 7-Client gesendet wird, wird ein für die Digest-Authentifizierung erforderlicher "Authorization" -Header berechnet. Der Win 7-Client besteht jedoch darauf, diesen Header über die zuvor erstellte Verbindung C weiterzuleiten , wenn C gebrochen ist, Es wird eine neue Verbindung gestartet, C ', eine einfache Anfrage OHNE den Header "Authorization" senden. An diesem Punkt sollten Sie in der Lage sein, vorherzusagen, was als nächstes passieren wird, und zu erklären, warum die Probleme mit mehreren Anmeldungen jemals auftreten.

Um den obigen Vorgang zusammenzufassen, sendet der Win 7-Client NUR den Header "Authorization" unter zwei Bedingungen: 1. Unmittelbar nach dem Absenden der Anmeldeinformationen, dh als der Header "Authorization" zum ersten Mal erstellt wurde. 2. Die Verbindung war dieselbe Verbindung, über die die ursprüngliche einfache Anfrage gesendet und die 401-Antwort erhalten wurde.

HTTP ist ein zustandsloses Protokoll. Weder Client noch Server sollten sich auf Zustände wie den Verbindungsstatus verlassen. Ein robuster Server wie Apache mit aktiviertem WebDAV-Modul oder ein robuster Client wie Cadaver können mit einem starren Client wie dem Win 7-Client oder einem starren Server wie meinem Server umgehen.

WebDAV mit Digest ist schwer zu korrigieren. Ich habe bisher nur zwei Server gesehen, von denen einer das beliebte Apache DAV-Modul ist. Der andere ist mein Server, nachdem dieser Fehler behoben wurde.

Win 7 WebDAV-Unterstützung ist in der Tat beschissen. Es gibt viele andere Möglichkeiten für Ihre Kunden. Cadaver ist ein ausgezeichneter Open-Source-WebDAV-Client auf Linux / Unix-Plattformen, Mac verfügt über integrierte WebDAV-Unterstützung und Clients von Drittanbietern wie Cyber ​​Duck, BitKinex usw. sind eine gute Wahl. Wenn sich jedoch ein großer Teil Ihrer Kunden immer noch auf die Windows-Plattform verlässt und Win7 Mini-Redirector immer noch die bequemste Möglichkeit ist, auf ihren WebDAV-Server zuzugreifen, müssen Sie ihn möglicherweise noch für die Kunden verwenden. Hier sind einige andere mögliche Ursachen dafür, dass die Digest-Authentifizierung nicht funktioniert.

1. Ihre Authentifizierungslogik ist falsch implementiert, sodass nicht einmal korrekte Anmeldeinformationen akzeptiert werden
2. Der DAV-Antworttext verwendet den Standard-Namespace. Weitere Informationen finden Sie unter den folgenden Links: http://www.greenbytes.de/tech/webdav/webdav-redirector-list.html#issue-namespace-handling https: // Probleme. apache.org/bugzilla/show_bug.cgi?id=49428
3. Wenn Sie den Header "Authentication-Info" senden, stellen Sie sicher, dass er funktioniert. Wenn> alle Header "Authentication-Info" senden, stellen Sie sicher, dass er funktioniert

Wenn Ihnen all dies nicht hilft, sind hier einige Ansätze aufgeführt, die ich bei der Suche nach der Grundursache als nützlich empfunden habe: 1. Verwenden Sie Fiddler, ngrep, um den Datenverkehr zu erfassen und zu untersuchen. 2. Verwenden Sie Open Source-Clients und -Server als Basisreferenz. Sie können die Maschinerie des Prozesses kennen, indem Sie den Code lesen. Der Code ist gut getestet und zuverlässig. 3. Erweitern Sie Ihre Perspektiven. Wenn die HTTP-Kommunikation nicht funktioniert, kann dies an Datenverkehr (Inhalt), Zeitüberschreitung (Timing), Verbindung (Kontext) usw. Liegen. 4. Denken Sie an die alte Tatsache: HTTP ist zustandslos. Aufgrund der hinzugefügten Zustände sollten keine Annahmen getroffen werden. 5. Lesen Sie den RFC sorgfältig durch und zögern Sie nicht, online Fragen zu stellen

Zum Abschluss ist die Digest-Authentifizierung ein stärkeres Schema als Basic. Basic bietet buchstäblich keinen Schutz in Bezug auf die heutigen Sicherheitstechnologien und Digest ist von Natur aus anfällig für Menschen im mittleren Angriff. Bitte überlegen Sie genau, in welchem ​​Sicherheitskontext Sie sie verwenden.

Auf microsoft.com gibt es eine KB, die angibt, ob die URL ein untergeordnetes Verzeichnis wie https://www.example.com/webdav enthält , das ein Webdav ist, das übergeordnete Verzeichnis jedoch kein Webdav Win7 ist, und Win Server 08 versucht es um sich gegen das übergeordnete Element zu authentifizieren, das KEIN Webdav ist. Das Update finden Sie hier: http://support.microsoft.com/kb/2560598

Ich habe bestätigt, dass es wie vorgesehen funktioniert, wenn es auf diese Weise eingerichtet wird. Ich denke, die andere Option wäre die Verwendung einer Webdav-Subdomain wie https://webdav.example.com , die auf Ihr Webdav-Verzeichnis verweist.

BitKinex ist das einzige Programm, das ich gefunden habe und das Webdav für ein selbstsigniertes Zertifikat unter Windows 7 ausführt. Ich hatte einige Hoffnungen auf Cyberduck, stellte jedoch fest, dass es das gleiche Problem hat, zweimal nach dem Kennwort fragt und stirbt. Anscheinend haben die BitKinex-Leute ein tiefes dunkles Geheimnis von win7 webdav mit Selbstsignierung entdeckt, das nur bestimmten Mitgliedern der Geheimbünde bekannt gegeben wird. LOL BitKinex macht den Job großartig und hat Scheduler und alles.

Ich habe sowohl die Basis- als auch die Digest-Authentifizierung (über https) ausprobiert und konnte mit einem Windows 7-Client nichts erreichen.

Die einzige Möglichkeit, die ich bisher unter Windows 7 ohne einen Client eines Drittanbieters zum Laufen gebracht habe, bestand darin, die Authentifizierung mit Benutzername / Kennwort aufzugeben und durch die Authentifizierung mit Clientzertifikaten zu ersetzen. Meine Verzeichnis-Zeilengruppe sieht jetzt so aus:

<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>

Die Zeilengruppe SSLRequire sollte gemäß Ihren eigenen Anforderungen geändert werden.

Installieren Sie anschließend ein Zertifikat auf der Clientseite. Ich generiere und verteile meine eigenen Zertifikate mit TinyCA2 . Oder verwenden Sie einfach eine Zertifizierungsstelle eines Drittanbieters.

Wir haben ein https-Webdav auf einem Server hinter einem Apache-Reverse-Proxy. und der Webclient-Dienst unter Windows wird nicht gestartet. Die Bereitstellung schlägt mit dem Netzwerknamen 0x80070043 fehl ...

Wir haben dies gelöst, indem wir die Antwort der ersten Anfrage vom Windows Explorer auf 200 OK anstelle einer Umleitung 302 umgeschrieben haben. Dann wird der Webclient gestartet und die Bereitstellung ist erfolgreich.

Beispiel für Apache-Regeln:

RewriteEngine On
RewriteCond %{REQUEST_URI} ^(/)$ [NC]
RewriteCond %{REQUEST_METHOD} OPTIONS
RewriteRule ^(.*)$ $1 [R=200,L]

Update: Wir hatten das gleiche Problem mit zweimaligen Anmeldungen und ich habe es gelöst, indem ich der Apache vhost-Konfiguration (auf dem Reverse-Proxy) Folgendes hinzugefügt habe:

DefaultType None