Чудеса WebProxy на ISA Server
-
4 декабря 2009 г. 9:36
В один прекрасный день у всех системных администраторов в нашей компании перестал работать Internet Explorer (в то время мы использовали версию 7.0). Сразу мы это не заметили, т.к. многие пользовались браузером Firefox и особо никто не расстроился, когда браузер перестал открывать странички, но профессиональный интерес взял свое и мы выделили один день на исследование данного вопроса.
Проверив все правила и политики на ISA Server мы не выявили каких-либо проблем с авторизацией. Дальнейшее исследование показало, что данный феномен проявляется у любого пользователя включенного в спец. группу G Системные администраторы и только у них.
Пришлось лезть в Active Directory и внимательно изучать данную группу. Оказалось что члены этой группы имею достаточно широкие права и поэтому они являются членами множества групп. В этом и оказалась проблема!!!
Ниже я привел список ровно 50 групп членом которых является данный пользователь. При добавлении его в 51-ую группу WebProxy перестает работать.
Я очень подробно описал данную ситуацию у себя на блоге http://dimka.yz74.ru/2009/12/04/wonder-webproxy-isa-server-2006/
Но решения проблемы так и не нашел.
В чем секрет 50 групп? Почему именно 50?
И самое главное как обойти это ограничение?
Мой блог: http://dimka.yz74.ru- Изменен тип Daniil KhabarovModerator 30 марта 2010 г. 9:54
- Изменен тип Daniil KhabarovModerator 16 апреля 2010 г. 12:56
Все ответы
-
4 декабря 2009 г. 10:29ОтвечающийДмитрий, у меня в маркере пользователя 54 SID'а групп AD, при этом аутентификация на WebProxy происходит и никакого нарушения функционала не наблюдается. У меня тоже ISA 2006 SP1, аутентифкация на WebProxy - Integrated, правда, я пробовал лишь IE8.
Дмитрий, а Вы наблюдали в анализаторе трафика, как осуществляется аутентификация - с помощью NTLM или Kerberos? У Вас хост WebProxy FQDN определен (?) - в этом случае, по идее, IE7 должен Kerberos "выбирать". Т.е., если NTLM срабатывает, то подозрение - на формирование маркера на стороне ISA. Я встречался с проблемами аутентифкации на WebProxy ISA при определении его хоста IP-адресом... -
4 декабря 2009 г. 10:40Сейчас у нас тоже уже IE8, но от этого не легче.
У Вас хост WebProxy FQDN определен (?)
Что вы под этим понимаете?
Мой блог: http://dimka.yz74.ru -
4 декабря 2009 г. 10:46ОтвечающийНу, "адрес" прокси-сервера указан в браузере каким образом?..
Дмитрий, а смотрели анализатором, Kerberos или NTLM отрабатывает аутентифкацию?.. -
4 декабря 2009 г. 10:51Смотрите что получается:
ISA Server говорит: Proxy Authentication Required и предлагает на выбор: Negotiate, Kerberios, NTLM.
Клиент в ответ на это посылает верительные данные Proxy-Authorization: Negotiate.
И дальше я вижу: Packet size limited during capture SPNEGO-KRB5 truncated.
Мой блог: http://dimka.yz74.ru -
4 декабря 2009 г. 10:54
Ну, "адрес" прокси-сервера указан в браузере каким образом?..
Дмитрий, а смотрели анализатором, Kerberos или NTLM отрабатывает аутентифкацию?..
конечно в виде FQDN.
Мой блог: http://dimka.yz74.ru -
4 декабря 2009 г. 11:08Отвечающий// Packet size limited during capture
Т.е., это просто его анализатор не зхватил целиком, так что ли?..
А, может, дело в скромном MTU между IP-интерфейсом ISA?.. Может, это как-то влияет на сообщения, Kerberos, которые с длинным билетом из-за перечисления стольких SID не влезают в дейтаграмму.
Дмитрий, а попробуйте к WebProxy по IP доступаться, ну "адрес" указать его в обозревателе IP-адресом, чтобы NTLM гарантированно отработал, - проблема останется? Если уйдет, то надо либо увеличивать MTU, либо принудительно для Kerberos TCP задействовать...- Предложено в качестве ответа Dmitry PonomarevMVP, Editor 20 марта 2010 г. 21:36
-
4 декабря 2009 г. 14:40Модератор
Проблему размера пакета легко проверить как описано в статье http://support.microsoft.com/kb/244474
Сазонов Илья http://www.itcommunity.ru/blogs/sie-wl/ -
7 декабря 2009 г. 4:38
// Packet size limited during capture
Проверил с указанием IP адреса не помогло. Буду пробовать Kerberos мучать.
Т.е., это просто его анализатор не зхватил целиком, так что ли?..
А, может, дело в скромном MTU между IP-интерфейсом ISA?.. Может, это как-то влияет на сообщения, Kerberos, которые с длинным билетом из-за перечисления стольких SID не влезают в дейтаграмму.
Дмитрий, а попробуйте к WebProxy по IP доступаться, ну "адрес" указать его в обозревателе IP-адресом, чтобы NTLM гарантированно отработал, - проблема останется? Если уйдет, то надо либо увеличивать MTU, либо принудительно для Kerberos TCP задействовать...
Мой блог: http://dimka.yz74.ru -
19 марта 2010 г. 15:22Модератор
Добрый день!
И чем закончилось ворошение?
-
16 апреля 2010 г. 10:09
Добрый день!
И чем закончилось ворошение?
К счастью, нашел время заняться опять данной проблемой.
При указании IP-адреса вместо FQDN в свойствах браузера аутентификация отрабатывает нормально. При указании FQDN или NETBIOS имени ISA Server'a сайты тут же перестают открываться, аутентификация не выполняется.
При это на машине откуда осуществляется проверка я поставил MaxPacketSize=1 для задейстования Kerberos по TCP.
U:\>ping -f -l 1472 192.168.0.2 Обмен пакетами с 192.168.0.2 по с 1472 байтами данных: Ответ от 192.168.0.2: число байт=1472 время=2мс TTL=128 Ответ от 192.168.0.2: число байт=1472 время<1мс TTL=128 Ответ от 192.168.0.2: число байт=1472 время=1мс TTL=128 Ответ от 192.168.0.2: число байт=1472 время=1мс TTL=128 Статистика Ping для 192.168.0.2: Пакетов: отправлено = 4, получено = 4, потеряно = 0 (0% потерь)
т.е. MTU тоже прекрасный.
Я также прочитал еще комментарии про Kerberos в Windows Vista и получается, что она по умолчанию использует Kerberos TCP.
Мой блог: http://dimka.yz74.ru -
16 апреля 2010 г. 12:59Модератор
Уважаемый Dmitriy Yuzepchuk ,
я так понимаю,
проблема закралась с TCP пакет ? Является ли это решением вашей проблемы? -
17 апреля 2010 г. 7:44
Уважаемый Dmitriy Yuzepchuk ,
я так понимаю,
проблема закралась с TCP пакет ? Является ли это решением вашей проблемы?
Даже не знаю, проблема до сих пор не решена. Я лишь уточнил что уже используется TCP и Kerberos, а также в случае NTLM авторизация проходит успешно.
К сожалению, это пока мне не помогло решить саму проблему.
Мой блог: http://dimka.yz74.ru -
26 апреля 2010 г. 10:37
Коллеги, может у кого-нибудь есть еще мысли по данному поводу?
Я правда в растерянности.
Мой блог: http://dimka.yz74.ru -
13 мая 2010 г. 11:24У меня такая же проблема... Уже голову сломал.
-
13 мая 2010 г. 12:13
Мне удалось победить проблему, но я так и не понял, что в конченом итоге повлияло на результат.
Самое интересное, что результат работы сказался, видимо, только после нескольких перезагрузок сервера/клиента. Поэтому, я не смог понять что было решающим.
Копал я в направлении Kerberos UDP.
в качестве тест проверки попробуйте указывать IP-адрес или NETBIOS имя компьютера, чтобы понять, такая же ситуация или нет.
Мой блог: http://dimka.yz74.ru -
13 мая 2010 г. 13:29
Все анологично Вашей, описанной выше, ситуации. А чем руководствовались при решении хоть?К счастью, нашел время заняться опять данной проблемой.
При указании IP-адреса вместо FQDN в свойствах браузера аутентификация отрабатывает нормально. При указании FQDN или NETBIOS имени ISA Server'a сайты тут же перестают открываться, аутентификация не выполняется
-
14 мая 2010 г. 2:58
Попробуйте в момент обращения к внешним узлам помониторить канал между ISA и DC. У вас один DC или несколько?
Я еще вспомнил, примерно во время решения данной проблемы мы перенесли DC на новый сервер, возможно это повлияло на решение.
Мой блог: http://dimka.yz74.ru
.png){kind=spacer}
