Функции безопасности в Outlook Web Access. Часть 2

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

Аутентификация в OWA – аутентификация на основании форм

В Exchange 2007 вы можете выбирать между аутентификацией на основании форм и группой аутентификационных методов, идущих под общим названием стандартных аутентификационных методов. Другим видимым изменением, касающимся безопасности, в Exchange 2007 стал тот факт, что метод аутентификации на основании форм используется по умолчанию в OWA, поэтому мы начнем с него, а стандартными методами займемся позже. Чтобы увидеть методы аутентификации, вызовите свойства виртуального каталога /owa в Exchange Management Console, а затем щелкните на вкладку Authentication. Вы увидите экран, аналогичный показанному на Рисунке 5.

Аутентификация на основании форм была представлена еще в Exchange 2003; она позволяет отображать целую страницу входа вместо обычных строк для ввода имени пользователя и пароля. Страница входа увеличивает надежность, так как имя пользователя и пароль сохраняются в cookies, а не в самом браузере. У такого подхода два основных преимущества. Во-первых, cookie очищается при завершении сессии OWA, а во-вторых, cookie очищается через некоторый предопределенный промежуток времени неактивности, например, когда пользователь отходит от компьютера, не завершив сессию браузера. Более того, время неактивности можно настроить как для публичных, так и для личных компьютеров. То есть можно применять различные значения времени неактивности для клиентских компьютеров, принадлежащих организации, и для иных компьютеров. Большинство организаций, скорее всего, предпочтут, чтобы время неактивности для компьютеров вне надежной для них зоны имели значительно меньшее время неактивности. Такой подход обычно увеличивает надежность, так как при этом нельзя вернуть сессию OWA после того, как cookie будет очищен. На Рисунке 6 показаны две опции, предлагаемые пользователю на экране аутентификации на основании форм: используется ли компьютер пользователя как публичный компьютер или как личный.

По умолчанию при выборе опции публичного компьютера выделяются 15 минут на неактивность до завершения сессии, хотя это значение можно и поменять. Для изменения этого значения, добавьте или измените следующий ключ реестра на сервере Client Access Server, на котором была включена аутентификации на основании форм:

Ключ: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeOWA

Имя: PublicTimeout

Тип: DWORD

Значение: {число в минутах}

Этот ключ реестра показан на Рисунке 7. Обратите внимание на то, что при этом требуется перезапуск служб Internet Information Services (IIS) на сервере Client Access Server. Чтобы проделать это быстро, запустите командную строку, затем запустите команду iisreset /noforce.

Выбор личного компьютера означает, что по умолчанию допускается период неактивности в 8 часов перед завершением сессии – очевидно, намного больший период, чем для публичного компьютера. Для личных компьютеров тоже есть ключ реестра для изменения значения времени неактивности:

Ключ: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeOWA

Имя: PrivateTimeout

Тип: DWORD

Значение: {число в минутах}

Необходимо помнить об одной важной вещи: эти значения не абсолютно точны, они представляют собой некоторое приближение. Официально Microsoft утверждает, что реальное время неактивности может оказаться в 1 – 1.5 раза больше числа, указанного в настройках, так как сервер Client Access Server циклически обходит ключи шифрования. Согласно моему опыту отключение происходит через промежуток времени, близкий к указанному значению, однако, как я уже говорил, это не точное значение, так что не забывайте об этом, когда будете тестировать OWA самостоятельно. Также если вы используете сервер ISA в качестве внешней связи для OWA, вы можете использовать аналогичные значения в ISA, чтобы для пользователей все было последовательно.

Возвращаясь к Рисунку 6: вы видели экран аутентификации на основании форм для OWA. Вы могли заметить, что аутентификационные данные по умолчанию предлагается вводить в формате домен\имя пользователя. Можно изменить эту строку, чтобы она требовала только имени пользователя или User Principal Name (UPN). Но, хотя и есть соблазн упростить пользователям жизнь, оставив только имя пользователя, прежде, чем сделать так, подумайте о влиянии на надежность организации такого действия. Например, подумайте о том, что требование по умолчанию вводить и домен, и имя пользователя означает необходимость вводить два типа данных для входа, а не один, как в случае с указанием только имени пользователя.

Если же вы все-таки решите оставить только имя пользователя, изменения можно произвести через Exchange Management Console или Exchange Management Shell. В Exchange Management Console вызовите свойства виртуального каталога /owa и перейдите на вкладку Authentication (Рисунок 5). Как видите, вы можете менять формат входа для аутентификации на основании форм, как вам нравится. В Exchange Management Shell вы можете воспользоваться командой Set-OwaVirtualDirectory с параметром LogonFormat. Варианты использоваться этой команды такие:

• FullName: Это соответствует варианту домен\имя пользователя (Рисунок 5), при этом от пользователя требуется вводить и доменное имя, и имя пользователя для аутентификации в OWA.
• PrincipalName: Этот параметр очевидно соответствует варианту с UPN на Рисунке 5, от пользователя при этом требуется вводить UPN для аутентификации.
• UserName: Это соответствует варианту «только имя пользователя» на Рисунке 5. Обратите внимание: если вы используете Exchange Management Shell для установки этого варианта, не забудьте указать домен по умолчанию с помощью параметра DefaultDomain команды Set-OwaVirtualDirectory.

Как и в случае с ключами реестра для публичных и личных компьютеров, чтобы внесенные изменения вступили в силу, требуется перезапуск служб IIS. Опять же, для этого можно применить команду iisreset /noforce.

Аутентификация в OWA – Стандартная аутентификация

Если вы работали или сейчас работаете со средой Exchange 2000 или Exchange 2003, вы наверняка знакомы со стандартными моделями базовой аутентификации, digest-аутентификации и аутентификации, встроенной в Windows.

Когда для виртуального каталога /owa на сервере Client Access Server настроена базовая аутентификация, пользователи увидят знакомое им всплывающее окошко, которое показано на Рисунке 8. По умолчанию базовая аутентификация не надежна, пока не добавляется SSL.

Аутентификация, встроенная в Windows, может быть очень полезна том, что пользовательские данные используются сервером для аутентификации пользователей. При таком подходе пользователям не нужно снова и снова вводить логин и пароль. Например, представим, что пользователь залогинился на своем рабочем компьютере с помощью информации об аккаунте из Active Directory, а затем загрузил Internet Explorer. Затем этот пользователь может решить получить доступ к серверу Client Access Server, на котором настроена аутентификация, встроенная в Windows. В этом случае пользователь получит доступ к OWA немедленно, без необходимости вводить какие-либо данные. Однако если сервер ISA используется для внешнего доступа к OWA, и на нем настроена аутентификация на основании форм, различия в процедурах аутентификации в зависимости от того, используется ли внешнее или внутреннее подключение, могут вызвать замешательство у пользователей. Поэтому некоторые организации применяют аутентификацию, основанную на формах, на отдельных серверах Client Access Server, которые устанавливаются специально для обслуживания только внутренних сессий.

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

Заключение

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