none
Чудеса с Outlook Anywhere RRS feed

  • Вопрос

  • Добрый день, уважаемые коллеги.

    Уже более месяца бьюсь с настройкой anywhere, однако полностью его запустить не получается.

    Что есть:

    1)      Один внешний статический айпи;

    2)      Внутренний и внешний домен – domain.ru

    3)      Exchange server mail.domain.ru (по этому имени опубликован почтовый сервер извне);

    4)      Создан для Exchange сертификат, со всеми ДНС именами, которые необходимы;

    5)      На базе данного сертификата создан веб-прослушиватель с проверкой подлинности на базе форм + AD;

    6)      Через данный веб-прослушиватель опубликованы OWA, Anywhere, ActivеSync;

     

    OWA и ActivеSync работают. А Anywhere постоянно выдает ошибку 403 доступа к Autodiscover.

    Изначально OWA, ActiveSync и Anywhere были опубликованы по адресу mail.domain.ru, однако потом я выяснил, что autodiscover должен быть опубликован по адресу либо domain.ru либо по autodiscover.mail.ru. В итоге я создал два правила:

    1)      Опубликовал по адресу mail.domain.ru Anywhere и из путей удалил /Autodiscover /*;

    2)      Опубликовал по адресу domain Anywhere и в путях оставил /Autodiscover /*.  Если захожу через веб-браузер по адресу https://domain.ru/autodiscover/autodiscover.xml то вижу окно TMG 2010, ввожу логин и пароль и вижу ошибку 600. Ошибок сертификата не вижу.

    После этого Outlook 2010 перестал выдавать ошибку загрузки OAB при нажатии Отправить\Получить, однако тестирование автонастроек подключения так же выдавало ошибку 403 на https://domain.ru/autodiscover/autodiscover.xml.

    После длительного изучения technet и сайта isadocs.com я узнал, что в случае публикации OWA и Anywhere на одном айпи и с прослушивателем на основе проверке FBA + AD в правилах публикации можно использовать либо простую проверку (соответственно и на клиенте и на CAS должна быть установлена простая проверка пароля) либо использовать правило без делегирования проверки однако юзер может быть переадресован на проверку (на клиенте и на CAS должна стоять проверка NTLM).

    После этого решил изначально настроить простую проверку: настроил в EMC на OWA и Anywhere простую проверку подлинности, поставил в правилах публикации OWA, Anywhere и Autodiscover простую проверку подлинности и на клиенте тоже самое. Пробую подключиться – снова вижу ошибку 403.

    Лезу на Exchange Server в IIS в каталог Autodiscover и указываю в нем только простую проверку и анонимную, убрав NTLM. После этого клиент работает на ура, проверка автонастроек проходит быстро, никаких ошибок. Одна большая проблема – В локальной сети при подключении outlook запрашивает пароль. Если обратно возвращаю проверку NTLM то в локальной сети все работает, а клиент Anywhere снова отбивает ошибку.

    Пробую второй способ публикации: на CAS для OWA и Anywhere ставлю проверку NTLM, на TMG 2010 в правилах публикации OWA, Anywhere и Autodiscover ставлю тип проверки «без делегирования проверки однако юзер может быть переадресован на проверку» а на клиенте ставлю проверку NTLM. При включении Outlook на клиенте Anywhere я получаю постоянное окно запроса логина и пароля.

     

    Уважаемые коллеги, помогите разобраться в проблеме. Уже все мозги кипят =)

Ответы

  • Проблема в том, что локальные ДНС разреeшают имя fl56.ru в ip первого сервера ДНС и соответсвенно пытается с него стянуть autodiscover, но там ничего нет.

    Очччень интересно.  А как у вас происходит автообнаружение внутренних клиентов? Или вообще не происходит?

    Как можно реализовать использование Outlook Anywhere в сети впн?

    Мобильный Outlook через VPN-соединение - это, как говорится, масло масляное. Outlook Anywhere предназначен для доступа ВНЕШНИХ клиентов в полном смысле этого слова. Чтобы после создания VPN-соединения Outlook Anywhere у клиентов продолжал работать напрямую через интернет, и при этом не мешал доступу к корпоративным ресурсам, на клиенте нужно сделать следуюoее:

    1. В настройках VPN-подключения снять галку "Использовать основной шлюз в удалённой сети";
    2. В дополнительных свойствах сети переместить коммутируемые соединения в конец списка;
    3. Для всех необходимых клиенту локальных ресурсов прописать строчки в hosts с указанием локальных адресов ресурсов;
    4 Для всех внутренних подсетей (если их больше чем одна), в которых находятся нужные клиенту ресурсы, прописать маршруты через сеть, в которой клиент получает адрес при подключении.

    • Помечено в качестве ответа Kozlov Artem 21 мая 2010 г. 7:49
  • ПроблеПроисходит, тянет настройки с https://mail.domain.ru/autodiscover

    Вы в этом уверены? Как мы уже говорили, служба автообнаружения  размещается либо на основном домене, либо на субдомене autodiscover. Есть подозрение, что она у вас не совсем правильно объявлена на внутреннем DNS. Проверьте с помощью анализатора подключения внутри сети.

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

    Можно ли как-то еще решить эту проблему?

    Можно. Outlook Anywhere в этом случае вам не нужен. Подключайте VPN-клиентов через их VPN-основной шлюз, по MAPI, в точности как и внутренних клиентов

    • Помечено в качестве ответа Kozlov Artem 21 мая 2010 г. 7:49

Все ответы

  • А пробовали совместить FBA для OWA и внутреннюю для RPC как написано здесь ?

    1. Опубликуйте Anywhere, OWA и EAS с помощью мастера, в настройках прослушивателя укажите делегирование с FBA
    2. Проверьте работоспособность OWA
    3. Сделайте копию созданного мастером правила публикации, в вышестоящей копии этого правила удалите все каталоги кроме /rpc/*, вместо "All authenticated users" поставьте "All users", снимите галку "require all users to authenticate", поставьте проверку подлинности "no delegation but client can directly authenticate" , на виртуальном каталоге rpc в Exch поставьте проверку подлинности integrated, на клиенте NTLM.

    P.S. Чем закончились ваши попытки публикации через второй IP?

  • Проблема в том, что в TMG 2010 нельзя одни правилом опубликовать одновременно Anywhere, OWA и EAS.

    + У меня есть еще дополнительное правило, которое публикует mail.domain.ru/autodiscover на адресе domain.ru

    Таким образом получается так:

    Я создаю 4 правила публикации:

    1) Autodiscover

    2) OWA

    2) Anywhere

    4) EAS

    На правилах Autodiscover, OWA я оставляю проверку NTLM

    Делаю дубль правила Anywhere. В изначальной копии оставляю проверку NTLM и удаляю из него каталог RPC, а в копии я удаляю все, кроме RPC и делаю проверку "no delegation but client can directly authenticate". На CAS везде ставлю NTLM.

    Верно я мыслю?

  • Проблема в том, что в TMG 2010 нельзя одни правилом опубликовать одновременно Anywhere, OWA и EAS.

    Я не думаю что это проблема. Можно же все сделать аналогично, как в ISA, но на нескольких правилах.

    1) Autodiscover

    2) OWA

    2) Anywhere

    4) EAS

    На правилах Autodiscover, OWA я оставляю проверку NTLM

    Делаю дубль правила Anywhere. В изначальной копии оставляю проверку NTLM и удаляю из него каталог RPC, а в копии я удаляю все, кроме RPC и делаю проверку "no delegation but client can directly authenticate". На CAS везде ставлю NTLM.

    А как насчет "All users" и "require all users to authenticate"? Без этих изменений в копии правила для /rpc/* - работать не будет. И проконтроллируйте чтобы на виртуальном каталоге /rpc была выбрана только integrated проверка подлинности.
  • Все сделал, так как писал, только еще добавил:

    1) Для правила публикации Autodiscover указал проверку "no delegation but client can directly authenticate".

    2) На клиенте установил Обычную проверку, т.к. если ставить NTLM то клиент не может подключиться при создании учетной записи, если же указать NTLM у уже созданной записи, то все работает отлично (может это можно как-то исправить, чтобы использовать и при подключении NTLM ?)

    3) На каталоге OAB в IIS добавил еще анонимную проверку подлинности.

    После данных действий Outlook Anywhere работает уже два дня и проходит проверку автоматической конфигурации почты.

    Дай бог, чтобы и дальше так же работал =)

    Единственная небольшая проблема, которая не дает полностью расслабиться - это то, что с проверкой NTLM не могу создать учетную запись - постоянно просит пароль.

     

  • 1) Для правила публикации Autodiscover указал проверку "no delegation but client can directly authenticate".

    А в пользователях при этом изменили на All Users? Если нет - нормально работать не будет

    2) На клиенте установил Обычную проверку, т.к. если ставить NTLM то клиент не может подключиться при создании учетной записи, если же указать NTLM у уже созданной записи, то все работает отлично (может это можно как-то исправить, чтобы использовать и при подключении NTLM ?) 

    Это значит снова траблы с Autodiscover, см.п.1

    3) На каталоге OAB в IIS добавил еще анонимную проверку подлинности. 

    Не думаю что это нужно.

    Единственная небольшая проблема, которая не дает полностью расслабиться - это то, что с проверкой NTLM не могу создать учетную запись - постоянно просит пароль.

    Чтобы автообнаружению не мешали формы, попробуйте сделать так: для \Autodiscover\* отдельное правило публикации протокола HTTP, отдельный прослушиватель на 80-м: проверка подлинности integrated, для All Autenticated Users. На IIS в свойствах Autodiscover снять требование SSL, поставить integrated проверку подлинности. Должно работать.

  • И так, сделал все, что написано выше - заработала проверка NTLM.

    Однако теперь возникла еще одна (надеюсь последняя проблема).

    Было решено давать доступ ко всем ресурсам компании исключительно через vpn.

    Настроил на TMG vpn для клиентов (тип сайт-сайт), подключил клиентов - все замечательно.

    Клиентам присваиваются адреса из подсети 176.16.23.*

    Клиентам присваиваются внутренние ДНС сервера 192.168.1.11 и 192.168.1.10

    Запускаем Outlook на клиенте и снова получаем ошибку OAB. Делаю проверку автоконфигурации и вижу, что нет доступа к https://fl56.ru/autodiscover/autodiscover.ru

    Проблема в том, что локальные ДНС разреeшают имя fl56.ru в ip первого сервера ДНС и соответсвенно пытается с него стянуть autodiscover, но там ничего нет.

    Изменить ДНС, для клиентов впн, на внешние нет возможности, т.к. нужен доступ клиентов именно к локалке.

    Как можно реализовать использование Outlook Anywhere в сети впн?

  • Проблема в том, что локальные ДНС разреeшают имя fl56.ru в ip первого сервера ДНС и соответсвенно пытается с него стянуть autodiscover, но там ничего нет.

    Очччень интересно.  А как у вас происходит автообнаружение внутренних клиентов? Или вообще не происходит?

    Как можно реализовать использование Outlook Anywhere в сети впн?

    Мобильный Outlook через VPN-соединение - это, как говорится, масло масляное. Outlook Anywhere предназначен для доступа ВНЕШНИХ клиентов в полном смысле этого слова. Чтобы после создания VPN-соединения Outlook Anywhere у клиентов продолжал работать напрямую через интернет, и при этом не мешал доступу к корпоративным ресурсам, на клиенте нужно сделать следуюoее:

    1. В настройках VPN-подключения снять галку "Использовать основной шлюз в удалённой сети";
    2. В дополнительных свойствах сети переместить коммутируемые соединения в конец списка;
    3. Для всех необходимых клиенту локальных ресурсов прописать строчки в hosts с указанием локальных адресов ресурсов;
    4 Для всех внутренних подсетей (если их больше чем одна), в которых находятся нужные клиенту ресурсы, прописать маршруты через сеть, в которой клиент получает адрес при подключении.

    • Помечено в качестве ответа Kozlov Artem 21 мая 2010 г. 7:49
  • >>Очччень интересно.  А как у вас происходит автообнаружение внутренних клиентов? Или вообще не происходит?

    Происходит, тянет настройки с https://mail.domain.ru/autodiscover

    >>1. В настройках VPN-подключения снять галку "Использовать основной шлюз в удалённой сети";

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

    Можно ли как-то еще решить эту проблему?

    Пробовал подключиться Outlook'ом через автообнаружение, подключается по pop и smtp (или imap, точно не помню уже). Однако в таком случае нет адресной книги на клиенте, а это большая проблема, поскольку народа много и контакты нужны.

    Может быть есть какой-то способ подключить клиентов через vpn к Exchange так, чтобы на них выгружалась адресная книга и они могли с ней работать?

  • ПроблеПроисходит, тянет настройки с https://mail.domain.ru/autodiscover

    Вы в этом уверены? Как мы уже говорили, служба автообнаружения  размещается либо на основном домене, либо на субдомене autodiscover. Есть подозрение, что она у вас не совсем правильно объявлена на внутреннем DNS. Проверьте с помощью анализатора подключения внутри сети.

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

    Можно ли как-то еще решить эту проблему?

    Можно. Outlook Anywhere в этом случае вам не нужен. Подключайте VPN-клиентов через их VPN-основной шлюз, по MAPI, в точности как и внутренних клиентов

    • Помечено в качестве ответа Kozlov Artem 21 мая 2010 г. 7:49
  • анализатор это тот, который в outlook ?

    Если да, то вот что :

    http://s59.radikal.ru/i165/1005/9f/e69fb4709747.jpg

    http://i030.radikal.ru/1005/45/f22065a4e7f1.jpg

  • анализатор это тот, который в outlook ?
    Нет. Вот этот.
  • Сделал Microsoft Office Outlook Connectivity Tests: Outlook Autodiscover - все прошло успешно, все зеленое :)

     

  • Подключил клиента впн. Делаю проверку автоконфигурации и уже здесь outlook ломиться на https://domain.ru/autodiscover

    Что-то чем дальше в лес, тем больше у меня с Exchange дров :)

  • Подключил клиента впн. Делаю проверку автоконфигурации и уже здесь outlook ломиться на https://domain.ru/autodiscover
    domain.ru и mail.domain.ru - это один и тот же сервер? Со стороны клиента разрешается в один и тот же IP?
  • нет, domain.ru (внутри локальной сети) это DC, а mail.domain.ru - это сам Exchange.

  • нет, domain.ru (внутри локальной сети) это DC, а mail.domain.ru - это сам Exchange.

    А узел autodiscover.domain.ru объявлен на внутреннем DNS? Его IP должен указывать на EXch.

  • Первым делом сделал так, затем перезагрузил клиентский комп и все заработало =) Спасибо огромное.

    Чтобы не создавать отдельную тему: а какие порты нужны outlook через mapi, чтобы открыть только их для сети впн ?

  • Первым делом сделал так, затем перезагрузил клиентский комп и все заработало =) Спасибо огромное.

    Не забывайте нажимать на зелёный стрелочка.

    Чтобы не создавать отдельную тему: а какие порты нужны outlook через mapi, чтобы открыть только их для сети впн ?

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