Назад | Перейти на главную страницу

Устранение предупреждения о сертификате при доступе пользователей к Outlook / Exchange 2010 при настройке разделенного домена

У меня есть внутренний сервер Exchange 2010 с внутренним доменом, EXCHANGE0.COMPANY.COM.

Я настроил всех пользователей для доступа к Outlook (даже внутри) с помощью Outlook-over-HTTP. Для этого я установил сертификат клиентского доступа для внешнего домена. mail.company.com.

Проблема в том, что всякий раз, когда пользователи открывают Outlook, они сразу же получают предупреждения сертификата о несоответствии между mail.company.com и EXCHANGE0.COMPANY.COM. Я хотел бы удалить эти предупреждения, и я считаю, что есть способ сделать это через DNS или через Exchange. Я просто не знаю, что мне делать.

Автообнаружение настраивается с использованием метода SRV, если это вообще имеет значение.

РЕДАКТИРОВАТЬ: Конфигурация на клиентах выглядит следующим образом

Сервер Exchange: EXCHANGE0.COMPANY.COM Подключайтесь с помощью Outlook Anywhere (HTTP): при быстрых и медленных соединениях подключайтесь к mail.company.com и доверяйте только msstd: mail.company.com

Имя в сертификате - mail.company.com, но Outlook ожидал EXCHANGE0.COMPANY.COM.

Вы можете решить эту проблему, установив атрибуты InternalURL для различных компонентов Exchange в соответствии с вашим внешним именем (mail.company.com). Как только вы это сделаете, вы можете создать запись DNS (возможно, CNAME для «mail.company.com» на «exchange0.company.com») - похоже, вы назвали свой домен AD таким же, как ваше настоящее имя домена в Интернете. ), чтобы клиенты могли подключиться к mail.company.com и перейти на компьютер с сервером Exchange.

Команды "set" для каждого компонента, который вам нужно запустить, приведены ниже. Вы можете использовать версии этих команд «Get-», чтобы увидеть, как они настроены сейчас.

Set-ActiveSyncVirtualDirectory -InternalURL
Set-AutodiscoverVirtualDirectory -InternalURL
Set-ClientAccessServer -AutodiscoverServiceInternalUri
Set-ECPVirtualDirectory -InternalURL
Set-OABVirtualDirectory -InternalURL
Set-OWAVirtualDirectory -InternalURL
Set-WebservicesVirtualDirectory -InternalURL

У меня была эта проблема на днях на клиенте, где я (в то время) не мог понять, как заставить работать отражение NAT, так что пользователи, обращающиеся к mail.example.com в Outlook 2010 (который, по-видимому, добавляет Outlook поверх HTTP по умолчанию ) перенаправлялись на внутренний интерфейс брандмауэра (у которого был самоподписанный сертификат somefirewall.local).

Я решил проблему, настроив разделенный DNS: я создал зону для example.com в Active Directory DNS (и добавил все соответствующие записи и поддомены, такие как A, CNAME, MX, TXT и т. Д.) И убедился, что mail.example.com преобразован во внутренний IP-адрес сервера Exchange. Работает без проблем, но нужно помнить, что нужно постоянно обновлять обе зоны (реальную и внутреннюю), если для этого нет доверенного / автоматизированного метода.

РЕДАКТИРОВАТЬ

Это должно сработать для вас, если вы создаете зону для mail.company.com и создаете запись A для (родительского) для разрешения на ваш внутренний сервер Exchange, потому что, если сертификат mail.company.com установлен на Exchange, он должен быть действительным / доверенный.

Если я правильно понимаю, вы хотите перенастроить свои службы обмена для работы в одном домене (даже внутри), используя этот KB940726 или это ссылка на сайт (оба охватывают одно и то же). Ошибка постоянна для сервера Exchange 2007/2010. В противном случае вам понадобится сертификат SAN (или подстановочный сертификат), чтобы охватить более одного домена под одним и тем же сертификатом (что является дорогостоящим).

Также, если у вас мало денег или вы поддерживаете небольшую компанию, я бы порекомендовал вам использовать autodiscover.domain.com в качестве основного домена для всего (даже для подключения клиентов Outlook, owa и т. д.). Это может показаться неудобным, но это сэкономит вам расходы на сертификаты, которые требуют охвата более одного домена (сертификаты SAN). Я обнаружил, что это наиболее экономичное решение для моих небольших клиентов, которые не обязательно хотят платить 100-1000 долларов в год только за сертификат, который может обрабатывать несколько доменов под одним IP / портом.

И чтобы закончить это, вы можете получить свободно (реально бесплатно!) SSL сертификаты от StartSSL обновляется ежегодно бесплатно. Только отзыв не является бесплатным, но если вы правильно генерируете сертификаты и не теряете ключи, вы должны быть в безопасности.

Чтобы решить эту проблему, вы воля нужен новый сертификат! Это почему? Потому что вам понадобится тема сертификата, чтобы соответствовать как mail.company.com, exchange0.company.com и, предпочтительно, autodiscover.company.com.

Обходной путь - использовать подстановочный сертификат для всех служб (* .company.com).

Я исправил свой с помощью этих 4 команд (при необходимости измените имена серверов / веб-адреса)

Set-ClientAccessServer -Identity EXCHANGE-SERVER -AutoDiscoverServiceInternalUri https://exchange-server.example.com/Autodiscover/Autodiscover.xml

Enable-OutlookAnywhere -Server EXCHANGE-SERVER -ExternalHostname "exchange-server.example.com" -DefaultAuthenticationMethod "Basic" -SSLOffloading:$False

Set-OABVirtualDirectory -identity "EXCHANGE-SERVER\OAB (Default Web Site)" -externalurl https://exchange-server.example.com/OAB -RequireSSL:$true -InternalUrl https://exchange-server.example.com/OAB

Set-WebServicesVirtualDirectory -identity "EXCHANGE-SERVER\EWS (Default Web Site)" -externalurl https://exchange-server.example.com/EWS/Exchange.asmx -BasicAuthentication:$True -InternalUrl https://exchange-server.example.com/EWS/Exchange.asmx

Я перезапустил IIS после для хорошей меры.

Исправлено странное предупреждение системы безопасности при переключении в автономный режим в Outlook и обратно в рабочий режим. Оповещение появлялось через минуту после открытия Outlook. Имя в сертификате не соответствует имени соединения. Все веб-службы, oab, ecp, autodiscover, activesync, owa, um были настроены правильно.