Устранение неполадок Web Application Proxy

В этой статье мы рассмотрим несколько советов, как устранить проблемы, которые могут возникнуть в средах, где были развёрнуты Web Application Proxy.

Сбор информации о среде окружения

Управление и устранение неполадок Web Application Proxy серверов требует хорошее знание Windows PowerShell и командлетов для Web Application Proxy.

При устранении неполадок Web Application Proxy, сначала необходимо принять к сведению любые сообщения об появляющихся в консоли ошибках. Если есть любые не очевидные ошибки, просмотрите журналы событий. Вы можете войти в каждый сервер и проверить журналы событий, но для упрощения процесса можете использовать Windows PowerShell.

Например, следующая команда Windows PowerShell будет собирать все события, созданные сервером Web Application Proxy в предыдущие 24 часа, наряду с их ID, уровнем и сообщениями:

$yesterday = (Get-Date) - (New-TimeSpan -Day 1) ; Get-WinEvent -FilterHashTable @{LogName='Microsoft-Windows-WebApplicationProxy/Admin'; StartTime=$yesterday} | group -Property ID,LevelDisplayName,Message -NoElement | sort Count, Name -Descending | ft – Name -HideTableHeaders}

Предположим, что вы неоднократно на этом конкретном сервере видите событие ID 12000. Однако, у вас есть целый ряд серверных Web Application Proxy, и вы хотите знать, испытывают ли они такую же ошибку. Чтобы собрать все события ID 12000, созданные в течение предыдущих 10 часов для набора Web Application Proxy серверов, выполните следующую команду:

Foreach ($Server in (gwpc).ConnectedServersName){Get-WinEvent -FilterHashTable @{LogName='Microsoft-Windows- WebApplicationProxy/Admin'; ID=12000; StartTime=(Get-Date) - (New-TimeSpan -hour 10)} -ComputerName $Server - ErrorAction SilentlyContinue | group MachineName -NoElement | ft Name -HideTableHeaders}

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

Для решения этой проблемы может быть очень полезной таблица кодов ошибок TechNet (http://technet.microsoft.com/en-us/library/dn770156.aspx). В таблице на сайте TechNet предлагается проверить подключение к AD FS для этого конкретного Web Application Proxy сервера. Чтобы сделать это, перейдите на https://<FQDN_of_AD_FS_Proxy>/FederationMetadata/2007-06/FederationMetadata.xml и убедитесь, что между сервером AD FS и Web Application Proxy сервера установлены права доверия. Если это не работает, запустите для устранения проблемы командлет Install-WebApplicationProxy.

Использование Microsoft Exchange Best Practices Analyzer

А также вы можете запустить на сервере Web Application Proxy - Exchange Best Practices Analyzer. Вы можете сделать это через графический интерфейс пользователя диспетчера сервера (Server Manager GUI). В панели слева выберите локальный сервер, а затем прокрутите вниз до анализатора соответствия рекомендациям (Best Practices Analyzer) в средней панели.

На правой стороне Server Manager GUI выберите пункт "Задачи" и "Start BPA Scan".

Вы можете запустить анализатор соответствия рекомендациям, используя следующий командлет Windows PowerShell:

Invoke-BpaModel Microsoft/Windows/RemoteAccessServer Get-BpaResult Microsoft/Windows/RemoteAccessServer

В этом случае результат связан с проблемами сертификата и появляется сообщение об ошибке: «Web Application Proxy не смог опубликовать приложение из-за проблем с сертификатами».

Событие, указанное на панели Best Practices Analyzer, содержит сведения, которые помогут вам решить проблему.

Таблица на TechNet предлагает следующее предложение для события 12021:

Убедитесь, что, настроенные для Web Application Proxy, отпечатки сертификата установлены на всех Web Application Proxy, с закрытым ключом в хранилище локального компьютера.

Вооружившись этой информацией, вы можете просмотреть сертификаты Web Application Proxy, чтобы убедиться, что у них правильные имена и даты истечения срока действия, а также то, что отпечаток совпадает с именем на сервере. Затем вы можете просмотреть сертификаты на сервере, убедиться, что они верны и переписать их, если они неверны.

Проблемы с сертификатами

Сертификаты играют важную роль в AD FS и Web Application Proxy. Получение надлежащих сертификатов - с правильными именами в сертификатах на соответствующих машинах - имеет решающее значение для корректной работы Web Application Proxy с AD FS.

Вы можете увидеть проблемы с сертификатами в сообщениях об ошибках, например:

Сертификат доверия («ADFS ProxyTrust - WAP01») недействителен.

Существует несколько возможных причин этой проблемы:

• Может произойти какое-то сетевое прерывание между Web Application Proxy и сервером AD FS.
• Возможно, сервер Web Application Proxy в течение длительного периода времени был не доступен.
• Может возникнуть проблема проверки сертификата из-за проблем в инфраструктуре CA.
• Проблемы синхронизации времени между Web Application Proxy и серверами AD FS могут привести к тому, что они будут не синхронизированы.

Чтобы устранить эти проблемы, проверьте настройки времени на серверах Web Application Proxy и серверах AD FS, а затем запустите командлеты Install-WebApplicationProxy.

Конфигурационные данные в AD FS непоследовательны или испорчены

Также вы можете столкнуться с ошибками, где данные конфигурации в AD FS не могут быть найдены, или непригодны для использования на сервере Web Application Proxy.

Это может привести к ошибкам, таким как:

Конфигурационные данные не были найдены в AD FS.

или:

Конфигурационные данные, хранящиеся в AD FS, повреждены или Web Application Proxy не смог их проанализировать.

или:

Web Application Proxy не смог получить список из AD FS -- Relying Parties.

Это может привести к некоторым ошибкам. Возможно, Web Application Proxy не был полностью установлен и настроен, или произошли изменения в базе данных AD FS, которые привели к повреждению. Также возможно, что из-за проблем с сетью, не может быть получен доступ к серверу AD FS, и поэтому база данных AD FS не читается.

Для таких типов ошибок существует несколько путей к решению:

• Чтобы устранить проблемы с настройкой, снова запустите командлет Install-WebApplicationProxy.
• Подтвердите с сервера Web Application Proxy подключение к сети AD FS.
• Убедитесь, что на сервере Web Application Proxy запущена служба WebApplicationProxy.

Поддержка не совместимых с SPI клиентов

Server Name Indication (SNI) — это функция Secure Sockets Layer (SSL) Transport Layer Security (TLS), используемая в Web Application Proxy и AD FS для снижения требований к сетевой инфраструктуре. Традиционно SSL-сертификат должен был быть привязан к комбинации IP адрес/порт. Это означает, если вы хотите привязать другой сертификат на тот же номер порта сервера, вам нужно иметь отдельный IP-адрес. Использование, вместо привязанного на имя хоста и порт сертификата, SNI, позволяет сохранить IP-адреса и уменьшить сложность.

Важно понимать, что SNI опирается на поддерживающего SNI запрашивающего клиента. Если SSL Client Hello не содержит заголовок SNI, http.sys не сможет определить, какой сертификат предложить клиенту и сбросит соединение.

Самые современные клиенты поддерживают SNI, но некоторые из них, имеют тенденцию вызывать проблемы. Как правило, старые браузеры, устаревшие операционные системы, аппаратные устройства для балансировки нагрузки, средства контроля жизнеспособности, более старые версии WebDAV, ActiveSync на Android и некоторые более старые устройства для конференц-связи VoIP могут не поддерживать SNI.

Если это необходимо, самым простым решением для поддержки не SNI клиентов, является создание привязки резервного сертификата в http.sys.

Резервный сертификат должен включать любые поддерживаемые полные доменные имена (FQDN), включая само полное доменное имя для службы AD FS (adfs.contoso.com), FQDN любого опубликованного через Web Application Proxy приложения (Mail.contoso.com) и, если вы используете соединение на рабочем месте, FQDN для поддержки регистрации предприятия (enterpriseregsitration.contoso.com).

Когда вы сгенерировали сертификат, используя следующий командлет Windows PowerShell, получите идентификатор GUID приложения и атрибут сертификата:

Get-WebApplicationProxyApplication | fl Name,ExternalURL,ExternalCertificateThumbprint

Теперь, когда у вас есть идентификатор GUID приложения и сертификат, вы можете привязать его к шаблону IP и порту 443, используя следующий синтаксис:

netsh http add sslcert ipport=0.0.0.0:443 certhash=certthumprint appid={applicationguid}

Обратите внимание, что вам нужно будет запускать это на каждом сервере в AD FS, а также на любом сервере Web Application Proxy.

Больше информации Вы можете найти техническую информацию о SNI как подразделе TLS Extensions RFC на https://tools.ietf.org/html/rfc3546#section-3.1.