Windows 7, HTTPS WebDav: дважды запрашивает пароль и не работает. Есть обходные пути?

Я ненавижу WebDAV.

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

• Транспортный механизм: HTTP или HTTPS
• Отслеживание сессии: куки или 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.

Я просто. Не могу. Выиграть.

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

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

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

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

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

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

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

2 июня 2014 г.

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

Следует признать, что выбор Digest Authentication и использование мини-перенаправителя Windows 7 само по себе может быть спорным. В этой статье не обсуждаются такие варианты дизайна, как этот. Его цель - поделиться тем, что я узнал, борясь с клиентом Microsoft WebDAV, чтобы другие люди не заплатили цену в будущем.

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

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

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

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

Сравнивая шаблоны соединения моего сеанса с сеансом между клиентом Win 7 и Apache, выяснилось, что различие заключается в том, что мой сервер WebDAV всегда разрывает соединение, особенно при возврате кода состояния HTTP серии 400, например 401 Unauthorized. Исправление простое, поддержание связи на 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 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 и не стесняйтесь задавать вопросы онлайн.

В заключение, Digest Authentication - это схема, более надежная, чем Basic. Basic буквально не обеспечивает защиты с точки зрения современных технологий безопасности, а Digest по своей природе уязвим для человека в средней атаке. Пожалуйста, тщательно продумайте, в каком контексте безопасности вы их используете.

WebDAV прекрасно работает, за исключением того, что клиенты Windows WebDAV не работают. Например, дайджест-проверка подлинности мини-перенаправителя Windows нарушена. Почему-то кажется, что можно сопоставить клиента из командной строки.

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

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

На microsoft.com есть КБ, который говорит, что если в URL есть дочерний каталог, такой как https://www.example.com/webdav который является webdav, но родитель не является win7 webdav, и сервер win 08 попытается аутентифицироваться против родителя, который НЕ является webdav. исправление здесь: http://support.microsoft.com/kb/2560598

Я подтвердил, что он работает как задумано, если настроен таким образом. Я думаю, что другой вариант будет использовать поддомен webdav, такой как https://webdav.example.com/ который указывает на ваш каталог webdav.

Я пробовал как базовую, так и дайджест-проверку подлинности (через 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. Или просто используйте сторонний центр сертификации.

У нас есть https webdav на сервере за обратным прокси-сервером Apache. и служба webclient на 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

BitKinex - единственная программа, которую я обнаружил, которая будет использовать webdav для самозаверяющего сертификата в Windows 7. У меня были некоторые надежды на Cyberduck, но я обнаружил, что у него та же проблема, дважды запрашивает пароль и умирает. По-видимому, ребята из BitKinex обнаружили какой-то глубокий темный секрет win7 webdav с собственной подписью, который раздается только некоторым членам тайных обществ. LOL BitKinex отлично справляется с работой, имеет планировщики и все остальное.