Публикация OWA и Outlook RPC/HTTP с брандмауэрами ISA Server 2006 EE с использованием проверки подлинности на основе форм (одночленный массив без NLB): Часть 2. Проблемы развертывания DNS и сертификат

Опубликовано: 11 Апреля, 2023

Публикация Outlook Web Access и Outlook RPC/HTTP с брандмауэрами ISA Server 2006 Enterprise Edition с использованием проверки подлинности на основе форм (одночленный массив без NLB)
Публикация Outlook Web Access и Outlook RPC/HTTP с брандмауэрами ISA Server 2006 Enterprise Edition (RC) с использованием аутентификации на основе форм (одночленный массив без NLB) — часть 4. Создание правил веб-публикации и тестирование конфигурации

В первой части этой серии статей о том, как публиковать OWA и RPC/HTTP с помощью брандмауэров ISA Server 2006, я рассказал о целях разработки серии статей и объяснил сценарий и лабораторную среду, в которой выполняется настройка и тестирование.

В этой, второй части серии, я расскажу о двух ключевых проблемах, которые досаждают администраторам брандмауэра ISA: соображения DNS и вопросы развертывания сертификатов. Эти две области дизайна брандмауэра ISA и сетевой безопасности ответственны за подавляющее большинство ошибок конфигурации и разочарований, с которыми сталкиваются администраторы брандмауэра ISA. Я знаю, что вы хотите вникнуть в суть того, как настроить брандмауэр ISA для публикации сайтов OWA и RPC/HTTP, но я не могу не подчеркнуть, насколько важны эти вопросы и что вы должны хорошо разбираться в DNS и вопросы, связанные с сертификатами , прежде чем вы начнете свой путь публикации веб-сервисов брандмауэра ISA.

ПРИМЕЧАНИЕ:
Если вы уже хорошо знакомы с проблемами, связанными с DNS и сертификатами, при настройке безопасных правил веб-публикации с брандмауэрами ISA, то вы можете пропустить эту статью и подождать до следующей недели, чтобы прочитать часть 3, где мы углубимся в содержательные детали настройки брандмауэра ISA.

В частности, мы сосредоточимся на следующих вопросах:

Ценность разделенной DNS-инфраструктуры
Разделенная инфраструктура DNS в этой серии статей
Важность соглашений об именовании сертификатов

Ценность разделенной инфраструктуры DNS

Из всех проблем в сети брандмауэра ISA больше всего беспокоят людей те, которые сосредоточены вокруг обсуждения разделенной DNS. Я никогда не мог понять, почему администраторы брандмауэра ISA так устойчивы к разделенной инфраструктуре DNS. Однако, если бы мне пришлось угадывать, это могло бы быть связано с одним из следующих заблуждений:

Они считают, что им нужно переименовать свои внутренние сетевые домены — заведомо неверно
Они думают, что есть неблагоприятное воздействие на безопасность — беззастенчиво неверно
Они думают, что DNS настолько сложна для понимания, что идея дальнейшего усложнения проблемы ставит их в тупик — для некоторых людей это может быть правдой.

Правда в том, что разделенный DNS может сделать вашу жизнь и жизнь ваших пользователей намного проще. Когда у вас есть разделенная инфраструктура DNS, вы достигаете следующего:

Пользователям никогда не нужно помнить об использовании разных имен в зависимости от текущего местоположения пользователя. Одно и то же имя используется, когда пользователь находится в корпоративной сети и где-то в Интернете или на партнерском сайте.
Клиентские приложения никогда не нужно перенастраивать в зависимости от текущего местоположения пользователя. Клиенты Outlook MAPI, клиенты SMTP, клиенты POP3, клиенты IMAP4, веб-клиенты браузера, клиенты FTP и другие клиенты никогда не нуждаются в повторной настройке. Те же настройки имени сервера в корпоративной сети используются, когда пользователь находится за пределами корпоративной сети.
Внутренним хостам никогда не нужно проходить через корпоративный брандмауэр для доступа к ресурсам, расположенным в корпоративной сети. Один из лучших способов снизить производительность брандмауэра ISA — разрешить хостам в защищенной сети брандмауэра ISA зацикливаться через брандмауэр ISA для доступа к серверам в корпоративной сети. Разделенный DNS гарантирует, что вы никогда не совершите эту ошибку снижения производительности.
Вы можете сохранить свое текущее доменное имя Active Directory. Разделенный DNS не требует переименования внутренних доменов. Вы можете добавить новые DNS-домены, которые используются исключительно для поддержки вашей разделенной инфраструктуры DNS, не нарушая DNS, связанный с Active Directory.
Все версии полного клиента Outlook MAPI (97/98/200/2002/2003) будут «просто работать». Пользователь может находиться в корпоративном офисе, приостановить работу своего ноутбука, а затем открыть его в гостиничном номере за 5000 миль, и Outlook автоматически подключится к серверу Exchange в корпоративной сети. Пользователю никогда не нужно перенастраивать клиент Outlook, а его текущее местоположение полностью прозрачно, когда речь идет о доступе приложений к корпоративным сетевым ресурсам.

Как инфраструктура разделенного DNS делает жизнь лучше для всех администраторов брандмауэра ISA

Разделенный DNS делает нужные ресурсы доступными как для внутренних, так и для внешних пользователей, независимо от местоположения. Независимость от местоположения позволяет пользователям использовать одно и то же имя для доступа к корпоративным информационным ресурсам независимо от местоположения. Пользователю никогда не нужно запоминать отдельные URL-адреса или имена серверов, когда он находится в корпоративной сети или при подключении откуда-то из Интернета.

Давайте посмотрим на пример. Пользователь находится в корпоративной сети, и ему необходимо получить доступ к серверу SharePoint Portal Server по URL -адресу https://sps.domain.com. Используя разделенную инфраструктуру DNS, пользователь сможет использовать https://sps.domain.com при подключении к тому же серверу портала SharePoint из любого места в Интернете.

Другой важный пример — Outlook Web Access (OWA). Когда пользователь находится в корпоративной сети, он использует URL-адрес https:// owa.domain.com/exchange для доступа к веб-сайту OWA. Используя разделенную инфраструктуру DNS, пользователь сможет получить доступ к веб-сайту OWA из Интернета, используя тот же URL-адрес, https://owa.domain.com/exchange.

Инфраструктура разделенной DNS работает, потому что есть два или более DNS-серверов, на которых размещены зоны, ответственные за одно и то же доменное имя. Один или несколько DNS-серверов отвечают за разрешение имен для узлов, расположенных в корпоративной сети, а один или несколько DNS-серверов отвечают за разрешение имен для узлов, расположенных в Интернете.

ВНИМАНИЕ:
Это ключевое отличие — DNS-серверы, которые разрешают имена для внешних хостов, никогда не доступны для внутренних хостов. DNS-серверы, которые разрешают имена для внутренних хостов, никогда не доступны для внешних хостов. Они полностью отделены от внутренних и внешних DNS-серверов и зон, что позволяет раздельному DNS обеспечивать желаемую прозрачность расположения приложений.

DNS-сервер, отвечающий за разрешение имен в корпоративной сети (внутренний DNS-сервер и зона), содержит записи ресурсов DNS, сопоставляющие имена серверов с их внутренними сетевыми IP-адресами, которые обычно являются фактическими адресами, используемыми серверами в корпоративной сети. Я говорю «обычно», потому что на пути могут быть внутренние устройства NAT. DNS-сервер, отвечающий за разрешение имен для пользователей Интернета, разрешает имена в общедоступный IP-адрес, разрешая входящий доступ к корпоративному ресурсу. Этот общедоступный IP-адрес может быть привязан к внешнему интерфейсу брандмауэра ISA и использоваться правилом веб-публикации или сервера, или может быть привязан к устройству NAT, расположенному перед брандмауэром ISA.

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

Веб-сайты Outlook Web Access Пользователи хотят использовать один и тот же URL-адрес при подключении к OWA независимо от того, находятся ли они в корпоративной сети или в Интернете.
Веб-сайты SharePoint Portal Server Пользователи хотят использовать один и тот же URL-адрес при подключении к сайтам SharePoint Portal Service независимо от того, находятся ли они в корпоративной сети или где-то в Интернете.
Общие веб-сайты, на которых размещена корпоративная информация. То же самое и здесь — пользователи не хотят запоминать разные имена в зависимости от их текущего местоположения. Они хотят использовать одни и те же имена, где бы они ни находились.
Клиентский доступ Exchange MAPI Разделение DNS имеет решающее значение для безопасной публикации Exchange RPC. Без хорошо спроектированной разделенной DNS вы не сможете в полной мере использовать безопасность, мобильность и прозрачность, обеспечиваемые публикацией Secure Exchange RPC.
Серверы POP3 Есть много людей, которые продолжают предоставлять доступ по протоколу POP3. Конфигурация клиента POP3 может быть сложной для обычных пользователей. Сколько бы вы сэкономили на звонках в службу поддержки, если бы пользователю никогда не приходилось перенастраивать свой клиент POP3 в зависимости от его текущего местоположения?
SMTP-серверы Многие компании предоставляют доступ к SMTP-серверу как внутренним, так и внешним пользователям. Подумайте, сколько могла бы сэкономить ваша служба поддержки, если бы им не приходилось тратить время на помощь пользователям в изменении настроек их SMTP-сервера, когда они покидают офис?
Серверы IMAP4 Многие компании используют клиентов IMAP4. Вы увидите, что разделенная инфраструктура DNS дает те же преимущества, что и клиенты POP3. Больше никаких обращений в службу поддержки для изменения настроек сервера IMAP4, когда эти пользователи покидают офис.
Серверы NNTP То же самое и здесь. Нет проблем с перенастройкой клиента NNTP, когда пользователи покидают офис.
Серверы терминалов Удаленный доступ к службам терминалов становится все более популярным. Хотя вы можете предоставить своим пользователям IP-адрес для использования при подключении к корпоративной сети и другой адрес для использования в Интернете, как насчет предоставления им простого полного доменного имени, которое работает независимо от того, находятся ли они на работе или в Интернете? ?
Шлюзы SSL VPN SSL VPN — горячая тема, и она становится все более горячей с каждым днем, когда Microsoft купила Whale. Разделенный DNS станет вашим ключом к успеху для любого развертывания SSL VPN, в котором вы участвуете.

Сведения о развертывании разделенного DNS

Давайте подробнее рассмотрим дизайн нашей разделенной инфраструктуры DNS для развертывания OWA и SharePoint. У вас есть серверы Exchange и SharePoint Portal в корпоративной сети. На внутреннем DNS-сервере вы создаете две записи Host (A) в домене mydomain.net. Зона DNS:

owa.mydomain.net Эта запись сопоставляется с частным IP-адресом сервера в корпоративной сети или адресом шлюза в корпоративной сети, который обеспечивает доступ к этому серверу, как в случае внутреннего устройства NAT.
sps.mydomain.net Эта запись сопоставляется с частным IP-адресом сервера в корпоративной сети или адресом шлюза в корпоративной сети, который обеспечивает доступ к этому серверу, как в случае внутреннего устройства NAT.

На общедоступном или внешнем DNS-сервере для домена mydomain.net вы также создаете две записи Host (A):

owa.mydomain.net Эта запись сопоставляется с общедоступным IP-адресом, который обеспечивает доступ к внутреннему сайту OWA. Этот IP-адрес может быть общедоступным адресом, привязанным к внешнему интерфейсу брандмауэра ISA, или общедоступным IP-адресом, привязанным к внешнему устройству NAT, которое выполняет NAT между Интернетом и внешним интерфейсом брандмауэра ISA.
sps.mydomain.net Эта запись сопоставляется с общедоступным IP-адресом, который обеспечивает доступ к внутреннему сайту SharePoint. Этот IP-адрес может быть общедоступным адресом, привязанным к внешнему интерфейсу брандмауэра ISA, или общедоступным IP-адресом, привязанным к внешнему устройству NAT, которое выполняет NAT между Интернетом и внешним интерфейсом брандмауэра ISA.

Теперь давайте посмотрим, как клиенты разрешают имена этих серверов. Корпоративная сеть использует DHCP для назначения информации об IP-адресации узлам сети. DHCP-сервер назначает IP-адрес внутреннего DNS-сервера узлам в корпоративной сети. DNS-серверы, назначенные узлам корпоративной сети, являются полномочными для mydomain.net. Когда пользователи в корпоративной сети подключаются к owa.mydomain.net, DNS-запрос к внутреннему DNS-серверу предоставляет клиентам внутренний адрес сервера OWA. Пользователи получают прямой доступ к OWA-сайту в корпоративной сети, минуя брандмауэр или любое другое устройство, используемое для обеспечения общего доступа к OWA-сайту.

Когда пользователи перемещаются из корпоративной сети во внешнюю сеть, они подключаются к внешней сети LAN или интернет-провайдеру и получают информацию об IP-адресации через DHCP. Внешнему хосту через DHCP назначается DNS-сервер, который может разрешать имена хостов в Интернете. Когда пользователь внешней сети подключается к owa.mydomain.net, DNS-сервер предоставляет клиенту внешней сети общедоступный адрес, который вы настроили для этого ресурса на внешнем DNS-сервере, полномочном для домена mydomain.net.

На рисунке ниже показаны DNS и действия по подключению как для внутренних, так и для внешних хостов, использующих разделенную инфраструктуру DNS.

фигура 1

Внешний ноутбук отправляет DNS-запрос на внешний DNS-сервер для имени owa.mydomain.net. DNS-серверы разрешают имя, запрашивая другие DNS-серверы Интернета.
DNS-сервер возвращает публичный IP-адрес owa.mydomain.net внешнему клиенту.
Внешний клиент отправляет запрос на общедоступный IP-адрес, предоставленный DNS-сервером. Этот адрес используется для того, чтобы сделать внутренний сервер доступным для внешних пользователей. В этом запросе содержится HTTP-заголовок хоста для owa.mydomain.net.
Брандмауэр ISA должен иметь возможность разрешать имя внутреннего DNS-сервера на основе общего/субъектного имени, настроенного в сертификате веб-сайта OWA-сайта. В этом примере сервер OWA имеет сертификат с темой/общим именем owa.mydomain.net (обратите внимание, что это не имеет ничего общего с фактическим именем сервера и никак не связано с NetBIOS-именем машины или полным доменным именем Active Directory).. Брандмауэр ISA настроен на использование внутреннего DNS-сервера и разрешает имя owa.mydomain.net во внутренний IP-адрес сайта OWA.
Внутренние пользователи хотят получить доступ к внутреннему сайту OWA. Внутренний клиент OWA отправляет DNS-запрос на внутренний DNS-сервер для owa.mydomain.net на внутренний DNS-сервер. Затем клиент OWA во внутренней сети отправляет запрос на внутренний IP-адрес сервера OWA, предоставленный внутренним DNS-сервером.

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

ПРЕДУПРЕЖДЕНИЕ:
Существует много путаницы в отношении роли Active Directory в разделенной инфраструктуре DNS. Ваша разделенная инфраструктура DNS может быть интегрирована с вашим доменом Active Directory, или вы можете создать отдельную инфраструктуру DNS для разделенной DNS. Имейте в виду, что хотя Active Directory зависит от DNS, DNS не зависит от Active Directory. По этой причине вы можете создать надежную разделенную инфраструктуру DNS, не нарушая и не затрагивая ваши соглашения об именах DNS Active Directory.

Разделенная инфраструктура DNS в этой серии статей

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

Это важный вопрос, и я должен объяснить, что я имею в виду, прежде чем двигаться дальше. Существует два основных типа разделенных инфраструктур DNS, которые вы можете развернуть:

То, что я назову чистой разделенной инфраструктурой DNS, где внутреннее доменное имя Active Directory совпадает с доменным именем, используемым внешними пользователями для доступа к внутренним ресурсам.
Другой вариант, который я назову параллельной разделенной инфраструктурой DNS, где доменное имя Active Directory не имеет ничего общего с разделенной инфраструктурой DNS, используемой для вашего безопасного решения для удаленного доступа.

Инфраструктура параллельной разделенной DNS будет привлекательна для тех, кто использует незаконные доменные имена второго уровня (такие как вызывающий ужас домен.local) или кто по недействительным соображениям безопасности считает, что чистая инфраструктура разделенной DNS застрахована (это не так, но есть много «экспертов» по безопасности, которые не понимают последствия безопасности и дают этот заведомо ложный совет). Инфраструктуру параллельного разделенного DNS относительно легко настроить, но вам нужно проделать немного больше работы.

Инфраструктуры параллельных разделенных DNS работают с теми же основными принципами внутренней DNS, а внешняя DNS поддерживает те же доменные имена, при этом внутренняя DNS обеспечивает разрешение внутренних имен, а внешняя DNS обеспечивает разрешение имен для внешних клиентов в Интернете. Единственная разница здесь в том, что вам нужно создать новую зону DNS в вашей внутренней сети, чтобы поддерживать это.

Например, рассмотрим следующее:

Внутреннее DNS-имя домена Active Directory — corp.net.
Некоторые «эксперты» по безопасности обманули руководство, запретив вам использовать доменное имя corp.net для безопасных подключений удаленного доступа.
У вас уже есть внешнее доменное имя, которое вы хотите использовать с именем externalcorp.net для безопасных подключений удаленного доступа.

В этом примере вы создаете новую зону на внутреннем DNS-сервере для домена externalcorp.net. Затем вы вводите записи ресурсов для всех серверов в корпоративной сети, которые будут принимать входящие подключения от внешних пользователей. Вам не нужно реплицировать всю вашу внутреннюю систему DNS, вы включаете только записи для опубликованных серверов. Хотя в более крупных средах это может быть истолковано как слишком большая административная нагрузка, я думаю, вы обнаружите, что это не так, поскольку IP-адреса серверов статичны и редко меняются.

На внешней стороне DNS ничего менять не нужно. Если у вас уже настроена внешняя зона DNS для домена externalcorp.net, все готово. Добавление внутренней зоны не влияет на конфигурацию внешней зоны. Это верно как для чистых конфигураций разделенных DNS, так и для параллельных конфигураций разделенных DNS.

Сквозное соглашение об именах разделенных DNS

В лабораторной конфигурации, которую мы будем использовать в этой серии статей, я буду использовать подмножество инфраструктуры чистой разделенной DNS, применяя соглашение об именовании сквозной разделенной DNS. В окончательном разделенном соглашении об именах DNS внешние пользователи FQDN используют для доступа к опубликованным веб-серверам то же имя, которое использует брандмауэр ISA. Единственная разница в том, что внешние пользователи подключаются к опубликованным веб-серверам через общедоступный IP-адрес, а брандмауэр ISA подключается к серверам через их частные IP-адреса.

Мы используем общедоступное имя owa.msfirewall.org в нашем правиле веб-публикации для правил веб-публикации OWA и RCP/HTTP. Брандмауэр ISA также будет настроен на использование того же имени, owa.msfirewall.org, при переадресации соединения на внутренние серверы Exchange. Я делаю это из удобства, а не по необходимости. Это заблуждение, что вы должны использовать сквозную схему именования, и это не так. Однако, если вы этого не сделаете, это может создать потенциальные сложности для вашей разделенной инфраструктуры DNS и удалить большую часть предоставляемых ею утилит.

Например, я мог бы настроить внешних пользователей на использование owa.msfirewall.org для подключения к опубликованному сайту OWA и RPC/HTTP, а затем настроить брандмауэр ISA для переадресации соединения как mail.msfirewall.org. Это бы сработало, но сломало бы нашу разделенную инфраструктуру DNS, потому что пользователи, находящиеся в Интернете, должны были бы не забывать использовать owa.msfirewall.org, а когда эти пользователи возвращались бы в корпоративную сеть, они должны были бы не забывать использовать почту. msfirewall.org. Поскольку весь смысл использования разделенной инфраструктуры DNS заключается в том, чтобы избежать этой проблемы, нет особого смысла использовать сквозную схему именования.

Существует еще одна проблема, связанная с тем, что не используется сквозная схема именования DNS с разделением, и она связана с сертификатами и общим/субъектным именем в этих сертификатах. Мы обсудим этот вопрос в следующем разделе.

Важность соглашений об именах сертификатов

Давайте продолжим наш предыдущий пример, чтобы понять, почему соглашения об именах сертификатов имеют решающее значение в разделенной инфраструктуре DNS. Как видно из этого примера, пользователи нашей тестовой сети смогут получить доступ к веб-сайтам OWA и RPC/HTTP, используя имя owa.msfirewall.org, когда они находятся во внутренней сети за брандмауэром ISA, а также когда они находятся где-то еще. в Интернете. Это связано с тем, что мы используем сквозное соглашение об именовании разделенных DNS.

Теперь давайте предположим, что мы не используем сквозную разделенную систему соглашений об именах DNS. В этом случае общее/субъектное имя в сертификате веб-сайта, привязанном к веб-прослушивателю, публикующему сайты OWA и RPC/HTTP, будет owa.msfirewall.org. Поскольку мы не используем сквозную разделенную схему именования DNS, мы привяжем сертификат к прокси-серверу OWA и RPC/HTTP с именем mail.msfirewall.org. Как вы думаете, каковы будут последствия этой конфигурации?

Внешние пользователи смогут использовать имя owa.msfirewall.org для доступа к веб-сайтам OWA и RPC/HTTP, поскольку веб-прослушиватель прослушивает подключения к owa.msfirewall.org, а общее/субъектное имя в сертификате — owa.msfirewall. .орг.
Брандмауэр ISA настроен на перенаправление подключений к mail.msfirewall.org, потому что это имя в сертификате веб-сайта, привязанном к веб-сайту OWA и RPC/HTTP. Имя mail.msfirewall.org разрешается в фактический IP-адрес веб-сайта во внутренней сети (при условии, что на пути нет внутренних устройств NAT).
Внутренние пользователи используют имя mail.msfirewall.org для подключения к веб-сайту OWA и RPC/HTTP, так как это общее/субъектное имя в сертификате, связанном с сайтом. Внутренние пользователи могут подключаться, поскольку запрос относится к сайту с тем же именем, что и в сертификате веб-сайта.
Теперь пользователи должны не забывать использовать https://owa.msfirewall.org/exchange при подключении из внешнего местоположения и https://mail.msfirewall.org/exchange при подключении из внутреннего местоположения.
Кроме того, теперь пользователи должны не забывать перенастраивать свою конфигурацию Outlook RPC/HTTP в зависимости от своего местоположения. Когда пользователи находятся в Интернете, они должны настроить свой клиент Outlook для подключения к owa.msfirewall.org, а когда они находятся во внутренней сети, они должны настроить клиент Outlook для подключения к mail.msfirewall.org или использовать MAPI. соединений, что на самом деле является настройкой по умолчанию.

Ситуация не так страшна для клиентов RPC/HTTP, так как они должны быть настроены на использование MAPI RPC при подключении к корпоративной сети, но мы все знаем по опыту, что часто все работает не так чисто, и иногда RPC /HTTP-подключение используется в корпоративной сети, когда оно не должно использоваться (занятая сеть с относительно высокими задержками). Ситуация критическая для пользователей OWA, которые теперь должны помнить об использовании разных имен в зависимости от их местоположения.

Соглашения об именах сертификатов имеют решающее значение, поскольку они определяют ваш успех или неудачу при настройке брандмауэра ISA и опубликованных веб-серверов для безопасных соединений. Некоторые вещи, которые следует учитывать в отношении соглашений об именах сертификатов:

Общее/субъектное имя в сертификате должно совпадать с именем, используемым клиентом для подключения к сайту. Если клиент подключается к http://owa.domain.com, общее/субъектное имя в сертификате должно быть owa.domain.com.
Общее/субъектное имя в сертификате не имеет никакого отношения к фактическому NetBIOS-имени или DNS-имени компьютера. Однако для подключения к серверу в сертификате, связанном с веб-сайтом или веб-приемником, должна быть запись DNS для общего имени/имени субъекта, поскольку это имя используется пользователями для подключения к серверу. Например, DNS-имя компьютера в Active Directory может быть serverA.domain.com, но сертификат веб-сайта, связанный с веб-сайтом, имеет общее/субъектное имя mail.domain.com. Для обоих этих имен требуется запись DNS, но они имеют один и тот же IP-адрес.
Несколько правил веб-публикации могут выполнять переадресацию на одно и то же имя, даже если они прослушивают веб-прослушиватели, которые имеют разные сертификаты с разными общими именами/темами. Например, веб-прослушиватель 1 прослушивает подключения к rpc.msfirewall.org, а веб-прослушиватель 2 прослушивает подключения к mail.domain.com. Правила веб-публикации, использующие эти веб-прослушиватели, можно настроить для переадресации подключений к одному и тому же безопасному сайту, который использует сертификат веб-сайта с общим именем exchange.msfirewall.org.

Как видно из этих примеров, имена сертификатов и конфигурация DNS зависят друг от друга. Сломанный DNS нарушит правильно настроенную инфраструктуру сертификатов, а сломанная инфраструктура сертификатов нарушит хорошо спроектированную инфраструктуру DNS.

Резюме

Прежде чем развертывать решение брандмауэра ISA для безопасной публикации OWA и веб-сайтов RPC/HTTP, вам необходимо рассмотреть вопросы имен DNS и сертификатов. Лучшим DNS-решением для безопасного удаленного доступа к сайтам OWA и RPC/HTTP является чисто разделенная инфраструктура DNS, за которой следует параллельная разделенная инфраструктура DNS. Очень плохое дизайнерское решение DNS для безопасного удаленного доступа к сайтам OWA и RPC/HTTP заключается в использовании совершенно разных имен для внутреннего и внешнего доступа, что требует от пользователей помнить об использовании разных имен в зависимости от их текущего местоположения.

Именование сертификатов тесно связано с вашей инфраструктурой DNS. Общее/субъектное имя в сертификате должно совпадать с именем, которое пользователь использует для подключения к сайту. При публикации безопасных веб-сайтов с использованием брандмауэров ISA внешний пользователь должен использовать имя сертификата веб-сайта, используемого в веб-прослушивателе правила веб-публикации, а брандмауэр ISA должен подключаться к опубликованному веб-серверу, используя имя, привязанное к опубликованному веб-сайту..

В следующей статье этой серии мы перейдем к самому интересному — к настройке брандмауэра ISA для публикации веб-фермы интерфейсных серверов Exchange. Тогда увидимся! -Том.

Публикация Outlook Web Access и Outlook RPC/HTTP с брандмауэрами ISA Server 2006 Enterprise Edition с использованием проверки подлинности на основе форм (одночленный массив без NLB)
Публикация Outlook Web Access и Outlook RPC/HTTP с брандмауэрами ISA Server 2006 Enterprise Edition (RC) с использованием аутентификации на основе форм (одночленный массив без NLB) — часть 4. Создание правил веб-публикации и тестирование конфигурации

Кибер-безопасность