На прошлой неделе я говорил вам о том, как можно, вероятно, использовать два Web-слушателя для публикации как сайтов OWA, ActiveSync и Outlook Anywhere, так и сайтов Outlook Autodiscover. Тогда я не был уверен, что это будет работать, так как имелась масса нерешенных вопросов, но теперь я могу смело говорить, что у меня есть работающая схема, которой я и поделюсь в этой статье.
Перед тем, как окунуться в детали публикации сайта Outlook Autodiscover, я хочу отвлечься на короткое время и поговорить о двух альтернативных подходах, которые я опишу в ближайшее время.
Первый альтернативных подход заключается в использовании SRV-записей в вашем публичном DNS для информирования клиентов Outlook Anywhere о FQDN и IP-адресе, который они могут использовать для доступа к сайту Outlook Autodiscover. Если вы просмотрите статью из базы знаний здесь: http://support.microsoft.com/kb/940881, вы найдете, что вам необходим только одно FQDN, один IP-адрес и один Web-слушатель, чтобы все заработало. В то время как решение, которое я опишу сегодня, требует только единственного Web-слушателя, оно не требует двух IP-адресов, так как нам нужны два сертификата с разными именами.
Подход SRV-записи очень хорош и значительно упрощает конфигурирование Web-слушателя на ISA Firewall. Однако Джим Харрисон предупреждает нас, что это не панацея:
«Проблема в том, что многие приложения под CERN, SOCKS или Socket прокси не могут использовать SRV-записи.
Другими словами, в редких случаях клиент, обслуживаемый прокси, будет даже делать поиск, и значительно реже он получит SRV запись».
Следовательно, вы не можете зависеть от SRV записей, когда клиент под устройством прокси, которое разрешает имена на стороне клиента. Единственная причина, почему клиент Outlook Anywhere способен «поглощать» SRV запись, заключается в том, что, после того, как поставлена заплата на клиент, сам клиент может использовать SRV запись. Как вы можете видеть, это проблема, связанная с клиентом, поэтому большинство прокси-серверов не создаются для SRV записей Outlook Anywhere, она не будет работать с ними в пути. Это означает, что вы можете воспользоваться преимуществами SRV подхода только для ваших внешних клиентов, которые не расположены за Web или SOCKS прокси устройством, которое разрешает имена на стороне клиента.
Это все еще не должно быть проблемой для ваших внутренних клиентов, которые пытаются достичь внешнего Outlook Autodiscover сервера, так как разделенный DNS позаботиться об этой проблеме. Внешняя часть DNS будет содержать DNS записи для autodiscover.domain.com, а внутренняя часть разделенного DNS будет содержать DNS SRV записи для автообнаружения URL.
Наконец, существует третий вариант, и этот вариант, возможно, будет самым популярным в зависимости от вашей среды. Третий вариант — использовать Kerberos Constrained Delegation для ваших правил публикации Web Publishing Rules и создать два Web-слушателя с двумя сертификатами и двумя IP-адресами. Что вы получаете с такой конфигурацией? Вы получаете возможность входить в Outlook Anywhere без необходимости вводить ваш IP-адрес каждый раз. Недостаток, естественно, в том, что нужно использовать два IP-адреса.
В то время как варианты SRV записей и Kerberos Constrained Delegation являются интересными, и о них стоит знать, мы должны закончить работу, начатую нами на прошлой неделе по использованию двух IP-адресов, одного Web-слушателя и двух сертификатов для публикации сайтов OWA, ActiveSync, Outlook Anywhere и Outlook Autodiscover.
Нужно сделать следующее:
Так как мы должны использовать второе FQDN, чтобы получить доступ к сайту Outlook Autodiscover, нам нужен второй сертификат, чтобы мы могли создавать защищенное соединение с ISA Firewall. Мы можем использовать сайт Web-регистрации для получения сертификата с сертификационного сервера, расположенного на DC машине.
Когда вы попадете на сайт Web-регистрации, выберите ссылку Request Certificate. На следующей странице сайта щелкните на Advanced certificate request. На странице Advanced Certificate Request щелкните на ссылку Create and submit a request to this CA. Выберите шаблон сертификата Web Server и в окошке Name введите FQDN службы автообнаружения. В нашем примере мы будем использовать autodiscover.msfirewall.org. Поставьте галочку напротив Store certificate in the local computer certificate store. Сертификат CA уже установлен на ISA Firewall, так как ISA Firewall является членом домена, и мы используем учреждение CA.
Щелкните на Submit и завершите мастер. Позвольте ему установить сертификат для вас, когда достигнете этого шага.
Рисунок 1
Не много можно добавить к созданию Web-слушателя что мы проделали на прошлой неделе. Следующие скриншоты показывают основные аспекты Web-слушателя, который используется для всех наших правил Web Publishing Rules.
На вкладке Networks вы можете видеть, что Web-слушатель прослушивает как внешний, так и внутренний интерфейс. Внешний интерфейс имеет два IP-адреса, а внутренний интерфейс имеет один IP-адрес. Внутренний интерфейс используется для поддержки внутренних клиентов, которые хотят использовать OWA, так что они могут выиграть от фильтров Forms-based authentication (аутентификация, базирующаяся на формах) ISA Firewall, а также HTTP Security ISA Firewall.
Рисунок 2
На вкладке Connections вы видите, что этот Web-слушатель настроен на прослушивание только SSL соединений.
На вкладке Certificates вы можете видеть, что сертификат с общим/субъектным именем owa.msfirewall.org связан с IP-адресами 10.0.0.1 и 192.168.1.71. Сертификат с именем autodiscover.msfirewall.org связан с IP-адресом 192.168.1.72. Убедитесь, что публичные и приватные DNS записи в вашей инфраструктуре разделенного DNS отражают эти имена и адреса.
На вкладке SSO мы установили домен с единым входом msfirewall.org. Это означает, что, когда пользователи заходят на один сервер в домене Active Directory msfirewall.org, им не нужно будет повторно авторизоваться, когда они соединяются с другой машиной из того же домена.
На вкладке Authentication выбрана опция HTML Form Authentication, и ISA Firewall использует Windows (Active Directory) качестве Authentication Validation Method(Метод проверки авторизации), что является наилучшим решением с точки зрения безопасности ISA Firewall, поскольку ISA Firewall является членом домена.
На вкладке Forms настройками формы по умолчанию являются настройки, определенные мастером Web Publishing Rule Wizard при создании правила Web Publishing Rule. Нет никаких причин что-либо изменять на этой странице.
Теперь нам надо внести некоторые изменения в настройки Web Publishing Rule для поддержки нашего FQDN autodiscover.msfirewall.org.
Двойной щелчок на правило Web Publishing Rule Outlook Anywhere и затем щелчок на вкладку Public Name. Ранее мы использовали owa.msfirewall.org в качестве публичного имени, но теперь мы должны изменить его для поддержки публикации службы Autodiscover. Используйте кнопку Remove для удаления записи owa.msfirewall.org и кнопку Add, чтобы добавить запись autodiscover.msfirewall.org щелкните Apply.
Рисунок 3
Щелкните вкладку Paths. На этой вкладке вы увидите пути, к которым правило имеет доступ на сервере клиентского доступа, когда запрос идет для autodiscover.msfirewall.org. Отметьте, что клиент Outlook Anywhere не только получает доступ к службе Autodiscover через autodiscover.msfirewall.org, но также использует FQDN autodiscover.msfirewall.org для достижения RPC/HTTP прокси, что демонстрируется фактом, что это правило может пересылать в директорию /rpc/* на сервере клиентского доступа.
Щелкните на вкладку Authentication Delegation. Раньше мы использовали делегирование NTLM, и оно хорошо работала для соединения RPC/HTTP. Однако если вы попытаетесь использовать делегирование NTLM для публикации и службы Autodiscover, и службы RPC/HTTP, вы выясните, что клиент будет все время получать приглашение ввести логин и пароль, и никогда не сможет войти. Я не знаю, почему так происходит, хотя настройкой по умолчанию для директории /Autodiscover/* является поддержка как базовой, так и интегрированной авторизации. Может быть, ответ лежит во внутреннем устройстве некоторой команды Powershell, но я не могу понять, какую именно из миллиона команд использовать для решения проблемы. Если вы вдруг это выясните, дайте мне знать.
Измените Method used by ISA Server to authenticate to the published Web server на Basic authentication и затем щелкните Apply.
Щелкните на вкладку Bridging. Здесь вы увидите, что только Redirect requests to SSL port включено, и по умолчанию как порт TCP используется порт 443. Не изменяйте это значение.
Щелкните на вкладку Users. Здесь по умолчанию стоит All Authenticated Users. Это всего лишь установка по умолчанию. Если вы хотите создать свою группу пользователей, которой вы хотите разрешить доступ к RCP/HTTP, можете сделать это здесь.
Щелкните на вкладку To. Обратите внимание, что мы не будем изменять запись в окне This rule applies to this published site. Это может сильно смутить вас, так как все выглядит так, как будто мы собираемся везде поменять публичные FQDN и URL, которые мы хотим использовать для сайта службы Autodiscover. Но мы должны использовать имя owa.msfirewall.org здесь, так как это имя на сертификате Web-сайта, связанного с сайтом сервера клиентского доступа.
Я думаю, одна из главных причин смятения в этой области связана с пользователем Subject Alternative Names на сертификате сайта, связанного с сайтом сервера клиентского доступа. Факт тот, что:
ISA Firewall не может использовать альтернативное имя субъекта. Точка. Больше нет вопросов.
Сейчас я могу от вас услышать: «Но Джим Харрисон говорил в своем ISA блоге, что ISA Firewall может действовать в качестве клиента по отношению к публикуемому сайту и использовать SAN”. Проблема с этим утверждением Джима в том, что на практике ISA Firewall не может использовать SAN, представленные публикуемым сервером, так как общее/субъектное имя и первое SAN (которое теоретически является единственным SAN, которое распознает ISA Firewall) должны быть одинаковыми. А раз они должны быть одинаковыми, конечный результат заключается в том, что ISA Firewall не может использовать ни единого SAN в сертификате сайта сервера клиентского доступа.
В окне Computer name or IP address убедитесь, что используете IP адрес или действительное имя машины во внутренней сети. Простейший способ для этого — использовать кнопку Browse и найти имя сервера клиентского доступа во внутренней сети.
Теперь вам надо окунуться в темные пещеры страшной среды PowerShell (Powerhell). Причиной этому служит необходимость (как я думаю) указать URL для службы Autodiscover на сервере клиентского доступа. Для того чтобы сделать это, нужно открыть EMS и выполнить следующую команду:
Set-ClientAccessServer -Identity "EXCH2007CAS" -
AutodiscoverServiceInternalURI
“https://autodiscover.msfirewall.org/autodiscover/autodiscover.xml”
Рисунок ниже показывает, как я потратил целый час на то, чтобы выяснить, как при помощи разных команд Powershell установить URL Autodiscover и проверить, действительно ли он был правильно установлен. Давайте же надеяться, молиться и просить, чтобы эту проблему исправили в Exchange 2007 SP1. Как и многие из вас, я, когда мне нужно окунуться в PowerShell, трачу целый час на выполнение пятиминутной задачи.
Рисунок 4
В нашей тестовой среде нужно убедиться, что внешний клиент может разрешать наш сайт службы Autodiscover. Откройте файл HOSTS в c:\windows\system32\drivers\etc, использую Notepad(Блокнот). Введите IP-адрес, который прослушивает сайт Autodiscover. Это тот IP-адрес, к которому вы привязали сертификат autodiscover.msfirewall.org. На рисунке ниже показаны строчки в файле HOSTS для нашего тестового клиента.
Рисунок 5
В среде вашего продукта эти FQDN будут содержать записи хоста (A) в вашем публичном DNS.
Теперь нам надо перейти к серверу клиентского доступа и внести некоторые изменения для поддержки FQDN доступа как к службе Autodiscover, так и к службе RPC/HTTP.
Откройте Exchange Management Console, расширьте Server Configuration и щелкните на Client Access. Двойной щелчок мыши на имени сервера клиентского доступа в верхней части центральной панели, и вы увидите диалоговое окно Properties для сервера клиентского доступа. Щелкните на вкладке Outlook Anywhere. Раньше у нас было записано owa.msfirewall.org в текстовом окне External host name Нам нужно изменить (как я думаю) этот текст на autodiscover.msfirewall.org, а также нам надо изменить авторизацию на Basic authentication(Рисунок ниже).
Я знаю, что я писал в прошлой статье, что нам следует использовать NTLM авторизацию, так что мы получим доступ к некоторым новым, но неопределенным «специальным функциям», включенным в Outlook 2007. Мне кажется, нам стоит отказаться от этих «специальных функций», если мы хотим использовать одинаковое правило для нашего доступа к RPC/HTTP и службе Autodiscover.
Я также замечал в предыдущих статьях, что не представляю себе, что нам нужно в таких случаях вносить в эти текстовые окна External Host Name. Джейсон Джонс сообщил мне, что нужно ввести правильное внешнее FQDN в эти текстовые окна, в противном случае ничего не будет работать. Надо сказать, что нам нужно использовать тот URL, что используют внешние клиенты для доступа к данной службе. Я поверю словам Джейсона и введу новое FQDN в текстовое окно.
Рисунок 6
Так как мы находимся с Exchange Management Console на сервере клиентского доступа, мы можем также указать внешний URL для автономной адресной книги. Внизу средней панели щелкните на вкладку Offline Address Book Distribution, затем двойной щелчок на записи OAB (Default Web Site).
В диалоговом окне OAB (Default Web Site) Properties щелкните на вкладку URLs. В окне External URL введите новое FQND. Раньше у нас стояло owa.msfirewall.org в качестве FQDN для внешнего URL. Мы должны ввести теперь новый URL, то есть autodiscover.msfirewall.org. Щелкните Apply, а затем OK.
Я не совсем уверен, должны ли мы выполнять следующий шаг, но он точно не повредит. У Exchange 2007 странные и неопределенные отношения с настройками IIS, поэтому нужно перезапустить IIS, чтобы новые настройки заработали.
Откройте командную строку и введите команду:
Iisreset –noforce
И нажмите ENTER. Это перезапустит IIS и, надеюсь, заставит работать новые настройки, которые мы выполнили в Exchange Management Console.
Кстати, перед тем, как мы поставим клиент и проверим, все ли работает, вот какие у меня ISA Firewall Rules:
Теперь мы готовы настроить профиль Outlook и протестировать настройки Autodiscovery. Щелкните Start, затем щелкните правой кнопкой мыши на иконке E-mail. Щелкните Properties.
Рисунок 7
В диалоговом окне Mail Setup щелкните кнопку Show Profiles.
В диалоговом окне Mail щелкните кнопку Add.
В диалоговом окне New Profile введите имя профиля в текстовом окне Profile Name. В этом примере мы будем использовать имя Admin3. Щелкните OK.
На странице Auto Account Setup введите имя пользователя в текстовом окне Your Name, ваш электронный адрес в окне E-mail Address и ваш пароль в окнах Password и Retype Password. Щелкните Next.
Введите ваше пользовательское имя и пароль в диалоговом окне Connect to. Убедитесь, что используете формат домен/имя и щелкните OK.
Да! Сработало. На странице Congratulations вы можете увидеть, что все работает, и что e-mail аккаунт успешно настроен на использование Microsoft Exchange. Щелкните Finish.
В диалоговом окне Mail выберите Always use this profile и выберите тот профиль, который только что создали. В данном примере профиль называется Admin3. Щелкните OK.
Запускаем Outlook. Да! Все заработало, и мы соединились с Exchange через ISA Firewall, используя настройки Autodiscover.
Если вы посмотрели на настройки, созданные службой Autodiscover, вы могли увидеть, что она указала autodiscover.msfirewall.org в качестве прокси-сервера и также настроила запись msstd:. Отлично! Все почти так хорошо, что я забываю о травмах, полученных от использования PowerShell.
Зажмите клавишу CTRL на клавиатуре и щелкните правой кнопкой мыши на иконке Outlook в системном трее. Щелкните на команду Connection Status в списке справа.
На рисунке ниже вы увидите, что мы добились успеха в создании RPC/HTTP соединения, как видно в колонке Conn мы используем HTTPS.
Рисунок 8
И для интересующихся: вот на что похожа конфигурация Test E-mail AutoConfiguration:
Рисунок 9
Похоже, нам еще многому надо научиться, чтобы получить полнофункциональный Exchange Server, работающий с ISA Firewall. Я подожду выхода Exchange Server 2007 SP1, прежде чем попробовать взять за службы IMAP4 и POP3 и Autodiscovery для этих клиентов. Нам все еще нужно получить также рабочую «службу» SMTP, чтобы мы могли убедиться, что можно отправлять исходящую почту и принимать входящую.
В этой статье мы познакомились с деталями публикации службы Autodiscover, входящую в Exchange 2007. Методы, использованные в этой статье, включали в себя использование 2 IP-адреса на внешнем интерфейсе ISA Firewall и привязывание различных сертификатов каждому IP-адресу. В начале статьи мы обсудили еще два метода. Один метод, требующий всего один IP-адрес, использует SRV записи DNS для публикации службы Autodiscover. Второй метод, требующий два IP-адреса и два сертификата и принудительное делегирование для Kerberos, позволяет внешним RPC/HTTP клиентам избежать ввода пароля при каждом входе, включая интегрированную авторизацию на Web-слушателе. Я буду освещать детали этих двух методов в будущих статьях. Спасибо!
www.isaserver.org
Tags: dns, domain, Exchange, imap, ISA Server, nat, redirect