none
domain.local отменяется с осени ... RRS feed

  • Вопрос

  • Коллеги, подскажите, как быть ? Есть локальный домен внутри локальной сети. В этом же домене есть Exchange Server 2013. На нём две сетевые карты - одна смотрит в инет, другая в локалку. Соответственно, получен на этот сервер сертификат от Комодо на mail.domain.local  и на mail.domail.ru . Пока всё работает нормально, но до окончания срока действия сертификата осталось 3 месяца, а потом провайдер сертификата говорит, что все домены .local перестанут работать - больше нигде на них сертификаты выдавать не будут. Вопрос один: что делать ?

    =STAS=

    • Изменено -STAS- 12 октября 2015 г. 20:17
    4 августа 2015 г. 11:19

Ответы

  • Всё ! Решил проблему ! Вот тут почитал, сделал всё по пунктам и вуаля - всё заработало : https://blog.digicert.com/exchange-replacing-internal-names-certificates-part-2/

    Большое Спасибо всем, кто участвовал и помог.

    Надеюсь, другим тоже поможет :)

    P.S.: Там рассмотрено два варианта - один с помощью их программы, другой - с помощью PowerShell. Программам Third-party я не очень доверяю, поэтому делал через PS.


    =STAS=

    • Предложено в качестве ответа Aleksey Shimanov 16 октября 2015 г. 5:47
    • Помечено в качестве ответа -STAS- 19 октября 2015 г. 7:46
    • Изменено -STAS- 19 октября 2015 г. 7:48
    15 октября 2015 г. 23:53

Все ответы

  • 1. Поднять свой центр сертификации (CA). Пользователи внутри домена будут доверять сертификатам, которые он выдаст.

    2. Подключаться по имени mail.domail.ru внутри организации (как один из вариантов - создать зону domain.ru на DC и импортировать текущие внешние записи, а для mail.domail.ru указать внутренний IP).



    • Изменено Tema_BYMVP 4 августа 2015 г. 12:17
    4 августа 2015 г. 12:14
  • Свой центр сертификации уже поднят. И у пользователей домена на компьютерах, введённых в домен, проблем нету - они автоматически доверяют сертификатам нашего CA. А проблемы начнутся с осени, когда поставлю новый сертификат, в котором нет mail.domain.local, а есть только mail.domain.ru. И проблемы, насколько я понимаю, будут у пользователей, компьютеры которых не в домене. Как в Outlook, так и в OWA ... Проблема также в том, что сам domain.ru зарегистрирован на Valuehost (там у нас расположен сайт нашей фирмы на Joomla и через них приходит почта на наш Exchange). Отправляем почту уже сами.

    =STAS=


    • Изменено -STAS- 5 августа 2015 г. 13:29
    5 августа 2015 г. 13:25
  • Ничего не понял. У вас же есть свой СА, верно? Что мешает выписать для внутренних соединений сертификат mail.domain.local, в котором будет так же имя autodiscover.domain.local. Для внешних подключений оставьте коммерческий сертификат. Или заверните все подключения через внешние адреса (autodiscover.domain.ru, mail.domain.ru).
    • Предложено в качестве ответа ILYA [ sie ] SazonovModerator 5 августа 2015 г. 14:25
    • Отменено предложение в качестве ответа -STAS- 27 октября 2015 г. 7:54
    5 августа 2015 г. 13:40
  • Хм ... так-то ничто не мешает, конечно, но ... каким службам какие сертификаты тогда назначать ? Сейчас общий сертификат и на .ru и на .local назначен на службы: IMAP, POP, IIS, SMTP ... А если будет два сертификата, то куда какой назначать ?

    =STAS=

    28 августа 2015 г. 21:07
  • В теории (у меня не получилось, но я не сильно и старался) можно повесить внешний сертификат для интернета и внутренний для локали. Делается это в iis в привязках.

    Но лучше уйти от *.local - поднимите виртуальный PDC, на нем заведите domain.ru и подружите с domain.local, затем не спешно перетащите всех в domain.ru, как перетащите - можете удалить domain.local.

    1 сентября 2015 г. 7:52
  • Или заверните все подключения через внешние адреса (autodiscover.domain.ru, mail.domain.ru).

    Было бы неплохо. Только как это сделать ? Есть какое-нибудь руководство ? Потому как сейчас куча мест и в Exchange 2013 и в IIS 7, где прописано и mail.domain.ru и mail.domain.local.

    Насколько я понимаю, пользователям OWA всё равно - они набирают mail.domail.ru - туда и попадают, а вот Outlook - нет.

    Даже при первом запуске Outlook после установки Office на доменном компьютере, он предлагает создать новую конфигурацию (как обычно) и сразу откуда-то подцепляет имя-пароль и адрес сервера mail.domain.local. Даже когда в настройках меняяю .local на .ru - всё равно при перезапуске опять вижу .local

    P.S.: Вчера попробовал обновить старый сертификат с .local на новый, недавно выданный сертификат только с .ru - сертификат ставится нормально, но и Outlook и при входе через OWA - ругается. Мол, сертификат нормальный,  но не соответствует серверу.

    Как бы завернуть все подключения на внешние адреса .ru и чтобы не было ругани на то, что сертификат .ru не соответствует серверу .local ?


    =STAS=

    • Изменено -STAS- 12 октября 2015 г. 8:48
    10 октября 2015 г. 21:35
  • Все настройки довольно просто меняются на уровне конфигурирования виртуальных каталогов Exchange. Замените все URL с доменным суффиксом local на URL с суффиксом ru. Так же используйте Set-OutlookProvider, чтобы указать CN сертификата для внутренних и внешних подключений, ну и обязательно Set-OutlookAnywhere для указания хостов для внешних и внутренних подключений (имя хостов в вашем случае будет одинаковым - mail.domain.ru. Соответственно должна быть внутренняя зона DNS domain.ru, где должны быть указаны все ваши записи, перечисленные в коммерческом сертификате, которые разрешаются в IP Exchange (internal).

    Do not multiply entities beyond what is necessary

    12 октября 2015 г. 4:35
  • А чтобы протестировать, корректно ли применились изменения виртуальных каталогов Exchange, используйте встроенное средство проверки автообнаружения в Outlook с доменной машины (CTRL + ПКМ по значку Outlook в трее - Проверить автоконфигурацию). Полученные параметры можно увидеть на вкладке XML. 
    • Предложено в качестве ответа AndreySV 23 октября 2015 г. 9:14
    • Отменено предложение в качестве ответа -STAS- 27 октября 2015 г. 7:55
    12 октября 2015 г. 6:48
  • Соответственно должна быть внутренняя зона DNS domain.ru, где должны быть указаны все ваши записи, перечисленные в коммерческом сертификате, которые разрешаются в IP Exchange (internal).
    Вот тут-то и проблема - сам domain.ru находится у нашего хостера - там находится наш сайт domain.ru. У нас - только наша внутренняя локальная сеть с DC domail.local на одном сервере с выходом в интернет и mail.domain.local - на другом, с другим выходом в интернет. Если я пропишу зону domain.ru на DC, то, как я понимаю, будет конфликт с domain.ru у провайдера ...

    =STAS=

    • Изменено -STAS- 12 октября 2015 г. 8:44
    12 октября 2015 г. 8:40
  • Необходимо будет перенести все записи из DNS провайдера в зону, созданную локально. С той лишь разницей, что для серверов Exchange укажите внутренние IP.
    12 октября 2015 г. 8:45
  • А сайт domain.ru, который физически лежит у хостера, тогда как ?

    =STAS=

    12 октября 2015 г. 8:55
  • Да ничего страшного. Клиент обращается к вашему локальному серверу DNS. Находит там в зоне domain.ru требуемую запись и использует ее для подключения к Exchange. Если же, к примеру, обращение происходит к другому имени (так же в domain.ru), то не найдя записи в локальной зоне ваш DNS сервер форвардит запрос на DNS провайдера.

    То есть ваша внутренняя зона domain.ru никак не повлияет на публичную зону.


    Do not multiply entities beyond what is necessary

    12 октября 2015 г. 9:03
  • Добавлю, что для зоны надо будет отключить динамические обновления, иначе дополнительно к внешнему IP будут резолвиться локальные адреса контроллеров домена.
    12 октября 2015 г. 9:28
  • Такая схема примерно ...

    Основную зону domail.ru создавать или дополнительную ? Да, и только прямого просмотра или прямого и обратного просмотра ?


    =STAS=




    • Изменено -STAS- 12 октября 2015 г. 9:39
    12 октября 2015 г. 9:29
  • да, примерно так. Зона основная, без динамических обновлений. Во внутренней DNS зоне domain.ru у вас будет всего 2 записи - mail.domain.ru и autodiscover.domain.ru (необязательная). Первая запись типа А, вторая CNAME.

    Do not multiply entities beyond what is necessary


    • Изменено Dmitry.I 12 октября 2015 г. 9:39
    12 октября 2015 г. 9:39
  • А сам почтовый сервер mail.domain.local не нужно переводить в домен domain.ru ?

    =STAS=

    • Изменено -STAS- 12 октября 2015 г. 10:02
    12 октября 2015 г. 9:58
  • Серверы вообще трогать не надо. Только:

    1. Продублировать зону domain.ru на внутренних DNS.

    2. Изменить настройки виртуальных каталогов IIS Exchange.

    12 октября 2015 г. 10:11
  • Окей. Спасибо. Сегодня вечером попробую. Отпишусь по результатам.

    =STAS=

    12 октября 2015 г. 10:21
  • А не будет ругани насчёт того, что сертификат выданый mail.domain.ru, используется на сервере mail.domain.local ?

    =STAS=

    12 октября 2015 г. 11:06
  • не будет, если все URL будут использовать зону domain.ru.

    Do not multiply entities beyond what is necessary

    12 октября 2015 г. 11:43
  • Все виртуальные каталоги поменял с mail.domain.local на mail.domain.ru, но один - никак - Autodiscover (Default Web Site) - там нету такой опции.


    =STAS=

    13 октября 2015 г. 11:45
  • Все нормально, этот каталог менять не надо.

    Проверяли ли вы работу автообнаружения (с помощью Outlook, как я писал выше)? 


    • Изменено Tema_BYMVP 13 октября 2015 г. 12:34
    13 октября 2015 г. 12:34
  • В общем почти получилось. Ситуация такая: OWA не ругается, а Outlook ругается на сертификат прокси, причём опять же, вручную меняю адрес прокси с .local на .ru - после перезагрузки вижу опять .local ... Откуда-то он этот адрес цепляет, видимо ...


    =STAS=

    13 октября 2015 г. 21:50
  • Посмотрите, какое имя сертификата прописано тут:

    get-outlokprovider

    Если local, замените егг (set-outlookprovider)

    14 октября 2015 г. 3:59
  • Все виртуальные каталоги поменял с mail.domain.local на mail.domain.ru, но один - никак - Autodiscover (Default Web Site) - там нету такой опции.


    =STAS=

    Set-AutodiscoverVirtualDirectory -Identity 'autodiscover (default Web Site)' -ExternalUrl "https://mail.domain.ru/autodiscover/autodiscover.xml"

    p.s.: на будущее.

    14 октября 2015 г. 8:48
    Модератор
  • А для какого смотреть ? Там выбор EXCH, EXPR и WEB ... .local я там нашёл в строке DistinguishedName и в OriginatingServer. И какую конкретно команду Set-OutlookProvider надо ввести для изменения .local на .ru ? А то там в описании к команде что-то ничего не пойму ...

    =STAS=

    • Изменено -STAS- 14 октября 2015 г. 10:38
    14 октября 2015 г. 10:35
  • А то там в описании к команде что-то ничего не пойму ...

    не меняет команда .local на .ru (я про Set-AutodiscoverVirtualDirectory)
    ключ -ExternalUrl указывает по какому адресу будут подключаться клиенты Outlook из внешней сети
    ключ -InternallUrl указывает по какому адресу будут подключаться клиенты Outlook из внутренней сети
    меняете адреса подключения на .ru - в сертификате должно быть соответствующее имя.
    к примеру:
    - для внешней сети: mail-ext.domain.ru
    - для внутренней сети: mail-int.domain.ru
    во внешнем DNS создаёте две записи А, указывающие на соответствующи имена. При этом, IP для mail-int будет из внутренний сети вроде 192.168.Х.Х/16


    14 октября 2015 г. 10:44
    Модератор
  • А для какого смотреть ? Там выбор EXCH, EXPR и WEB ... .local я там нашёл в строке DistinguishedName и в OriginatingServer. И какую конкретно команду Set-OutlookProvider надо ввести для изменения .local на .ru ? А то там в описании к команде что-то ничего не пойму ...

    =STAS=

    Надо смотреть на поле CertPrincipalName. Назначить его можно так:

    Set-OutlookProvider EXPR -CertPrincipalName msstd:mail.contoso.com
    14 октября 2015 г. 11:13
  • ... Если же, к примеру, обращение происходит к другому имени (так же в domain.ru), то не найдя записи в локальной зоне ваш DNS сервер форвардит запрос на DNS провайдера

    Однако, хотелось бы уточнить. С какого перепугу DNS, считающий себя авторитетным для зоны domain.ru, любые запросы для этой зоны (для отсутствующих в зоне записей) будет форвардить куда-то ещё?

    Как уже справедливо написал Artem R "Необходимо будет перенести все записи из DNS провайдера в зону, созданную локально. С той лишь разницей, что для серверов Exchange укажите внутренние IP".

    С уточнением, не "перенести", а "скопировать" :).

    И нет никакой необходимости "поднимать виртуальный PDC" и вообще MS domain для domain.ru, достаточно создать соответствующую зону на уже существующем (для бла-бла.local) DNS.


    S.A.

    14 октября 2015 г. 12:10
  • Однако, хотелось бы уточнить. С какого перепугу DNS, считающий себя авторитетным для зоны domain.ru, любые запросы для этой зоны (для отсутствующих в зоне записей) будет форвардить куда-то ещё?

    Всё верно, так и произошло. После создания зоны domain.ru и вписания туда mail.domain.ru и autodiscover.domain.ru наши сотрудники обратились ко мне с вопросом, почему не открывается наш сайт domain.ru (который физически находится у провайдера). Пока я его не прописал в ту же зону domain.ru с указанием внешнего IP.


    =STAS=

    14 октября 2015 г. 13:50
  • Было так:

    После ввода команд Set-OutlookProvider получилось так:

    А в Outlook внизу поменялось, а наверху всё равно осталось .local:

    да, а что значат эти EXCH, EXPR и WEB ? и как всё-таки поменять этот Адрес URL для подключения к прокси-серверу Exchange ?


    =STAS=

    • Изменено -STAS- 14 октября 2015 г. 14:11
    14 октября 2015 г. 14:07
  • Вверху так и будет - это локальный адрес сервера. 

    Вы правда немного перестарались - EXCH можно было не менять. Вот подробное описание, что это вообще такое:

    http://blogs.technet.com/b/exchange/archive/2008/09/26/3406344.aspx

    Подключение Outlook теперь проходит успешно?

    14 октября 2015 г. 14:14
  • Пока новый сертификат ещё не устанавливал - готовлю почву так сказать. Почтовик рабочий и на ходу если менять и что-то не заработает - будут вопросы. Потому сегодня ночью займусь заменой сертификата, благо с зонами вроде разобрались и с прокси тоже (надеюсь). Как поставлю - сразу отпишусь.

    P.S.: Большое спасибо всем за помощь - один бы я не разобрался со всем этим. Я вообще раньше в MDaemon работал - там всё по-другому ...


    =STAS=

    14 октября 2015 г. 14:27
  • Да, ещё такой вопрос: на этом почтовике есть ещё 2 обслуживаемых домена из зон .ru и .com, но перенаправление на них идёт через DNS провайдера на этот же сервер. На них эти изменения никак не повлияют ? Или тоже зоны для них прописывать надо ?

    =STAS=

    • Изменено -STAS- 14 октября 2015 г. 15:24
    14 октября 2015 г. 14:56
  • Вы же меняете только имя для внутреннего подключения, для внешнего мира не меняется ничего. Ведь не имя.бла-бла.local было же прописано на DNS провайдера :).

    На внешнем DNS (провайдера) прописаны имена с внешними IP, используемыми внешними клиентами для внешнего доступа (ничего не поменялось). На внутреннем DNS прописаны те же имена, но с внутренними IP, используемыми внутренними клиентами для доступа в локалке (имена поменялись).

    В зависимости от точки подключения клиента (внутри/снаружи), клиент получает от доступного ему DNS, для одного и того же имени, правильный IP (внутренний/внешний), и попадает куда надо - всё гораздо проще, чем когда "оттуда - .ru , отсюда - .local" ;).


    S.A.

    14 октября 2015 г. 16:32
  • В общем, ничего не получается. Несмотря на все старания, пока вот:

    P.S.: Извне сети - всё работает нормально (хотя в настройках Outlook Адрес URL для подключения к прокси-серверу Exchange для по-прежнему значится https://mail.domain.local). Уж не знаю, куда и копать--то ...


    =STAS=

    • Изменено -STAS- 14 октября 2015 г. 23:03
    14 октября 2015 г. 21:07
  • Интересует, что показывает тест автообнаружения Outlook, запущенный внутри сети. Покажите содержимое вкладок "Журнал" и "XML".

    15 октября 2015 г. 7:22
  • Всё ! Решил проблему ! Вот тут почитал, сделал всё по пунктам и вуаля - всё заработало : https://blog.digicert.com/exchange-replacing-internal-names-certificates-part-2/

    Большое Спасибо всем, кто участвовал и помог.

    Надеюсь, другим тоже поможет :)

    P.S.: Там рассмотрено два варианта - один с помощью их программы, другой - с помощью PowerShell. Программам Third-party я не очень доверяю, поэтому делал через PS.


    =STAS=

    • Предложено в качестве ответа Aleksey Shimanov 16 октября 2015 г. 5:47
    • Помечено в качестве ответа -STAS- 19 октября 2015 г. 7:46
    • Изменено -STAS- 19 октября 2015 г. 7:48
    15 октября 2015 г. 23:53
  • Да, ещё, только сегодня сообразил: если сделать domain.ru для внешних подключений, а domain.local для внутренних, то всё равно проблема останется, т.к. внутри сети бывают также и НЕ-доменные компы, а они нашему CA не доверяют.

    =STAS=

    20 октября 2015 г. 14:04