none
Не работает Outlook Anywhere из внутренней сети. RRS feed

  • Вопрос

  • Доброго дня Уважаемые коллеги.

    Пытаюсь подключиться обычным клиентом Outlook из набора MS Office, или клиентом OUtlook Office 365 из внутренней сети. Допустим это обычный ноутбук ВНЕ домена- локальный в сети где есть Exchange, либо через VPN. Внешне и внутреннее  DNS имя домена различаются (внешняя name.ru , внутренняя contoso.local), но на внутреннем DNS сервере прописана внешняя доп.зона name.ru. Внутри данной зоны на внутреннем DNS прописаны две записи mx.name.ru на оба ip адреса обоих серверов Exchange для DNS Round Robin- TTL равен 1 минуте

    Во внешнем DNS в зоне домена name.ru прописана А запись Autodiscover на белый ip-адрес.

    Но, хочу обратить особый момент на разрешение имен и саму инфраструктуру. Есть два леса  в исходном локальный DNS на котором  прописана доп.зона name.ru и  есть целевой лес в дочернем домене которого стоит Exchange 2016. .Между дочерним доменом целевого леса и исходным лесом существует внешний траст На DNS в дочернем домене нет данной доп.зоны, но прописаны условные пересылки для корректного разрешения имен в обоих лесах. Данная схема существует, пока не закончится миграция из иходного леса в целевой. Данный момент я привел лишь для того, что бы исключить возможные проблемы в разрешении имен и подключения не доменного клиента Outlook, если это так.

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

    При публикации основных служб во внешней зоне DNS таких как fIIS через 443 порт для подключения клиентов, используется внешнее имя mx.name.ru , на то же имя во внешней зоне DNS опубликован и Autodiscover..

    Что работает:

    1.В домене клиенты Outlook автоматически получают конфигурацию и работают штатно.

    2.Мобильные клиенты через внешние сети передачи данных подключаются к Exchange и штатно работают.

    3.Обычный Outlook из внешней сети подключается через запись Autodiscover, которая прописана во внешнем DNS , все штатно подключается через запрос имени пользователя домена и пароля.

    Что не работает:

    1.Обычный клиент Outlook вне домена на локальном ПК или  ноутбуке.То есть из внутренней сети без домена.

    2. Мобильный клиент через местный Wi-Fi не проверял, но можно сказать, что выдаются адреса из внутренней сети и подключение так же не удастся.

    Пишет ошибку подключения, или что подключение не зашифровано, даже если появляется окно аутентификации.

    Подскажите, в чем может быть данная ошибка, может стоит прописать запись Autodiscover на внутреннем DNS доп.зоны ?

    Понятно, что клиент Outlook в домене сначала обращается в AD за SCP , далее уже Autodiscover для поиска настроек.

    Либо надо указать внешнюю запись Autodoscover-ра c белым ip-адоесом в допю зоне на нашем локальном DNS :?-Хотя тут странная логика получается, изнутри сети сначала обращаться во внешнюю зону DNS , а далее обратно к внутренним серверам Exchange ?

    Почему внутренний клиент Outlook вне домена, не может взять настройки сразу с локальных серверов Exchangr по внутреннему имени mx.name.ru ?

    Есть инструмент, или утилита для проверки правильности подключения клиента Outlook, который не является доменным ?

    Спасибо!



    Люди тратят здоровье, что бы заработать $, а затем тратят $, что бы вернуть здоровье!






    • Изменено rеstless 5 декабря 2018 г. 12:14
    5 декабря 2018 г. 11:14

Ответы

  • Да, проблем быть не должно, я согласен. Можете и клиентом О365 подключиться к своей организации.

    Было бы корректно авто обнаружение настроено, а что происходит при этом в сессии мы не видим. Поэтому и надо брать в руки Fiddler.

    10 декабря 2018 г. 10:54

Все ответы

  • Нашел, то что не доделано. Так как все виртуальные каталоги, в том числе и Autodiscover смотрят на одно и то же имя mx.name.ru, то соответственно я создал во внутренней зоне DNS name.ru  CNAME запись вида Autodiscover на mx.name.ru.

    Но тут так же есть не очень удобные моменты:

    При первоначальной настройке клиента просит как обычно vasia.ivanov@name.ru и пароль. Все данные ввел, но затем снова окно аутентификации с UPN суффиксом vasia.ivanov@name.ru, естественно он пароль не воспринимает, так как у меня внутренний UPN суффикс вида  name.ds.local.

    Только когда вводишь NetBios имя локального домена name\Ivanov.VI и пароль, то автоконфигурация срабатывает и мы получаем работающий Outlook. 

    Инфраструктура такова, что UPN для внутреннего имени отличается от внешнего. 

    Вопрос: Как то можно упростить процедуру входа для таких клиентов, ограничившись лишь одним шагом введения пароля ? 

    Можно правда попробовать добавить UPN Suffix в домен, для @name.ru и указать его в аккаунте входа как предпочтительный, тогда я так понимаю достаточно будет ввести только пароль. Хотя и тут есть проблема. Аккаунт входа у нас в формате Ivanov.VI, а SMTP адрес vasya.ivanov@name.ru

    Либо создать SRV запись будет правильнее, есть отличие от механизма CNAME ?

    Есть еще варианты ? ))  

    Спасибо.



    Люди тратят здоровье, что бы заработать $, а затем тратят $, что бы вернуть здоровье!


    • Изменено rеstless 5 декабря 2018 г. 13:48
    5 декабря 2018 г. 13:44
  • По логике вещей будет гораздо меньше проблем если UPN будет совпадать с почтовым адресом. Можно просто добавить UPN-суффикс и поменять UPN у пользователей.
    5 декабря 2018 г. 13:51
  • По логике вещей будет гораздо меньше проблем если UPN будет совпадать с почтовым адресом. Можно просто добавить UPN-суффикс и поменять UPN у пользователей.
    К сожалению добавить UPN суффикс мы не сможем, потому что это делается на уровне всего леса, а нам права даны только в дочернем домене.  Так что либо изыскивать другие способы, либо вот так через двойной ввод пароля ((

    Люди тратят здоровье, что бы заработать $, а затем тратят $, что бы вернуть здоровье!

    5 декабря 2018 г. 14:05
  • 1. Поменять пользователям UPN, как посоветовал выше Алексей, на совпадающий с почтовым адресом.

    2. Проблема решена.

    PS. Просто поменяйте атрибут UPN, суффикс прописывать для смены не обязательно. Можете проверить это на тестовых пользователях. Всем остальным атрибут просто копируется скриптом на  PowerShell, взяли primary SMTP и скопировали его значение в UPN.

    7 декабря 2018 г. 17:13
  • 1. Поменять пользователям UPN, как посоветовал выше Алексей, на совпадающий с почтовым адресом.

    2. Проблема решена.

    PS. Просто поменяйте атрибут UPN, суффикс прописывать для смены не обязательно. Можете проверить это на тестовых пользователях. Всем остальным атрибут просто копируется скриптом на  PowerShell, взяли primary SMTP и скопировали его значение в UPN.

    Дмитрий, уже сделали, все замечательно работает в обычном Outlook. Решили так же попробовать в Office 365, но что-то как то "криво" пока:



    Люди тратят здоровье, что бы заработать $, а затем тратят $, что бы вернуть здоровье!

    10 декабря 2018 г. 8:45
  • Если UPN совпадает, то нет особых проблем для подключения ящика.

    Посмотрите fiddler'ом что происходит в сессии. По идее, подключение сразу должно пойти в О365 минуя вашу земную среду. Может, на файерволле закрыт траффик, и поэтому нет подключения. Гадать пока только остается, точно сказать сложно.

    10 декабря 2018 г. 10:08
  • Если UPN совпадает, то нет особых проблем для подключения ящика.

    Посмотрите fiddler'ом что происходит в сессии. По идее, подключение сразу должно пойти в О365 минуя вашу земную среду. Может, на файерволле закрыт траффик, и поэтому нет подключения. Гадать пока только остается, точно сказать сложно.

    Посмотрите fiddler'ом что происходит в сессии - что за инструмент, можно немного расшифровать ?Дмитрий, я немного про другое если клиент Outlook штатно подключается к нашей организации Exchange, то почему бы и клиентом Outlook Office 365 не подключаться к нашей организации Exchange. 

    Вот именно с клиентом Office 365 такая фигня происходит.


    Люди тратят здоровье, что бы заработать $, а затем тратят $, что бы вернуть здоровье!

    10 декабря 2018 г. 10:51
  • Да, проблем быть не должно, я согласен. Можете и клиентом О365 подключиться к своей организации.

    Было бы корректно авто обнаружение настроено, а что происходит при этом в сессии мы не видим. Поэтому и надо брать в руки Fiddler.

    10 декабря 2018 г. 10:54