Балансировка нагрузки веб-приложений с IIS-аутентификацией NTLM и олицетворением ASP.NET

Просмотр категорий

Балансировка нагрузки веб-приложений с IIS-аутентификацией NTLM и олицетворением ASP.NET

Обзор #

Веб-сервер Microsoft, Internet Information Services (IIS), объединяет несколько механизмов аутентификации для проверки подлинности пользователей в системах Active Directory или автономных системах (аутентификация на основе LDAP). NTLM — это протокол аутентификации Windows «запрос-ответ», который может использоваться в сетях и приложениях, работающих в обеих средах.

Можно рассмотреть два разных сценария: интерактивная аутентификация NTLM включает в себя две системы — клиент и контроллер домена, который используется для хранения данных пользователей, необходимых для аутентификации, и неинтерактивная аутентификация NTLM включает в себя три различные системы — клиент, сервер приложений и домен — для предоставления пользователю доступа к определенному ресурсу в приложении.

Функция имитации пользователя в ASP.NET позволяет веб-приложениям аутентифицировать и авторизовывать пользователей, использующих Microsoft IIS.

В этой статье мы собираемся объяснить, как загружать приложения балансировки нагрузки, которые интегрируют протокол NTLM для неинтерактивных сценариев аутентификации пользователей.

Как работает NTLM? #

Протокол NTLM основан на протоколе HTTP / S, где данный клиент запускает квитирование всего шагов 6 для установления аутентифицированного сеанса.

Аутентифицированное рукопожатие сеанса требует следующих шагов:

1. Клиент инициирует анонимный запрос к определенному ресурсу на веб-сервере.

ПОЛУЧИТЬ / HTTP

2. Сервер отвечает сообщением о неавторизации и указывает метод аутентификации, который должен использовать клиент.

401 Несанкционированная WWW-аутентификация: NTLM

3. Клиент повторно отправляет запрос, включая запрос на аутентификацию в формате NTLM.

GET/HTTP-авторизация: NTLM

4. Сервер отвечает сообщением о несанкционированном доступе и запрашивает у клиента дополнительную информацию.

401 Несанкционированная WWW-аутентификация: NTLM

5. Клиент повторно отправляет запрос, включая оставшуюся информацию о сессии.

GET/HTTP-авторизация: NTLM

6. Сервер устанавливает соединение с контроллером домена для завершения запроса на аутентификацию, а затем подтверждает клиенту факт аутентификации.

HTTP 200 ОК

Обратите внимание, что это рукопожатие требуется в каждом новом соединении, а не в HTTP-запросах, и во время шагов с 3 по 6 соединение необходимо поддерживать. Если соединение закрыто, эту часть рукопожатия следует повторить, и просто повторение с шага 5 недопустимо. С другой стороны, после аутентификации соединения заголовок авторизации не нужно отправлять снова, пока соединение не закрывается независимо от ресурса, к которому осуществляется доступ.

Как загрузить балансировку веб-приложений с использованием NTLM-аутентификации? #

С RELIANOIDСуществует два основных способа балансировки нагрузки и создания веб-приложения на базе NTLM с высокой доступностью: с помощью простого балансировщика нагрузки TCP уровня 2 или прокси-сервера уровня 4 для расширенных функций.

Простое распределение нагрузки NTLM на уровне 4 #

Чтобы сбалансировать нагрузку веб-приложений с поддержкой аутентификации NTLM с простой конфигурацией, мы можем создать фермы на основе LSLB с профилем L4xNAT. Мы можем использовать протоколы HTTP или HTTPS.

Затем в глобальных настройках убедитесь, что используется протокол TCP , но в зависимости от требуемой топологии можно выбрать NAT или DNAT .

В разделе «Сервисы» необходимо настроить параметр «Постоянство», чтобы гарантировать, что аутентификация для определенного клиента всегда будет осуществляться на одном и том же бэкэнде, иначе аутентификация соединения не может быть выполнена.

Наконец, добавьте свой список бэкэндов и настройте проверку работоспособности, как указано в разделах ниже.

Балансировка нагрузки NTLM на уровне 7 #

Эта опция позволяет обрабатывать данные HTTP/S с поддержкой NTLM с помощью прокси-сервера уровня 7, настроенного через модуль LSLB и HTTP-ферму. Для этого необходимо создать ферму для HTTP или HTTPS в соответствии с требованиями SSL для виртуального сервиса. Единственное различие будет заключаться в прослушивателе, настроенном в глобальных настройках создаваемой фермы.

На этом уровне, поскольку приложение пока не может создавать сессионные cookie для обеспечения постоянного соединения или его фиксации, мы можем использовать опцию «Вставка cookie» , которая позволяет балансировщику нагрузки создавать новый cookie во время первоначального установления соединения в процессе аутентификации NTLM.

Наконец, добавьте свой список бэкэндов и настройте проверку работоспособности, как указано в разделах ниже. Вы можете настроить дополнительные параметры приложения на уровне прокси-сервера, включенного в ферму такого типа, и поддержка NTLM не будет затронута.

Расширенные проверки работоспособности сайтов проверки подлинности NTLM #

Для создания собственной расширенной проверки работоспособности приложений, аутентифицированных по протоколу NTLM, нам необходимо создать в каталоге /usr/local/relianoid/app/libexec скрипт для проверки бэкэнда, как показано ниже. Например, check_ntlm.sh с соответствующими правами доступа.

#!/bin/bash # получить входные параметры BACKEND=$1 PORT=$2 USER=$3 PASS=$4 URI=$5 STRING=$6 /usr/bin/curl http://${BACKEND}:${PORT}${URI } --ntlm -negotiate -u ${USER}:${PASS} 2>/dev/null | grep "${STRING}" &>/dev/null if [ $? == 0 ] then # если команда Curl не завершается сбоем, то уведомляете, что серверная часть работает echo "Server ${BACKEND}:${PORT} OK" exit 0 fi # если команда Curl завершается неудачей, то уведомляете, что серверная часть не работает echo "Сервер ${BACKEND}:${PORT} не в порядке" выход 1

В разделе «Мониторинг» >> «Farmguardian» , если применимо, или добавьте это в команду для проверки работы службы фермы.

Мы можем проверить скрипт проверки работоспособности, выполнив:

/usr/local/relianoid/app/libexec/check_ntlm.sh 192.168.0.99 80 johndoe johnsecret "/my/uri" "DOCTYPE html"

Зная, что IP-адрес бэкэнда — 192.168.0.99, порт — 80 HTTP, johndoe — фиктивный пользователь в нашем домене, johnsecret — фиктивный пароль, «/my/uri» — URI для проверки, а «DOCTYPE html» — строка, которую нужно найти в данных ответа, если запрос был успешным.

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

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

Наслаждайтесь сбалансированными по нагрузке веб-приложениями NTLM!

📄 Загрузите этот документ в формате PDF #

    EMAIL: *

    Разработано компанией BetterDocs