Windows 7, HTTPS WebDav: Просит пароль дважды и сбои. Какие-либо обходные решения?

Я ненавижу WebDAV.

Я заработал эту ненависть во время процесса получения поддержки WebDAV на мой кластер Обслуживания файлов. Это основано на Сервере 2008 / IIS7 с плагином WebDAV для IIS. Это неуклюже, и каждый отдельный клиент WebDAV там ожидает мочь говорить с сервером WebDAV по их собственному соединению следующего:

• Транспортный механизм: HTTP или HTTPS
• Отслеживание сессии: Cookie или HTTP-заголовки
• Аутентификация: Основной, Обзор, 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. Просто. Не может. Победа.

Прямо сейчас у меня есть Windows 7 и WinXP, работающий просто великолепно при обслуживании WebDAV из IIS7. Потребовалось много лома, но это работает. OSX работает главным образом на более новые версии. Все остальные рискуют.

Windows ожидает, что определенные глаголы WebDAV будут доступны. Проверьте то, что получают Ваши клиенты Win7, когда они пытаются соединить и отследить в обратном порядке ошибку. Если они не добираются один, это - знак, что хосту Windows не нравится среда по некоторым причинам; возможно, необходимо изменить отслеживающие сессию методы, или необходимо удостовериться, что хосты DAV находятся в корректной Зоне безопасности IE. Рассмотрение журналов доступа - то, что позволило мне отслеживать в обратном порядке то, что Windows ожидал от сервера WebDAV.

Вы думали бы, что выполнение WebDAV из IIS клиентам Windows будет просто, но Вы ошиблись бы как я.

WebDAV работает отлично, за исключением этого, клиенты окон WebDAV повреждаются. Например, Windows Mini Redirector's Digest authentication повреждается. По некоторым причинам кажется, что возможно отобразить клиент из командной строки.

Следующая страница объясняет это подробно: http://barracudaserver.com/products/BarracudaDrive/tutorials/mapping_windows_drive.lsp

Используйте другой клиент WebDAV или используйте сервер WebDAV, такой как BarracudaDrive, который реализует URL сессии. Вы входите в использование браузера и используете URL сессии, обеспеченный браузером при подключении диска.

BitKinex является единственной программой, я нашел, что это сделает webdav к сам подписанный сертификат на окнах 7. Я имел некоторые надежды на Киберутку, но нашел, что она имеет ту же проблему, подсказки для пароля вдвое больше и умирает. По-видимому, люди 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 . Или просто воспользуйтесь сторонним центром сертификации.

На 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.

Я столкнулся с той же проблемой и решил ее. Проще говоря, есть несколько распространенных причин проблемы.

1. проблема пространства имен ответов dav
2. проблема с подключением

Я подробно объяснил эту проблему в моем блоге :

Почему дайджест-аутентификация не выполняется в мини-перенаправителе Windows 7

ИЮНЬ 2-ОЕ, 2014

Вот проблема: у вас есть сервер WebDAV, он работает с почти все клиенты WebDAV, кроме мини-перенаправителя Windows 7 при использовании Дайджест-аутентификация.

По общему признанию, зачем выбирать дайджест-аутентификацию и придерживаться Мини-редиректор Windows 7 сам по себе может вызывать споры. Эта статья не обсуждает такие варианты дизайна, как этот. Он направлен только на поделитесь тем, что я узнал, борясь с клиентом Microsoft WebDAV так что другие люди не будут платить за это в будущем.

Обычный способ подключения к серверу WebDAV из Win7 - открыть В окне проводника Windows сопоставьте сетевой диск с URL-адресом сервера. Если сервер защищен дайджест-аутентификацией, вам будет предложено для ввода вашего логина и пароля. Вы вводите, отправляете, и он появляется еще один ящик, снова запрашивая учетные данные. Вы продолжаете набирать правильные учетные данные 3 раза, и Windows не позволит вам сохранить пытаюсь.

Это проблема, с которой я столкнулся. Делая вещи более интересными, проблема может быть замаскирована, когда присутствует Fiddler веб-отладчик. Который иными словами, когда Скрипач находится посередине, это работает; в противном случае он перестанет работать.

Я пытался подойти к этой проблеме со многих сторон, которые я буду обложку позже в этом посте, но все не решило проблему.

Я сделал большой шаг вперед, когда обнаружил, что у Fiddler есть два параметры, связанные с подключением: «Повторное использование клиентского подключения» и «Повторное использование подключение к серверу », оба включены по умолчанию для обеспечения производительности причина, я полагаю. Описанные мною рабочие / неработающие сценарии ранее можно было воспроизвести с помощью переключателя «Повторное использование клиентского соединения» включения / выключения, не закрывая полностью Fiddler.

Путем сравнения шаблонов подключения моего сеанса с сеансом между клиентом Win 7 и Apache разница оказалась в том, что мой сервер WebDAV всегда разрывает соединение, особенно при возвращает 400 серий кода состояния HTTP, например 401 Несанкционированный. Исправление простое, поддерживая соединение после 401 решает проблему немедленно.

Мой коллега, опытный разработчик, сказал мне, что это древняя ошибка Microsoft, которая существовала более 12 лет, но так и не исправила. Клиент запускает TCP-соединение, C, а затем отправляет простой HTTP запрос, сервер сгенерирует ответ 401 вместе с Заголовок «WWW-Authenicate», включая информацию дайджеста, отправляет его обратно к клиенту. В данный момент на сервере есть возможность либо сохранить соединение, либо разорвать его, независимо от того, о чем говорилось ранее в заголовках «Соединение», «Сохранение активности». Скажите сервер решил разорвать соединение, когда ответ 401 дойдет до клиент Win 7, он вычислит заголовок «Авторизация», необходимый для Однако дайджест-аутентификация, клиент win 7 настаивает на отправке этого заголовок через соединение C, созданное ранее, если C не работает, он запустит новое соединение, C ', отправит простой запрос БЕЗ Заголовок «Авторизация». На этом этапе вы сможете предсказать что будет дальше, и объяснить, почему множественный вход проблемы существуют когда-либо.

Подводя итог описанному выше процессу, клиент Win 7 будет ТОЛЬКО отправлять Заголовок «Авторизация» при двух условиях: 1. сразу после отправки учетные данные, т.е. когда заголовок «Авторизация» был создан, первый раз; 2. соединение было тем же соединением, через которое оно отправил исходный простой запрос и получил ответ 401.

HTTP - это протокол без сохранения состояния, ни клиент, ни сервер не должны полагаться на любые состояния, такие как статус подключения. Надежный сервер, такой как Apache с включенным модулем WebDAV или надежный клиент, такой как Cadaver способен справиться с жестким клиентом, таким как клиент win 7 или жестким сервер, такой как мой сервер.

WebDAV с Digest трудно понять, я видел только два сервера, сделанные это прямо сейчас, один - популярный модуль Apache DAV, другой - мой сервер после исправления этой ошибки.

Win 7 WebDAV действительно плохая поддержка. Есть много других вариантов для ваших клиентов. Cadaver - отличный клиент WebDAV с открытым исходным кодом на платформах Linux / Unix Mac имеет встроенную поддержку WebDAV, а третье такие клиенты для вечеринок, как Cyber ​​Duck, BitKinex и т. д., являются хорошим выбором. Однако, если большая часть ваших клиентов все еще полагается на Платформа Windows, таким образом, мини-перенаправитель Win7 по-прежнему остается их самой удобный способ доступа к их серверу WebDAV, вам все равно может потребоваться заставить его работать на клиентов. Вот еще несколько возможных причин что дайджест-аутентификация не работает.

1. Ваша логика аутентификации реализована неправильно, поэтому она не принимает даже правильные учетные данные
2. В теле ответа DAV используется пространство имен по умолчанию, обратитесь к ссылкам ниже для получения дополнительной информации: http://www.greenbytes.de/tech/webdav/webdav-redirector-list.html#issue-namespace-handling https://issues.apache.org/bugzilla/show_bug.cgi?id = 49428
3. Если вы отправляете заголовок «Authentication-Info», убедитесь, что он работает. Если> все отправляют заголовок «Authentication-Info», убедитесь, что он работает

Если все из них вам не поможет, вот несколько подходов, которые я нашел полезными при поиске основной причины: 1. Используйте Fiddler, ngrep для захвата и изучать трафик 2. Использовать клиенты и серверы с открытым исходным кодом как основу ссылка. Вы можете узнать механизм процесса, прочитав код; код хорошо протестирован и надежен 3. Расширьте свой перспективы. Если соединение HTTP не работает, причина может быть в трафик (контент), тайм-аут (время), соединение (контекст) и т. д. 4. Помните старый факт: HTTP не имеет состояния. Не следует делать никаких предположений на основе добавленных состояний 5. Внимательно прочтите RFC и не не стесняйтесь задавать вопросы в Интернете

Подводя итог, дайджест-аутентификация - это схема, более сильная, чем базовая. Базовый буквально не обеспечивает защиты с точки зрения сегодняшней безопасности технологии и дайджест по своей природе уязвимы для человека посередине атака. Пожалуйста, подумайте, какой контекст безопасности вы используете их в.

у нас есть https webdav на сервере за обратным прокси-сервером Apache. и служба веб-клиента в Windows не запускается, сбой при монтировании с сетевым именем 0x80070043 ...

мы решили эту проблему, переписав ответ первого запроса vom windows explorer на 200 OK вместо перенаправления 302. Затем веб-клиент запустится и установка выполнена успешно.

пример правил apache:

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

Обновление: у нас была такая же проблема с двойным входом, и я решил ее, добавив в конфигурацию Apache vhost (на обратном прокси) следующее:

DefaultType None