none
Чудеса WebProxy на ISA Server RRS feed

  • Вопрос

  • В один прекрасный день у всех системных администраторов в нашей компании перестал работать 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?
    И самое главное как обойти это ограничение?
    4 декабря 2009 г. 9:36

Все ответы

  • Дмитрий, у меня в маркере пользователя 54 SID'а групп AD, при этом аутентификация на WebProxy происходит и никакого нарушения функционала не наблюдается. У меня тоже ISA 2006 SP1, аутентифкация на WebProxy - Integrated, правда, я пробовал лишь IE8.

    Дмитрий, а Вы наблюдали в анализаторе трафика, как осуществляется аутентификация - с помощью NTLM или Kerberos? У Вас хост WebProxy FQDN определен (?) - в этом случае, по идее, IE7 должен Kerberos "выбирать". Т.е., если NTLM срабатывает, то подозрение - на формирование маркера на стороне ISA. Я встречался с проблемами аутентифкации на WebProxy ISA при определении его хоста IP-адресом...
    4 декабря 2009 г. 10:29
    Отвечающий
  • Сейчас у нас тоже уже IE8, но от этого не легче.

    У Вас хост WebProxy FQDN определен (?)

    Что вы под этим понимаете?
    4 декабря 2009 г. 10:40
  • Ну, "адрес" прокси-сервера указан в браузере каким образом?..

    Дмитрий, а смотрели анализатором, Kerberos или NTLM отрабатывает аутентифкацию?..
    4 декабря 2009 г. 10:46
    Отвечающий
  • Смотрите что получается:

    ISA Server говорит: Proxy Authentication Required и предлагает на выбор: Negotiate, Kerberios, NTLM.
    Клиент в ответ на это посылает верительные данные Proxy-Authorization: Negotiate.
    И дальше я вижу: Packet size limited during capture SPNEGO-KRB5 truncated.

    4 декабря 2009 г. 10:51
  • Ну, "адрес" прокси-сервера указан в браузере каким образом?..

    Дмитрий, а смотрели анализатором, Kerberos или NTLM отрабатывает аутентифкацию?..

    конечно в виде FQDN.
    4 декабря 2009 г. 10:54
  • // Packet size limited during capture
    Т.е., это просто его анализатор не зхватил целиком, так что ли?..

    А, может, дело в скромном MTU между IP-интерфейсом ISA?.. Может, это как-то влияет на сообщения, Kerberos, которые с длинным билетом из-за перечисления стольких SID не влезают в дейтаграмму.
    Дмитрий, а попробуйте к WebProxy по IP доступаться, ну "адрес" указать его в обозревателе IP-адресом, чтобы NTLM гарантированно отработал, - проблема останется? Если уйдет, то надо либо увеличивать MTU, либо принудительно для Kerberos TCP задействовать...
    4 декабря 2009 г. 11:08
    Отвечающий
  • Проблему размера пакета легко проверить как описано  в статье http://support.microsoft.com/kb/244474


    Сазонов Илья http://www.itcommunity.ru/blogs/sie-wl/
    4 декабря 2009 г. 14:40
    Модератор
  • // Packet size limited during capture
    Т.е., это просто его анализатор не зхватил целиком, так что ли?..

    А, может, дело в скромном MTU между IP-интерфейсом ISA?.. Может, это как-то влияет на сообщения, Kerberos, которые с длинным билетом из-за перечисления стольких SID не влезают в дейтаграмму.
    Дмитрий, а попробуйте к WebProxy по IP доступаться, ну "адрес" указать его в обозревателе IP-адресом, чтобы NTLM гарантированно отработал, - проблема останется? Если уйдет, то надо либо увеличивать MTU, либо принудительно для Kerberos TCP задействовать...
    Проверил с указанием IP адреса не помогло. Буду пробовать Kerberos мучать.
    7 декабря 2009 г. 4:38
  • Добрый день!

    И чем закончилось ворошение?

    19 марта 2010 г. 15:22
    Модератор
  • Добрый день!

    И чем закончилось ворошение?

    К счастью, нашел время заняться опять данной проблемой.

    При указании 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.

    16 апреля 2010 г. 10:09
  • Уважаемый Dmitriy Yuzepchuk

    я так понимаю, Медали пользователяМедали пользователяМедали пользователяМедали пользователя проблема закралась с TCP пакет ? Является ли это решением вашей проблемы?

    16 апреля 2010 г. 12:59
    Модератор
  • Уважаемый Dmitriy Yuzepchuk

    я так понимаю, Медали пользователяМедали пользователяМедали пользователяМедали пользователяпроблема закралась с TCP пакет ? Является ли это решением вашей проблемы?

    Даже не знаю, проблема до сих пор не решена. Я лишь уточнил что уже используется TCP и Kerberos, а также в случае NTLM авторизация проходит успешно.

     

    К сожалению, это пока мне не помогло решить саму проблему.

    17 апреля 2010 г. 7:44
  • Коллеги, может у кого-нибудь есть еще мысли по данному поводу?

    Я правда в растерянности.

    26 апреля 2010 г. 10:37
  • У меня такая же проблема... Уже голову сломал.
  • Мне удалось победить проблему, но я так и не понял, что в конченом итоге повлияло на результат.

    Самое интересное, что результат работы сказался, видимо, только после нескольких перезагрузок сервера/клиента. Поэтому, я не смог понять что было решающим.

    Копал я в направлении Kerberos UDP.

    в качестве тест проверки попробуйте указывать IP-адрес или NETBIOS имя компьютера, чтобы понять, такая же ситуация или нет.

  • К счастью, нашел время заняться опять данной проблемой.

    При указании IP-адреса вместо FQDN в свойствах браузера аутентификация отрабатывает нормально. При указании FQDN или NETBIOS имени ISA Server'a сайты тут же перестают открываться, аутентификация не выполняется

    Все анологично Вашей, описанной выше, ситуации. А чем руководствовались при решении хоть?
  • Попробуйте в момент обращения к внешним узлам помониторить канал между ISA и DC. У вас один DC или несколько?

     

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