locked
Избежать запроса логина-пароля в Outlook при работе через прокси-сервер. (Повтор) RRS feed

  • Вопрос

  • Можно как-то? Если да, то как...
    • Перемещено Hengzhe Li 18 марта 2012 г. 7:26 forum merge (От:Exchange Server 2007)
    6 июня 2007 г. 6:29

Все ответы

  • Какой прокси? Какой протокол для работы Outlook? Какой пароль запрашивать и в какой форме? Кто здесь, вообще? =))))

    Телепаты на форуме зарегистрированы, но они в бессрочном отпуске =)

    6 июня 2007 г. 6:43
  • Можно. Используя NTLM аутентификацию как на стороне клиента, так и на стороне прокси-севрера
    6 июня 2007 г. 7:02
  • И еще раз отвечаю. на Outlook стоит NTLM- авторизация (в настройках прокси), на IIS стоит Windows-based авторизация (Для чистоты даже убил Form-Based Authentication на owa). Результат - запрос логина и пароля.

    6 июня 2007 г. 12:54
  •  Alexander Trofimov написано:

    Какой прокси? Какой протокол для работы Outlook? Какой пароль запрашивать и в какой форме? Кто здесь, вообще? =))))

    Телепаты на форуме зарегистрированы, но они в бессрочном отпуске =)

     По пунктам...

    В Outlook появилась поддержка какого-то еще прокси кроме http-прокси? Круто... где?

    Ну если через прокси то вестимо rpc over http. Или во что там его переименовали

    Пароль пользователя. Чей же еще? Окошко такое выскакивает, введите логин и пароль.

    Я.

    Почему в отпуске - вот Павел на месте.

    PS

    Вообще я знаю только одну конфигурацию при которой Outlook запрашивает логин-пароль на вход (это использование rpc-over-http). Можно услышать о других?

     

    6 июня 2007 г. 13:15
  • Поменьше сарказма, уважаемый. Через прокси, при желании можно работать и по pop3/smtp. Откуда я знаю какие там тараканы у Вас в сети?

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

    6 июня 2007 г. 13:36
  • Ну не надо сразу обижатся так....

    Просто данная тема всплывает раз в месяц со времен появления rpc-over-http. Я с ней еще в 2003-ем бился и ничего сделать не смог. Еще раз условия:

    Outlook 2007 на доменной машине под доменным юзером. Цепляется из Инета через http-прокси. В настройках прокси стоит NTLM-авторизация. В настройках owa (и всех остальных каталогов IIS) Windows-based authentification. После каждого запуска получаем запрос на логин-пароль (точно такой же как если лезть из Инета на owa при выключенной Form-based authentification). Ставим галку save password но она не помогает. Пароли по 10 символов. Куда еще можно копать?

    7 июня 2007 г. 5:54
  •  DonAlPatino написано:
     

    В Outlook появилась поддержка какого-то еще прокси кроме http-прокси? Круто... где?

    Так... за подобное нужно наказывать.

    А что, в Outlook появилась поддержка http-прокси? Круто... где?

    Задание на дом: взять чистый лист бумаги и 50 раз на нем написать: "Я обещаю разобраться, чем RPC proxy отличается от HTTP proxy, и больше не умничать на публичных форумах".

    7 июня 2007 г. 5:54
  •  Jоker написано:
     DonAlPatino написано:
     

    В Outlook появилась поддержка какого-то еще прокси кроме http-прокси? Круто... где?

    Так... за подобное нужно наказывать.

    А что, в Outlook появилась поддержка http-прокси? Круто... где?

    Задание на дом: взять чистый лист бумаги и 50 раз на нем написать: "Я обещаю разобраться, чем RPC proxy отличается от HTTP proxy, и больше не умничать на публичных форумах".

    "Connect to my Exchange mailbox using http" не я придумал. Давайте не впадать в терминологический маразм. Все ведь поняли о чем я говорю? Или в лучших традициях оракловых форумов "нетриждысертифицированным" специалистам вход воспрещен?

    Ну так и скажите - больше спрашивать ну буду.

    7 июня 2007 г. 5:58
  •  DonAlPatino написано:

    Outlook 2007 на доменной машине под доменным юзером. Цепляется из Инета через http-прокси. В настройках прокси стоит NTLM-авторизация. В настройках owa (и всех остальных каталогов IIS) Windows-based authentification. После каждого запуска получаем запрос на логин-пароль (точно такой же как если лезть из Инета на owa при выключенной Form-based authentification). Ставим галку save password но она не помогает. Пароли по 10 символов. Куда еще можно копать?

    Используется ли ISA сервер? (Я надеюсь, что у Вас Outlook не цепляется напрямую к CAS, выставленному в Интернет...) Если да, как настроен listener и как настроено правило публикации (authentication delegation)? Попробуйте изменить настройки на no authentication и no delegation but client can authenticate directly и посмотрите, изменится ли что-нибудь. Если есть возможность, проверьте, может ли тот же самый клиент подключиться к CAS напрямую.

    При правильных настройках в соответствии с документацией все работает без всяких запросов логинов/паролей (при условии, что клиентская машина является членом домена). Этим пользуются миллионы людей, так что вряд ли на стороне Microsoft имеется ошибка, она скорее имеется на стороне Вашей конфигурации.

    7 июня 2007 г. 6:04
  •  DonAlPatino написано:

    "Connect to my Exchange mailbox using http" не я придумал. Давайте не впадать в терминологический маразм.

    Покажите мне в этой фразе слово proxy. Можно воспользоваться микроскопом.

    Я цепляюсь к терминологии только потому, что Вы первый перешли в область наездов и начали проявлять ничем не обоснованный сарказм.

    Сертификация тут совершенно ни при чем, а при чем то, что американцы называют емким словечком attitude. Заметьте, что вопрос в этом топике задаете Вы, а остальные помогают или не помогают исключительно из собственного альтруизма.
    7 июня 2007 г. 6:09
  • Что в голову пришло... Может это и ваш случай?

    http://support.microsoft.com/?kbid=896861

    7 июня 2007 г. 10:06
  •  Jоker написано:

    Используется ли ISA сервер?

    Нет. Портмаппинг на 443-ий порт. Ну и SSL в обязательном порядке

     Jоker написано:

    При правильных настройках в соответствии с документацией все работает без всяких запросов логинов/паролей (при условии, что клиентская машина является членом домена). Этим пользуются миллионы людей, так что вряд ли на стороне Microsoft имеется ошибка, она скорее имеется на стороне Вашей конфигурации.

    Я и не сомневаюсь, что ошибка где-то у меня. Знать бы еще где. Хотя повод по-наезжать на MS, что оно не работает с настройками по-умолчанию остается.

    Кстати для меня остается загадкой почему при включенном proxy Outlook все равно сначал ломится к серверу напрямую (через DCOM) и только обломившись "вспоминает" про http.

    7 июня 2007 г. 13:24
  •  Jоker написано:
     DonAlPatino написано:

    "Connect to my Exchange mailbox using http" не я придумал. Давайте не впадать в терминологический маразм.

     

    Покажите мне в этой фразе слово proxy. Можно воспользоваться микроскопом.

    Я цепляюсь к терминологии только потому, что Вы первый перешли в область наездов и начали проявлять ничем не обоснованный сарказм.

    Сертификация тут совершенно ни при чем, а при чем то, что американцы называют емким словечком attitude. Заметьте, что вопрос в этом топике задаете Вы, а остальные помогают или не помогают исключительно из собственного альтруизма.
     


    Прямо под этой "фразой" кнопка "Exchange Proxy Settings". А если на нее нажать, то получаем окошка с надписью "Use this url to connect..." и в этом Url хоть ты тресни, но кроме протоколов http и https ничего выбрать нельзя. Поэтому я никак не пойму о чем мы спорим.

    А насчет остального - приходится честно признать что осталось два способа решения проблем настройки продуктов Микрософт

    1. Надеятся на альтруизм более опытных товарищей

    2. Башлять много-много бабла "партнерам", которые с вероятностью 70% будут потом в этом же форуме выяснять в чем проблемы...

    Спасибо Микрософт за то, что никто не останется без работы и "приблизим же бюджет внедрения новых продуктов MS к бюджету внедрения SAP R3!" (Копирайт не мой) :-(
    7 июня 2007 г. 13:33
  •  DonAlPatino написано:

    Кстати для меня остается загадкой почему при включенном proxy Outlook все равно сначал ломится к серверу напрямую (через DCOM) и только обломившись "вспоминает" про http.

    Никакой загадки нет. Вы его сами так конфигурируете. Видите, там есть два чекбокса: "On fast networks..." и "On slow networks...". По умолчанию помечен только второй, и это правильно - тогда Outlook будет соединяться по RPC из внутренней сети и по HTTP извне. (Можно в принципе оба флажка снять, неважно, извне RPC все равно недоступен). А если поставить оба, то Outlook будет подключаться через HTTP в любом случае.

    P.S. DCOM тут ни при чем Smile

    7 июня 2007 г. 20:35
  •  DonAlPatino написано:
     Jоker написано:
     DonAlPatino написано:

    "Connect to my Exchange mailbox using http" не я придумал. Давайте не впадать в терминологический маразм.

     

    Покажите мне в этой фразе слово proxy. Можно воспользоваться микроскопом.

    Я цепляюсь к терминологии только потому, что Вы первый перешли в область наездов и начали проявлять ничем не обоснованный сарказм.

    Сертификация тут совершенно ни при чем, а при чем то, что американцы называют емким словечком attitude. Заметьте, что вопрос в этом топике задаете Вы, а остальные помогают или не помогают исключительно из собственного альтруизма.
     


    Прямо под этой "фразой" кнопка "Exchange Proxy Settings". А если на нее нажать, то получаем окошка с надписью "Use this url to connect..." и в этом Url хоть ты тресни, но кроме протоколов http и https ничего выбрать нельзя. Поэтому я никак не пойму о чем мы спорим.

    Имеется в виду RPC Proxy. Который, между прочим, не обязан даже быть Exchange сервером, эту компоненту можно поставить на отдельный компьютер. А HTTP proxy - это совершенно четко определенное понятие, которое, например, может быть реализовано в ISA, и которое тут совершенно не используется.

    Но я согласен с Вами, что в совокупности эти две фразы могут быть поняты неправильно, что мы тут и наблюдаем.  Поэтому давайте замнем терминологический спор для ясности.

    7 июня 2007 г. 20:39
  • Дома стоит обе галки, но ломимся все равно сначала по Dcom. Впрочем может тут дело в неработающем Autodiscover... с ним разбиратся пока не ыбло времени.
    8 июня 2007 г. 7:29
  •  Jоker написано:

    Но я согласен с Вами, что в совокупности эти две фразы могут быть поняты неправильно, что мы тут и наблюдаем.  Поэтому давайте замнем терминологический спор для ясности.

     

    OK

    8 июня 2007 г. 7:31
  • Господа, давайте не заниматься хернёй и не обвинять друг друга в чём попало, лишь бы обвинять. Я полагаю, что надо просто переформулировать вопрос и думать над ним. Так будет оперативнее и без флуда.

     

    Я сам столкнулся с той же проблемой.

     

    Формулирую вопрос заново, со скидкой на мою конфу, но который по сути тот же вопрос, что и был задан вначале:

     

    Между клиентом (Outlook 2007) (который из другого домена) и сервером Exchange 2007 стоит IIS 6. Настроено RPC over HTTPS. IIS, прежде чем пустить клиента к серверу сначала запрашивает авторизацию (согласно настройкам directory security в виртуальных каталогах). Клиент с другого домена и, потому, не проходит авторизацию ни LM ни NTLM автоматически. И IIS выдаёт окошечко с запросом на ручной ввод креденшиалов.

    Видятся два пути выхода из положения:

     1 ) Установить сертификат User от другого домена (где живут Exchange и IIS) данному пользователю.

     2 ) Занести данные пользователя в LanMan на его рабочей станции.

     

    Со слов тех.поддержки Майкрософта первое не возможно, так как Outlook не поддерживает сертификаты. Я не совсем согласен. Ведь Outlook тут ни причём.

    Второго я не умею.

     

    У кого идеи ?

     

    P.S.: если кому-то недостаточно информации - прошу выражать это параллельно с выражением уважения к участникам форума - всё же мы не быдло. Все любят вспоминать про телепатов, когда не находят ответа заранее написанного на вопрос, который возник секунду назад. А с тем, что надо быть телепатом, чтобы предугадать вопрос никто не считается

    18 июня 2007 г. 7:30
  •  Mike L.A. написано:

     1 ) Установить сертификат User от другого домена (где живут Exchange и IIS) данному пользователю.

     2 ) Занести данные пользователя в LanMan на его рабочей станции.

     Со слов тех.поддержки Майкрософта первое не возможно, так как Outlook не поддерживает сертификаты. Я не совсем согласен. Ведь Outlook тут ни причём.

    Пользователь может подключаться к почтовому серверу разными путями: OWA, Outlook, RPC/HTTP (aka Outlook Anywhere), ActiveSync, etc.

    • OWA вполне себе позволяет использовать сертификаты, смарткарты и прочее: http://technet.microsoft.com/en-us/library/bb124507.aspx
    • Outlook не использует CAS сервер (и соответственно IIS) вообще, так что нет и темы для разговора.
    • RPC over HTTP пока не поддерживает двухфакторную аутентификацию.
    • ActiveSync поддерживает двухфакторную аутентификацию с использованием пользовательских сертификатов. При публикации через ISA настраивается Kerberos constrained delegation etc. (ISA сервер, увы, должен быть членом домена).

    Подробнее тут: http://www.microsoft.com/technet/isa/2006/deployment/exchange.mspx 

    18 июня 2007 г. 17:35
  • 1) сертификаты OWA не интересны, интересены сертификаты для Outlook

    2) Что значит Outlook не использует CAS и IIS ? Если подключение по HTTPS, значит он должен подключиться к какому-то web-серверу. Там крутится .Net Framework (значит CAS). Или я не прав ?

    3) RPC over HTTPS не может поддерживать или не поддерживать какие-либо типы аутентификации. Это не протоколы аутентификации. Это всего-лишь протокол вызова процедур и транспортный протокол.

    4) Публикация через ISA тоже не интерисует. Лучше принять во внимание вариант, если траффик не фильтруется и заранее правильно раутится, а то будем решать сразу с двумя неизвестными выражениями проблему

     

    А вот идея по поводу CAS интересная.

    19 июня 2007 г. 6:07
  •  Mike L.A. написано:

    1) сертификаты OWA не интересны, интересены сертификаты для Outlook

    2) Что значит Outlook не использует CAS и IIS ? Если подключение по HTTPS, значит он должен подключиться к какому-то web-серверу. Там крутится .Net Framework (значит CAS). Или я не прав ?

    3) RPC over HTTPS не может поддерживать или не поддерживать какие-либо типы аутентификации. Это не протоколы аутентификации. Это всего-лишь протокол вызова процедур и транспортный протокол.

    4) Публикация через ISA тоже не интерисует. Лучше принять во внимание вариант, если траффик не фильтруется и заранее правильно раутится, а то будем решать сразу с двумя неизвестными выражениями проблему

     

    А вот идея по поводу CAS интересная.

    1) сертификаты не бывают "для OWA" или "для Outlook". Речь идет о компьютерных или пользовательских сертификатах. Какая разница, какой продукт их использует? Цель одна - удостовериться, что компьютер (или пользователь) именно тот, за кого себя выдает.

    2) Вот и Вы впадаете в те же терминологические споры. Давайте отличать Outlook от RPC over HTTP. Outlook использует RPC протокол, который никаким образом не использует ни CAS, ни IIS. RPC over HTTP - другое дело, для него я сделал отдельный пункт.

    3) Спасибо за информацию, очень познавательно Smile Давайте я напишу "Outlook Anywhere" вместо "RPC over HTTP", легче станет? Я имею в виду клиента. А нужные типы аутентификации поддерживаются CAS сервером и соответственно домен-контроллерами.

    4) Ну на нет и суда нет.

    19 июня 2007 г. 19:20
  • 1) сертификаты не бывают "для OWA" или "для Outlook". Речь идет о компьютерных или пользовательских сертификатах. Какая разница, какой продукт их использует? Цель одна - удостовериться, что компьютер (или пользователь) именно тот, за кого себя выдает

     

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

     

     

    2) Вот и Вы впадаете в те же терминологические споры. Давайте отличать Outlook от RPC over HTTP. Outlook использует RPC протокол, который никаким образом не использует ни CAS, ни IIS. RPC over HTTP - другое дело, для него я сделал отдельный пункт

     

    Ни слова не понял. Я не писал что Аутлук использует CAS. Я спросил что значит эта фраза. CAS использует только IIS.

     

     

    3) Спасибо за информацию, очень познавательно Давайте я напишу "Outlook Anywhere" вместо "RPC over HTTP", легче станет?

     

    ну вот поэтому наверно и возникают такие перепалки на форуме. Я не прослеживаю логической связи между первыми двумя фразами и третьей:

    - RPC over HTTP пока не поддерживает двухфакторную аутентификацию

    - RPC over HTTPS не может поддерживать или не поддерживать какие-либо типы аутентификации. Это не протоколы аутентификации. Это всего-лишь протокол вызова процедур и транспортный протокол

    - Давайте я напишу "Outlook Anywhere" вместо "RPC over HTTP", легче станет? Я имею в виду клиента. А нужные типы аутентификации поддерживаются CAS сервером и соответственно домен-контроллерами.

     

    Что имелось ввиду ? Кто не поддерживает всё-таки двухфакторную аутентификацию ? И как это сказывается на данной схеме ?

    28 июня 2007 г. 8:59
  • для подавления запроса пароля при NTLM аутентификации, на клиенте, можно попробовать следующее:
    [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa]
    "lmcompatibilitylevel"=dword:00000002

    28 июня 2007 г. 10:46
  •  D A V написано:
    для подавления запроса пароля при NTLM аутентификации, на клиенте, можно попробовать следующее:
    [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa]
    "lmcompatibilitylevel"=dword:00000002

     

    да он вроде по умолчанию такой стоит

    28 июня 2007 г. 11:07
  • по умолчанию там "0"

    ЗЫЖ http://support.microsoft.com/kb/820281
    You are using NTLM authentication to the proxy server for Exchange, but Windows does not automatically send the NTLM challenge/response data. Windows does not do this because the older LANMAN challenge/response password is included in the authentication data.
    28 июня 2007 г. 11:12
  • точно, я же сам поменял недели 2 назад. В любом случае не работает. Нужны ещё идеи.
    29 июня 2007 г. 7:02
  • Ветка работает, все ок!
    2 июля 2007 г. 8:00