Не обновляется репозиторий через прокси.
#1
Отправлено 19 Октябрь 2012 - 17:21
Подскажите, пожалуйста, как научить Dr.Web Enterprise Server авторизоваться в прокси-сервере ISA 2004?
Аутентификация Basic разрешена и браузеры типа Opera могут ее использовать. В логах ISA отображается сначала попытка анонимного выхода, а затем с заданым логином. А вот Dr.Web Enterprise Server даже не пытается использовать тот логин, который задан в конфигурации репозитория. Пытается использовать anonymous ему не дают и он спокойненько в своих логах пишет "407 Proxy Authentication Required". На кой ему логин и пароль для прокси дали - не ясно.
#2
Отправлено 19 Октябрь 2012 - 19:08
2. файл .config из любого подкаталога репозитория ЕС-сервера.
3. Фрагмент лога drwcsd.log уровня ALL для указанной проблемы.
И ремарк: вряд ли у вас аналогичная проблема - разница в 3 года, еще не возраст, но уже срок.
#3
Отправлено 20 Октябрь 2012 - 07:43
Прикрепленные файлы:
#4
Отправлено 22 Октябрь 2012 - 09:03
Если у вас "Secure NAT" (требуется установка файервольного клиента), то - никак. Только настраивать правила ISA.Подскажите, пожалуйста, как научить Dr.Web Enterprise Server авторизоваться в прокси-сервере ISA 2004?
P.S. Хотя, если ES-сервер уже научился NTLM-авторизации, то логины вида домен\пользователь или пользователь@fqdn - должны работать.
#5
Отправлено 22 Октябрь 2012 - 10:48
#6
Отправлено 22 Октябрь 2012 - 16:33
Чтобы мы могли попробовать вам помочь,фрагмент лога необходим с уровнем протоколирования ALL, у вас сейчас INFO.
#7
Отправлено 23 Октябрь 2012 - 07:31
Написал в ТП, отпишу чем решится.
#8
Отправлено 29 Октябрь 2012 - 19:14
Сообщение было изменено Dimasin: 29 Октябрь 2012 - 19:15
#9
Отправлено 29 Октябрь 2012 - 19:28
в Поддержку, надеюсь, тоже отправили?Прикладываю лог уровня ALL.
#10
Отправлено 29 Октябрь 2012 - 19:32
В логах прокси что? В частности, в какое именно запрещающее правило попало обращение ES-сервера?Прикладываю лог уровня ALL. Пароль АБСОЛЮТНО ТОЧНО ВЕРНЫЙ.
Файервольный клиент установлен?
#11
Отправлено 29 Октябрь 2012 - 21:07
Ни под какое. ES просто закрывает соединение. Это и без логов прокси видно.В логах прокси что? В частности, в какое именно запрещающее правило попало обращение ES-сервера?Прикладываю лог уровня ALL. Пароль АБСОЛЮТНО ТОЧНО ВЕРНЫЙ.
Файервольный клиент установлен?
Прикрепляю архив antivirus.zip с логами аутентификации браузера Opera и DrWeb ES в pcap и txt форматах (формат pcap читается, например, wireshark):
drweb_auth - попытка аутентификации через прокси DrWeb ES
opera_auth - аутентификация через прокси браузера Opera
Из логов в частности видно, что после сообщения прокси "HTTP/1.1 407 Proxy Authentication Required ( Отказано в доступе. )" Opera посылает "GET http://1c.ru/ HTTP/1.1 ...." с параметрами аутентификации и получает желаемую страничку, а drweb просто закрывает соединение.
antivirus.zip 28,68К 2 Скачано раз
#12
Отправлено 29 Октябрь 2012 - 21:08
в Поддержку, надеюсь, тоже отправили?Прикладываю лог уровня ALL.
Ага. Ответы ТП показать?
#13
Отправлено 29 Октябрь 2012 - 23:58
[вырезано цензурой]. Идите, в общем, в техподдержку, если вы такой умный.Ни под какое. ES просто закрывает соединение. Это и без логов прокси видно.
P.S. Говорю, как человек, знающий на собственном опыте разницу между авторизацией служб и приложений.
#14
Отправлено 30 Октябрь 2012 - 10:15
В качестве самого простого решения, могу предложить - если для вас методы Negotiate, Kerberos не критичны или вообще не ислользуются, отключить их, тогда прокси будет сразу работатать с методом NTLM. Или, если все-таки используете эти методы, попробовать обыграть этот нюанс правилами ISA.
#15
Отправлено 30 Октябрь 2012 - 12:07
... Это не ЕС использует Negotiate авторизацию, а прокси-сервер ожидает авторизацию в режиме Negotiate, а ЕС, к сожалению, этой версии, ее не поддерживает. Проблема в том, что после отлупа такого метода, не происходит переход к следующему методу. ...
Я понимаю несколько иначе:
- ES ломится без авторизации
- ISA говорит неа, я умею ... вот список
- ES выбирает из списка самое первое и пытается авторизоваться
Дальше мне не совсем ясно что происходит. Судя по логам авторизации браузера и антивируса до этого момента все одинаково. А вот после него, браузер запрашивает страничку и к запросу прицепляет "Proxy-Authorization: Negotiate", а ES просто закрывает соединение.
#16
Отправлено 30 Октябрь 2012 - 12:15
[вырезано цензурой]. Идите, в общем, в техподдержку, если вы такой умный. ...Ни под какое. ES просто закрывает соединение. Это и без логов прокси видно.
Извините, если что не так ответил, но это действительно очевидно.
На первый запрос без авторизации ISA говорит что анонимусам доступ запрещен. А поскольку последующего запроса, как у браузера, нет, то и в логах, соответственно, ничего.
У браузера же две строчки, первая, анонимусам доступ запрещен, и вторая, молодец drweb, проходи (это я для наглядности, попросил браузер ходить под той же учетной записью, что и ES).
#17
Отправлено 30 Октябрь 2012 - 14:57
Я понимаю несколько иначе:
- ES ломится без авторизации
- ISA говорит неа, я умею ... вот список
- ES выбирает из списка самое первое и пытается авторизоваться
Дальше мне не совсем ясно что происходит. Судя по логам авторизации браузера и антивируса до этого момента все одинаково. А вот после него, браузер запрашивает страничку и к запросу прицепляет "Proxy-Authorization: Negotiate", а ES просто закрывает соединение.
У ЕС в настройках указан прокси и аккаунт, поэтому:
- ЕС идет на прокси
- прокси вывешивает список доступных методов авторизации, в порядке ослабления надежности
- ЕС идет по первому методу из списка, им оказывается Negotiate, но увы, в 6.00.3.201111300 этот метод обламывается.
- ЕС не пытается попробовать сл. метод, и пишет в лог ошибку.
К сожалению, в ЕС 6.0.3 именно так.
Решений ровно два:
1. Приведено чуть выше
2. Обратиться в СТП, сославшись на этот топик, они должны знать, как помочь, если не знают, пусть посмотрят в емейл моего профиля и я им подскажу. Есть workaround, но без помощи СТП вам тут не обойтись.
Сообщение было изменено Foxes: 30 Октябрь 2012 - 14:58
#18
Отправлено 30 Октябрь 2012 - 20:45
... В качестве самого простого решения, могу предложить - если для вас методы Negotiate, Kerberos не критичны или вообще не ислользуются, отключить их, тогда прокси будет сразу работатать с методом NTLM. Или, если все-таки используете эти методы, попробовать обыграть этот нюанс правилами ISA.
Увы, в ISA 2004 все три метода можно либо включить, либо отключить флагом "Integrated Windows authentication".
Вот цитата из справки ISA: "Integrated Windows authentication represents NTLM, Kerberos, and Negotiate authentication mechanisms."
В ТП написал. Ответили: "информация передана в тестовую лабораторию для анализа."
Хотя, в самом первом сообщении написали: "В частности, мы поддерживаем NTLM и Basic. Потому попытка авторизоваться, например, по GSS-Negotiate как наиболее сильному алгоритму будет неуспешной."
Это класс! Мы умеем NTLM и Basic, нам предлагают на выбор Negotiate, Kerberos, NTLM и Basic. Мы знаем, что не умеем Negotiate, но все равно делаем эту попытку, обламываемся и в логи пишем: "Отказано в доступе".
Мне одно не ясно, это же ПРОГРАММА. Как ее нужно написать, чтобы она вместо метода который умеет ПЫТАЛАСЬ использовать то, что в нее не запрограммировали?
#20
Отправлено 31 Октябрь 2012 - 10:44
Читают тему: 0
0 пользователей, 0 гостей, 0 скрытых