Предварительная подготовка

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

Дополнительные сведения о разрешениях, делегировании ролей и правах, необходимых для администрирования Exchange 2007, см. в разделе Вопросы, связанные с разрешениями.

Конкретные действия, производимые при выполнении этой процедуры с использованием консоли управления Exchange, зависят от следующих факторов:

от используемой версии сервера Exchange 2007: окончательная первоначальная (RTM) версия Exchange 2007 или Exchange 2007 с пакетом обновления 1 (SP1);

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

Процедура

Exchange Server 2007 с пакетом обновления 1 (SP1)

Чтобы настроить встроенную проверку подлинности Windows для веб-клиента Outlook с помощью консоли управления Exchange

В консоли управления Exchange перейдите к виртуальному каталогу, который необходимо настроить на использование встроенной проверки подлинности Windows с использованием сведений, приведенных в действии 2 или в действии 3.

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

Чтобы изменить виртуальный каталог Exchange 2007 выберите пункты Настройка серверов и Клиентский доступ, а затем откройте вкладку Outlook Web Access. Виртуальный каталог Exchange 2007 по умолчанию — /owa.

Чтобы изменить виртуальный каталог предыдущей версии, выберите пункты Настройка серверов, Сервер почтовых ящиков и откройте вкладку WebDAV. По умолчанию имеются следующие виртуальные каталоги предыдущих версий: /Public, /Exchweb, /Exchange и /Exadmin.

Если на компьютере с установленной ролью сервера клиентского доступа не установлена роль сервера почтовых ящиков, выберите пункты Настройка серверов, Клиентский доступ и откройте вкладку Outlook Web Access.

В рабочей области выберите виртуальный каталог, который необходимо настроить на использование встроенной проверки подлинности Windows, и выберите пункт Свойства.

Откройте вкладку Проверка подлинности.

Выберите вариант Использовать один или несколько стандартных способов проверки подлинности.

Выберите Встроенная проверка подлинности Windows.

Нажмите кнопку ОК.

Чтобы настроить встроенную проверку подлинности Windows для веб-клиента Outlook с помощью среды управления Exchange

Чтобы настроить встроенную проверку подлинности Windows для виртуального каталога Outlook Web Access по умолчанию на веб-узле служб IIS локального сервера Exchange, откройте среду управления Exchange и выполните следующую команду:

Копировать код

Дополнительные сведения о синтаксисе и параметрах см. в разделе Set-OwaVirtualDirectory.

Окончательная первоначальная (RTM) версия сервера Exchange Server 2007

Чтобы настроить встроенную проверку подлинности Windows для веб-клиента Outlook с помощью консоли управления Exchange

Откройте консоль управления Exchange.

Откройте раздел Конфигурация сервера\Клиентский доступ.

На вкладке Outlook Web Access откройте свойства виртуального каталога, который необходимо настроить на использование встроенной проверки подлинности Windows.

Откройте вкладку Проверка подлинности.

Выберите вариант Использовать один или несколько стандартных способов проверки подлинности.

Выберите Встроенная проверка подлинности Windows.

Нажмите кнопку ОК.

Чтобы настроить встроенную проверку подлинности Windows для веб-клиента Outlook с помощью среды управления Exchange

Чтобы настроить встроенную проверку подлинности Windows для виртуального каталога Outlook Web Access по умолчанию на веб-узле служб IIS локального сервера Exchange, откройте командную консоль Exchange и выполните следующую команду:

Копировать код

Для получения дополнительных сведений о синтаксисе и параметрах см. раздел Командлет Set-OwaVirtualDirectory (окончательная первоначальная версия).

Дополнительные сведения

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

Дополнительные сведения о повышении безопасности связи между клиентскими компьютерами и сервером клиентского доступа см. в разделе Управление безопасностью клиентского доступа.

Устранение неполадок AD FS — встроенная проверка подлинности Windows AD FS Troubleshooting — Integrated Windows Authentication

Встроенная проверка подлинности Windows позволяет пользователям входить в систему с учетными данными Windows и работать с единым входом (SSO), используя Kerberos или NTLM. Integrated Windows authentication enables users to log in with their Windows credentials and experience single-sign on (SSO), using Kerberos or NTLM.

Причина сбоя встроенной проверки подлинности Windows Reason integrated windows authentication fails

Существует три основные причины, по которым встроенная проверка подлинности Windows завершится ошибкой. There are three main reason why integrated windows authentication will fail. К ним относятся: They are: — Неправильное Настройка имени субъекта-службы (SPN) Service Principal Name(SPN) misconfiguration — Токен привязки канала Channel Binding Token — Настройка Internet Explorer Internet Explorer configuration

Неправильное Настройка имени участника-службы SPN misconfiguration

Имя участника-службы (SPN) — это уникальный идентификатор экземпляра службы. A service principal name (SPN) is a unique identifier of a service instance. Имена участников-служб используются при проверке подлинности Kerberos для связывания экземпляра службы с учетной записью входа службы. SPNs are used by Kerberos authentication to associate a service instance with a service logon account. Это позволяет клиентскому приложению запросить проверку подлинности учетной записи службы, даже если у клиента нет имени учетной записи. This allows a client application to request that the service authenticate an account even if the client does not have the account name.

Ниже приведен пример использования имени субъекта-службы с AD FS. An example of an how an SPN is used with AD FS is as follows:

1. Веб-браузер запрашивает Active Directory, чтобы определить, какая учетная запись службы работает под sts.contoso.com A web browser queries Active Directory to determine which service account is running sts.contoso.com
2. Active Directory сообщает браузеру, что это AD FS учетной записи службы. Active Directory tells the browser that it’s the AD FS service account.
3. Браузер получит билет Kerberos для учетной записи службы AD FS. The browser will get a Kerberos ticket for the AD FS service account.

Если учетная запись службы AD FS имеет неправильно настроенное или неправильное SPN, это может вызвать проблемы. If the AD FS service account has a misconfigured or the wrong SPN then this can cause issues. Просмотр трассировок сети может привести к ошибкам, например КРБ Error: KRB5KDC_ERR_S_PRINCIPAL_UNKNOWN. Looking at network traces, you may see errors such as KRB Error: KRB5KDC_ERR_S_PRINCIPAL_UNKNOWN.

С помощью трассировки сети (например, Wireshark) можно определить, какое имя субъекта-службы пытается разрешить браузер, а затем использовать средство командной строки SetSPN – Q . Using network traces (such as Wireshark) you can determine what SPN the browser is trying to resolve and then using the command line tool, setspn — Q , you can do a lookup on that SPN. Возможно, он не найден или назначен другой учетной записи, отличной от учетной записи службы AD FS. It may not be found or it may be assigned to another account other than the AD FS service account.

Имя субъекта-службы можно проверить, просмотрев свойства учетной записи службы AD FS. You can verify the SPN by looking at the properties of the AD FS service account.

Токен привязки канала Channel Binding Token

В текущей версии, если клиентское приложение проходит проверку подлинности на сервере с использованием протокола Kerberos, дайджест-проверку подлинности или проверку NTLM с использованием HTTPS, то сначала устанавливается канал безопасности транспортного уровня (TLS), а проверка подлинности выполняется по этому каналу. Currently, when a client application authenticates itself to the server using Kerberos, Digest, or NTLM using HTTPS, a Transport Level Security (TLS) channel is first established and authentication takes place using this channel.

Токен привязки канала является свойством внешнего канала, защищенного TLS, и используется для привязки внешнего канала к диалогу по внутреннему каналу, прошедшему проверку подлинности клиента. The Channel Binding Token is a property of the TLS-secured outer channel, and is used to bind the outer channel to a conversation over the client-authenticated inner channel.

При возникновении атаки «злоумышленник в середине» и расшифровке и повторном шифровании SSL-трафика ключ не будет совпадать. If there is a «man-in-the-middle» attack occurring and they are decrypting and re-encrypting the SSL traffic, then the key will not match. AD FS определит, что в центре веб-обзора r и самого себя есть что-то другое. AD FS will determine that there is something sitting in the middle between the web browse r and itself. Это приведет к сбою проверки подлинности Kerberos, и пользователю будет предложено диалоговое окно 401 вместо единого входа. This will cause the Kerberos authentication to fail and the user will be prompted with a 401 dialog instead of an SSO experience.

Это может быть вызвано следующим: This can be cause by:

• любые элементы, находясь между браузером и AD FS anything sitting in between the browser and AD FS
• Fiddler Fiddler
• Обратные прокси-серверы, выполняющие мост SSL Reverse proxies performing SSL bridging

По умолчанию AD FS имеет значение Allow. By default, AD FS has this set to «allow». Этот параметр можно изменить с помощью командлета PowerShell. Set-ADFSProperties -ExtendProtectionTokenCheck You can change this setting using the PowerShell cmdlet Set-ADFSProperties -ExtendProtectionTokenCheck

Настройка Internet Explorer Internet Explorer configuration

По умолчанию Internet Explorer будет иметь следующий порядок: By default, Internet explorer will be have the following way:

1. Internet Explorer получит ответ 401 от AD FS с словом NEGOTIATE в заголовке. Internet explorer will receive a 401 response from AD FS with the word NEGOTIATE in the header.
2. Это указывает веб-браузеру на необходимость получения билета Kerberos или NTLM для отправки обратно в AD FS. This tells the web browser to get a Kerberos or NTLM ticket to send back to AD FS.
3. По умолчанию IE пытается сделать это (SPNEGO) без вмешательства пользователя, если слово NEGOTIATE находится в заголовке. By default IE will try to do this (SPNEGO) without user interaction if the word NEGOTIATE is in the header. Он будет работать только для сайтов интрасети. It will only work for intranet sites.

Существует два основных момента, которые могут помешать этому. There are 2 main things that can prevent this from happening.

Включить встроенную проверку подлинности Windows не проверяется в свойствах IE. Enable Integrated Windows Authentication is not checked in the properties of IE. Он находится в разделе «Свойства обозревателя» — > «> безопасность». This located under Internet Options -> Advanced -> Security.

Зоны безопасности настроены неправильно Security zones are not configured properly

FQDN не входит в зону интрасети FQDNs are not in the intranet zone

URL-адрес AD FS не входит в зону интрасети. AD FS URL is not in the intranet zone.

Настройка Kerberos аутентификации в различных браузерах

В этой статья, мы рассмотрим, как настроить Kerberos аутентификацию для различных браузеров в домене Windows для прозрачной и безопасной аутентификации на веб-серверах без необходимости повторного ввода пароля в корпоративной сети. В большинстве современных браузерах (IE, Chrome, Firefox) имеется поддержка Kerberos, однако, чтобы она работала, нужно выполнить несколько дополнительных действий.

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

• Поддержка Kerberos должны быть включена на стороне веб-сервера (пример настройки Kerberos авторизации на сайте IIS)
• Наличие у пользователя прав доступа к серверу
• Пользователь должен быть аутентифицирован на своем компьютере в Active Directory с помощью Kerberos (должен иметь TGT — Kerberos Ticket Granting Ticket).

К примеру, мы хотим разрешить клиентам Kerberos авторизацию через браузер на всех веб серверах домена winitpro.ru (нужно использовать именно DNS или FQDN, а не IP адрес веб сервера)

Настройка Kerberos аутентификации в Internet Explorer

Рассмотрим, как включить Kerberos аутентификацию в Internet Explorer 11.

Откройте Свойства браузера -> Безопасность -> Местная интрасеть (Local intranet), нажмите на кнопку Сайты -> Дополнительно. Добавьте в зону следующие записи:

Далее перейдите на вкладку Дополнительно (Advanced) и в разделе Безопасность (Security) убедитесь, что включена опция Разрешить встроенную проверку подлинности Windows (Enable Integrated Windows Authentication).

Включаем Kerberos аутентификацию в Google Chrome

Чтобы SSO работала в Google Chrome, нужно настроить Internet Explorer вышеописанным способом (Chrome использует данные настройки IE). Кроме того, нужно отметить, что все новые версии Chrome автоматически определяют наличие поддержки Kerberos. В том случае, если используется одна из старых версий Chrome (Chromium), для корректной авторизации на веб-серверах с помощью Kerberos, его нужно запустить с параметрами:

«C:\Program Files (x86)\Google\Chrome\Application\chrome.exe” —auth-server-whitelist=»*.winitpro.ru» —auth-negotiate-delegate-whitelist=»*.winitpro.ru»

Либо эти параметры могут быть распространены через групповые политики для Chrome (политика AuthServerWhitelist) или строковый параметр реестра AuthNegotiateDelegateWhitelist (находится в ветке HKLM\SOFTWARE\Policies\Google\Chrome).

Для вступления изменений в силу нужно перезагрузить браузер и сбросить тикеты Kerberos командой klist purge (см. статью).

Настройка Kerberos аутентификации в Mozilla Firefox

По умолчанию поддержка Kerberos в Firefox отключена, чтобы включить ее, откройте окно конфигурации браузера (в адресной строке перейдите на адрес about:config). Затем в следующих параметрах укажите адреса веб-серверов, для которых должна использоваться Kerberos аутентификация.

Проверить, что ваш браузер работает через аутентифицировался на сервере с помощью Kerberos можно с помощью Fiddler или команды klist tickets.