Outlook web access 2007 настройка

Обновлено: 04.07.2024

Многие предприятия используют Outlook Web Access (OWA) исключительно для работы с электронной почтой вне офиса. Но OWA, особенно в сочетании с Service Pack 1 для Exchange Server 2007, предоставляет более широкие возможности. В статье рассматриваются новые функции OWA, в частности, доступ к файлам через сеть Internet, и даются рекомендации администратору в отношении соответствующих настроек

Exchange Server 2007 значительно улучшен по сравнению с Exchange Server 2003. Microsoft основательно поработала и над Outlook Web Access. Администрирова-ние OWA в Exchange Server 2007 стало гораздо удобнее. Все настройки интегрированы в управляющую консоль и оболочку управления Exchange. Для настройки OWA уже не требуется никаких дополнительных инструментов или управляющих программ информационных служб Internet (Internet Information Services, IIS). Пользователи могут самостоятельно настраивать интерфейс в соответствии со своими предпочтениями.

По внешнему виду Outlook Web Access все больше напоминает Outlook, то же самое можно сказать и о функциональности. В OWA появилась поддержка правой кнопки мыши, что позволило существенно облегчить управление, которое теперь сопоставимо с обычной работой за компьютером. OWA в Exchange 2003 использует язык, заданный в браузере, а это затрудняет работу в заграничных командировках. В Exchange Server 2007 можно устанавливать параметры языка независимо от браузера.

При скачивании вложений улучшено сжатие Gzip, и объем передаваемых данных оказывается существенно меньше. Тем самым, Microsoft учла, что иногда внешним сотрудникам требуются не только электронные письма, но и эффективный доступ к другим данным. OWA в Exchange Server 2007 впервые дает возможность получать файлы с серверов файлов или SharePoint, а также читать документы, даже если нужная программа не установлена на рабочем компьютере: OWA передает аутентификационные данные текущего пользователя серверам файлов, защищая ее посредством шифрования SSL, т.е. выступает в качестве обратного посредника (Reverse Proxy). В результате доступ для чтения предоставляется к любым сетевым путям. Из соображений безопасности эту функцию можно деактивировать или включить лишь для некоторых пользователей.

ТЕХНИЧЕСКИЕ НОВШЕСТВА В OUTLOOK WEB ACCESS

Exchange Server 2007 предусматривает возможность совместной работы CAS и внутренних серверов (Back-end) Exchange Sever 2000/2003: в этом случае сервер клиентского доступа выполняет роль внешнего сервера Exchange Server 2000/2003. Правда, для улучшения взаимодействия серверов Microsoft настоятельно рекомендует установить Exchange Server 2007. По умолчанию доступ OWA активирован для всех пользователей. Системные администраторы могут активировать или деактивировать эту функцию в консоли управления Exchange в свойствах пользовательских учетных записей на вкладке «Свойства почтового ящика». Управление учетными записями осуществляется в разделе «Настройка получателя/почтовый ящик».

SERVICE PACK 1 ДЛЯ EXCHANGE SERVER 2007

Service Pack 1 предоставляет пользователям OWA поддержку личных списков рассылки, а также доступ к общим папкам без необходимости выхода из почтового ящика. Гораздо лучше поддерживаются правила и редакторы для ассистентов. Можно настраивать имеющиеся правила приема почты или создать новые. Все правила, созданные в OWA, находятся на сервере, поэтому они будут доступны даже при соединении через Outlook. Пользователи могут создавать формуляры и записи для своих адресных книжек, а также восстанавливать удаленные электронные письма, обращаясь к корзине сервера напрямую через OWA. Помощь администратора теперь не требуется, что приводит к заметному снижению нагрузки на отдел ИТ. Вид календаря также можно настраивать: к примеру, активировать отображение по месяцам, в то время как в прежней версии предлагалось отображать только по неделям или дням.

ДОСТУП К ВЛОЖЕННЫМ ФАЙЛАМ

При доступе через Outlook Web Access осуществляется разграничение общедоступных и личных компьютеров. Регистрируясь в OWA, пользователи могут выбрать тип компьютера, с которого они соединяются со своим почтовым ящиком (см. Рисунок 1), а системный администратор заранее определяет, к каким вложенным данным разрешен доступ в каждом случае (см. Рисунок 2). К примеру, для тех сотрудников, кто подключился к сети, находясь в Internet-кафе, можно запретить работу с таблицами Excel, содержащими конфиденциальные корпоративные данные.

По умолчанию Exchange Server 2007 разрешает доступ ко всем типам вложений со всех компьютеров, поэтому необходимые настройки рекомендуется произвести как можно скорее после внедрения Exchange Server 2007. Для этого в консоли управления Exchange имеется несколько разделов, а соответствующие настройки находятся в разделе «Свойства» виртуального каталога «OWA» на вкладке «Настройка сервера/доступ клиентов». Там представлены различные опции для разных типов компьютеров. Вкладка «Установить доступ к данным с личных компьютеров» предназначается для настроек «личных компьютеров», которые пользователи могут выбрать при регистрации
в OWA. Возможности конфигурации на этой вкладке идентичны настройкам вкладки «Доступ к данным с общественных компьютеров», ограничивающей доступ с незащищенных компьютеров.

Доступ возможен как к известным, так и к неизвестным типам файлов. По умолчанию для незнакомых файлов включена опция «принудительное сохранение». При деактивации настройки «Активировать прямой доступ к данным» Exchange Server блокирует доступ к любым вложенным файлам. После нажатия на кнопку «настроить» можно указать, какие вложения OWA будет блокировать, а к каким доступ пользователей разрешен (см. Рисунок 3):

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

Функцию просмотра документов в режиме Web (Webready Document Viewing) можно активировать или деактивировать здесь же, во вкладках «Доступ к данным с личных компьютеров» и «Доступ к данным с общественных компьютеров». C помощью кнопки «Поддержка» системным администраторам предлагается настроить типы данных, для которых будет поддерживаться просмотр документов в режиме Web. По умолчанию эта функция активирована для всех типов файлов.

ДОСТУП К РАЗРЕШЕННЫМ ФАЙЛАМ И СЕРВЕРАМ SHAREPOINT

Новая функция в OWA — возможность доступа для чтения к разрешенным данным и серверам SharePoint. Для этого появилась новая кнопка «документы», при нажатии на которую OWA отображает все связанные разрешенные разделы (при наличии соответствующих полномочий). Через ссылку «Открыть путь» можно ввести имя разрешенного раздела в соответствии с правилами универсального соглашения об именовании (Uniform Naming Convention, UNC).

Если сохранить имя файла в избранном, дальнейший доступ к нему ускорится. Доступ к разрешенным разделам серверов файлов и к серверам SharePoint настраивается параллельно с функцией просмотра документов в режиме Web. Если такой просмотр предназначается для чтения вложений электронных писем, то задачей удаленного доступа является доступ к определенным файлам. Эта функция активирована по умолчанию, поэтому системным администраторам нужно настроить ее сразу после внедрения Exchange Server 2007, чтобы избежать кражи данных или их нецелевого использования. Впрочем, сама по себе она особой опасности не представляет, поскольку серверы закрыты для несанкционированных пользователей.

Настройка указанной функции опять-таки производится в разделе «Свойства» виртуального каталога OWA в консоли управления Exchange (см. Рисунок 4). Здесь тоже проводится различие между доступом с общественных и личных компьютеров. Опции для общей активации или деактивации доступа к данным находятся на тех же вкладках, что и параметры просмотра документов в режиме Web. Доступ к серверам данных и серверам SharePoint можно настраивать отдельно. Во вкладке «Удаленные серверы файлов» следует указать, какие именно серверы будут открыты для пользователей.

Для серверов (но не отдельных данных) можно создавать разрешительные и запретительные списки, а кроме того, установить, как поступать при обращении к серверу, не включенному ни в один из списков. Все серверы, находящиеся в запретительном списке, недоступны через OWA, тогда как серверы из разрешительного списка предоставляют файлы. По умолчанию Exchange блокирует все серверы, не входящие ни в один из списков. Благодаря этим опциям, предприятия могут четко указать пользователям, откуда и какие серверы с определенными типами данных будут им доступны. При вызове кнопки «Настроить» открывается новое окно, содержащее доменные имена серверов SharePoint, к которым у пользователей есть допуск. Данный раздел особенно полезен в случае применения вложенных доменов, поскольку позволяет получить список доступных серверов SharePoint.

ПРЕДОСТАВЛЕНИЕ OWA C ISA 2006

Outlook Web Access можно удобно и безопасно публиковать в Internet с помощью сервера Internet Security and Acceleration (ISA). Идеальный вариант предусматривает шифрование SSL, сервер клиентского доступа и собственный центр сертификации. ISA Server 2006 содержит ряд улучшений в области публикации серверов вообще и серверов Web в частности, а также несколько новых и расширенных механизмов аутентификации. ISA 2006 автоматически реализует функцию распределения нагрузки Web при публикации OWA.

При помощи технологии мостов SSL (SSL-to-SSL-Bridging) ISA Server 2006 обеспечивает сквозную защиту (End-to-End) и фильтрацию на уровне приложений, предоставляя аутентифицированный и зашифрованный клиентский доступ. Для этого сервер исследует зашифрованные данные, прежде чем они достигнут сервера Exchange. Сервер ISA 2006 расшифровывает поток SSL, производит проверку его состояния, повторно зашифровывает данные и передает их серверу Exchange. При публикации через ISA клиент в сети Internet и сервер ISA формируют туннель SSL. Еще один туннель SSL, находящийся между сервером ISA и сервером Exchange, дополнительно защищает соединение. Эта технология применения двух разных туннелей SSL именуется мостом SSL. Она обеспечивает стабильное и надежное предоставление электронных писем, а также доступ к серверам данных и SharePoint.

Томас Йоос — независимый профессиональный консультант по ИТ. Он консультирует средние и крупные предприятия по вопросам построения сетей Microsoft, Active Directory, Exchange Server и безопасности ИТ.

С помощью ISA 2006 вы можете опубликовать Web сервер двумя способами:

Публикация с использованием правил публикации сервера (Server publishing)
Публикация с использованием правил публикации Web-сервера (Web publishing)

В этой статье я расскажу о том, как настроить публикацию OWA Exchange 2007 с использованием ISA 2006 и Web publishing.

Имеются несколько вариантов перенаправления:

Есть ряд моментов, которые необходимо учитывать при получении, установке и настройке сертификатов:

От теории к практике.

Создание сертификата на публикуемом Web-сервере.

На Web сервере открываем оснастку IIS (я буду писать про IIS7, по IIS 6 уже много где написано и его настройка более привычна что ли).

В этом окне указываете Центр Сертификации и дружественное имя сертификата.

При нажатии кнопки Select выберите Центр Сертификации

Так выглядит итоговое окно. Нажимаем кнопку Finish и наш сертификат создается.

После того как сертификат создан, его необходимо экспортировать. Для этого на только что созданном сертификате нажимаем правой кнопкой мыши и выбираем пункт Export.

Указываем путь и имя файла для экспорта сертификата, указываем пароль для защиты сертификата. Пароль запоминаем, он будет необходим при импорте сертификата.

Настройка виртуального каталога OWA в IIS.

Далее переходим к настройке виртуального каталога OWA. Там же в консоли управления IIS открываем Default Web Site и переходим к низлежащему каталогу OWA. Выбираем настройки SSL (SSL Settings).

в настройках SSL выставляем следующие параметры

Настройка ISA сервера.

Прежде всего на ISA сервер необходимо импортировать сгенерированный ранее сертификат.

Для этого открываем оснастку mmc и дабавляем туда консоль управления сертификатами

указываем что хотим управлять сертификатами Компьютера

а именно локального компьютера (напоминаю, эту процедуру мы делаем на ISA сервере)

открываем указанную ветку, именно туда мы должны импортировать сертификат

запускаем мастер импорта сертификата

копируем файл с сертификатом на компьютер ISA сервера и указываем путь к нему в мастере импорта

вводим пароль, который использовали при экспорте

указываем в какое хранилище импортировать сертификат

вот что мы должны получить в итоге

После импорта сертификата переходим к созданию правила публикации. Открываем консоль ISA сервера.

На ISA сервер создаем новое правило публикации Web узла.

задаем имя правила публикации

указываем, что мы собираемся публиковать (в нашем случае сервис OWA Exchange 2007)

говорим, что будем использовать SSL

в следующем окне указываем имя сервера, который будем публиковать

задаем параметры внешнего имени публикуемого сервиса

далее система предлагает нам указать Web-listner, в нашем случае его надо сначала создать

переходим к мастеру создания Web-listner

указываем, требовать SSL для клиентов

выбираем интерфейс на котором будет работать Web-listner

переходим к выбору SSL сертификата

указываем импортированный ранее сертификат

указываем параметры проверки подлинности

и настройки параметров единого входа

на этом создание Web-listner закончено

заканчиваем настройки правила публикации

выбираем метод делегирования проверки подлинности

и указываем для кого данное правило будет работать

на этом создание Web-listner закончено

В итоге, после этих не сложных операций, у нас получается наиболее защищенный опубликованный OWA.

Для работы с веб-частями Outlook Web Access используемой учетной записи необходимо делегировать как минимум доступ с правами «Читатель» к открываемому содержимому. Если в приложение внедрена веб-часть Outlook Web Access, для которой требуется проверка подлинности, необходимо передать сведения для проверки подлинности с запросом веб-части. Один из возможных способов — настроить виртуальный каталог Outlook Web Access для использования встроенной проверки подлинности Windows. Встроенная проверка подлинности Windows позволяет пользователям, которые уже вошли в систему с учетной записью Active Directory, использовать Outlook Web Access без повторного ввода учетных данных.

Exchange 2007 Outlook Web Access имеет новый формат URL-адреса для запросов виртуального каталога /owa. Чтобы выполнить запрос, можно ввести URL-адрес напрямую в веб-обозревателе или внедрить его в веб-приложение, например на страницу Office SharePoint Server.

В зависимости от мер безопасности, используемых в сети, может потребоваться настройка кодировки для URL-адреса веб-частей. После настройки кодировки код, связанный с пользовательским интерфейсом, создает URL-адрес, используя параметры с URL-кодировкой. В параметрах с URL-кодировкой пробелы заменяются сочетанием %20, а разделители пути «/» — сочетанием %2f. Во всех примерах в данном разделе используются параметры с кодировкой.

Поддерживаемые веб-части Microsoft Exchange 2000 и Exchange 2003 автоматически преобразуются в веб-части Exchange 2007.

В таблице 1 приведены параметры веб-части и примеры их использования.

Таблица 1. Параметры веб-части и их использование

Имя сервера и каталог (обязательно)

URL-адрес виртуального каталога Outlook Web Access.

Можно использовать тот же URL-который, который используется для подключения к Outlook Web Access, например:

Идентификатор почтового ящика для явного входа в Exchange 2007 (необязательно)

Любой SMTP-адрес, сопоставленный с открываемым почтовым ящиком.

Если в этом разделе не указан URL-адрес, открывается почтовый ящик по умолчанию для пользователя, прошедшего проверку подлинности.

cmd (требуется при указании любых параметров, кроме идентификатора почтового ящик для явного входа)

При использовании параметра ?cmd=contents выводится веб-часть Outlook Web Access, заданная параметрами, а не весь пользовательский интерфейс Outlook Web Access.

Если почтовый ящик не задан, этот параметр указывается после каталога сервера:

Если почтовый ящик задан, параметр указывается после идентификатора почтового ящика для явного входа:

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

ИД папки — это свойство папки PR_ENTRY_ID в кодировке Base64:

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

При использовании URL-кодировки пробелы заменяются сочетанием %20, а разделители пути «/» — сочетанием %2f.

Иерархия папок должна начинаться с корня почтового ящика.

Путь к папке может указывать на обычную папку или папку поиска.

Этот параметр можно использовать для указания любой из четырех папок по умолчанию без ввода ее локализованного имени.

Значения параметра module вводятся без учета регистра:

Чтобы открыть календарь почтового ящика вне зависимости от его локализации, введите:

Этот параметр определяет представление папки.

Если этот параметр не указан, по умолчанию используются следующие представления:

Примечание.
Строки для преставлений по умолчанию автоматически получают URL-кодировку.

Сортировка по умолчанию для представления — это сортировка папки при ее открытии в клиенте Outlook Web Access.

В Exchange 2007 не поддерживаются следующие представления веб-частей Exchange 2003:

Строки, определяющие представления, не локализуются и не учитывают регистр.

Доступные представления зависят от типа папки.

Представления для календаря:

Представления для папки «Контакты»:

Представления для задач:

d, m, y (необязательно)

Определяют дату, для которой необходимо отобразить календарь. Эти параметры можно вводить в любом порядке вместе или по отдельности.

Если любой из этих параметров не указан, по умолчанию используется текущий день, месяц или год. Например, если текущий день — 3 мая 2007 г. и указано значение месяца «9» (сентябрь), будет использоваться дата 3 сентября 2007 г.

Допустимы следующие значения:

y=[четыре цифры года]

Указание на то, что необходимо открыть более мелкую веб-часть Outlook Web Access.

При использовании веб-частей для доступа к содержимому Outlook Web Access будет отображаться не весь пользовательский интерфейс Outlook Web Access. Параметр part еще более уменьшает выводимый пользовательский интерфейс. В этом примере показано отображение списка задач в формате самой маленькой веб-части:

На рис. 1 и 2 показан пользовательский интерфейс Outlook Web Access при применении параметра part=1 к веб-части «Задачи» и без его применения.

На рис. 1 показана веб-часть «Задачи» Outlook Web Access без параметра part=1.

На рис. 2 показана веб-часть «Задачи» Outlook Web Access с параметром part=1.

Примечание.
Если какая-либо возможность отключена с помощью сегментации, она не будет доступна в качестве веб-части. Например, если отключен календарь Outlook Web Access, нельзя получить доступ к календарям с помощью веб-частей Outlook Web Access.

Веб-части Outlook Web Access можно также вручную вводить в веб-обозревателе. Например, пользователь может использовать URL-адрес веб-части Outlook Web Access, чтобы открыть календарь другого пользователя.

Чтобы открыть отдельный календарь в представлении еженедельника, выполните указанные ниже действия.

Дополнительные сведения о веб-частях и планировании веб-страниц см. в следующих статьях:

Дополнительные сведения о проверке подлинности Outlook Web Access см. в следующих разделах:

Функции безопасности в Outlook Web Access (часть 1)

Введение

В этом цикле статей я хочу рассмотреть функции безопасности, доступные в Outlook Web Access (OWA) в Exchange 2007. В OWA 2007 было добавлено множество усовершенствований в области безопасности по сравнению с предыдущими версиями Exchange, поэтому данные моменты безопасности необходимо тщательно рассмотреть во время стадии создания вашей установки Exchange 2007. Давайте перейдем непосредственно к делу и посмотрим, что этот продукт может нам предложить.

Расположение сервера клиентского доступа (Client Access Server)

Давайте начнем статью с рассмотрения фундаментальной части безопасности Exchange 2007 OWA, а именно с безопасности сервера, отвечающего за предоставление OWA, с сервера Client Access Server. В Exchange 2000 и Exchange 2003 роль сервера переднего плана немного схожа с ролью сервера Client Access Server в Exchange 2007. Иногда организации устанавливали роль сервера переднего плана в демилитаризованной зоне на основе того, что данная конкретная роль подходила для этого местоположения в сети, после чего сервер переднего плана осуществлял соединение с внутренним почтовым сервером. Однако такая конфигурация оказалась противоречивой, поскольку были те, кто считал, что расположение внешнего сервера в демилитаризованной зоне требовало того, что нужно было открывать много дополнительных портов на брандмауэре, отделяя демилитаризованную зону от внутренней сети, в которой находился внутренний почтовый сервер. В Exchange 2007 следует отметить, что Microsoft не поддерживает расположение сервера Client Access Server в демилитаризованной зоне, поэтому при планировании следует учитывать этот факт расположения сервера Client Access Servers.

Учитывая все вышесказанное, давайте перейдем к другим ключевым областям безопасности OWA, начиная с шифрования Secure Sockets Layer (SSL) и сертификатов, используемых для этой цели.

Secure Sockets Layer

Одним из основных изменений в безопасности OWA в Exchange 2007 стал тот факт, что SSL шифрование включено по умолчанию, и для применения шифрования через SSL Exchange 2007 использует цифровые сертификаты. Можно просто связывать термин цифровые сертификаты с сторонними центрами сертификации, такими как Verisign, или с внутренним центром сертификации, который интегрирован в среду Active Directory. Хотя это правильно, стандартный SSL сертификат, который генерируется Exchange 2007 во время установки на, самом деле, является самоподписным сертификатом (self-signed certificate). Это означает, что в то время как сторонние центры сертификации будут подписывать издаваемые ими сертификаты, самоподписные сертификаты, выпускаемые Exchange 2007, как предполагает их название, подписываются самим Exchange 2007.

На рисунке 1 показан самоподписной сертификат, который был выпущен сервером Exchange 2007 с NetBIOS именем CCR-SRV1. На рисунке 2 показан тот же сертификат, но здесь особое внимание уделено полю Subject Alternative Name сертификата.

Рисунок 1: Закладка общих свойств самоподписного сертификата Exchange 2007

Рисунок 2: Поле Subject Alternative Name сертификата Self-Signed Exchange 2007

Из рисунка 2 видно, что поле сертификата Subject Alternative Name заполнено не только NetBIOS именем сервера, но и Fully Qualified Domain Name (FQDN). Также на рисунке 1 видно, что самоподписной сертификат не является доверенным по умолчанию так, это бывает с сертификатами сторонних производителей. Другими словами, вам нужно скопировать этот сертификат в Хранилище доверенных корневых сертификатов (Trusted Root Certificate Store) каждого компьютера, с которых вы собираетесь подключаться к серверу Client Access Server, например, при использовании Outlook Web Access через браузер на ПК. Если этого не сделать, вы получите уведомление о сертификате, как показано на рисунке 3.

Если вас не беспокоит появление вышеупомянутого предупреждения, можно использовать самоподписные сертификаты при использовании OWA для доступа к почтовым ящикам. Однако следует отметить, что другие методы клиентского доступа, такие как Outlook Anywhere, не работают с самоподписными сертификатами, поэтому, возможно, лучше будет установить сертификат из стороннего центра сертификации в самом начале, или из внутреннего центра сертификации. Более подобно опции центров сертификации мы рассмотрим в одной из следующих частей этого цикла. Еще одной из основных проблем с самоподписными сертификатами является тот факт, что ими в целом сложнее управлять. Например, самоподписные сертификаты действительны в течение всего одного года в Exchange 2007 Service Pack 1, после чего вам нужно обновлять сертификаты с помощью команды New-ExchangeCertificate. Администраторам бывает довольно проблематично запомнить, когда истекает срок действия этих сертификатов, хотя такие системы мониторинга как System Center Operations Manager (SCOM) могут помочь в решении этой проблемы. Сертификаты, предоставляемые сторонним центром сертификации или центром сертификации Active Directory, могут иметь более длительный срок действия, например, 3 года.

Рисунок 4: SSL требования для /owa Virtual Directory

Центры сертификации (Certificate Authorities)

Очевидно, приобретение сертификатов сторонних центров сертификации будет стоить определенных денег, в то время как сертификаты, выпущенные внутренним центром сертификации, абсолютно бесплатны, здесь расходы идут только на установку и настройку центра сертификации. К тому же, гораздо проще создать и назначить сертификаты из внутреннего центра сертификации, а затем переиздавать их в случае возникновения определенных проблем. К примеру, сертификат сервера Client Access Server требует множество дополнительных имен, перечисленных в поле Subject Alternate Name, и вполне вероятно, что вы могли забыть включить одно из этих имен в начальный запрос сертификата.

Существует множество организаций, особенно малых предприятий, которые не устанавливали внутренний центр сертификации Microsoft, интегрированный в среду Active Directory. В результате во время первой установки Exchange 2007 этим организациям необходимо решить, будут ли они продолжать использование самоподписных сертификатов Exchange 2007, или они будут получать свои цифровые сертификаты у сторонних поставщиков сертификатов. Еще одним вариантом может быть установка внутреннего центра сертификации, а самой очевидной опцией является установки центра сертификации, использующего службы Microsoft Certificate Services.

Установка Exchange 2007 инфраструктуры не является единственной причиной для того, чтобы обратить внимание на установку внутреннего центра сертификации на основе технологий Microsoft. Прочие продукты Microsoft, такие как Office Communications Server, System Center Operations Manager и System Center Configuration Manager также используют сертификаты. Поэтому, если у вас в настоящее время нет внутреннего центра сертификации, возможно, пришло время задуматься о преимуществах его установки и использования.

Заключение

На этом закончим первую часть цикла статей о безопасности OWA в Exchange 2007. Большую часть статьи мы посвятили рассмотрению SSL сертификатов, и это вполне оправдано, поскольку они жизненно необходимы для безопасности OWA 2007. В следующей части цикла мы рассмотрим способы аутентификации OWA, такие как проверка подлинности на основе форм, а также стандартные способы аутентификации, такие как интегрированная Windows аутентификация.

Автор: Нейл Хобсон (Neil Hobson)

Полезные ссылки

Этот пост October 30, 2009 at 5:44 pm опубликовал molse в категории Microsoft Exchange. Желающие могут оформить RSS подписку на комменты. Both comments and trackbacks are currently closed.

Читайте также: