Различия

Показаны различия между двумя версиями страницы.

--- russianway:jms_jas:jms_cluster_connection [2022/09/17 10:49] – создано root
+++ russianway:jms_jas:jms_cluster_connection [2024/12/21 19:00] (текущий) – внешнее изменение 127.0.0.1
@@ Строка 1: / Строка 1: @@
-====== Настройка подключения JAS и JWM к кластеру JMS ======
+====== Настройка аутентификации Administration API JMS в кластерной конфигурации ======
+Имеем кластер JMS в режиме балансировки нагрузки из двух нод, на каждой из которых установлены компоненты: JMS, JAS, JWM (Data Service+Admin Portal). \\
+Службы JMS стартуют из под выделенной учетной записи, например corp\jms-service. \\
+При попытке сконфигурировать компоненты JAS  и JWM на подключение к кластеру JMS при попадании запроса на "свою" же ноду сталкиваемся с ошибкой аутентификации:
+{{ :russianway:jms_jas:pasted:20220917-105530.png }}
+В логе Wireshark также видно, что получаем отлуп по Kerberos аутентификации.
+{{ :russianway:jms_jas:pasted:20220917-105859.png }}
+Для исправления подобной ошибки достаточно прописать дополнительный SPN "**HTTP/**" в служебную учетную запись:
+<code bash>setspn -A HTTP/fqdn.jms.loadbalancer corp\jms-service</code>, где fqdn.jms.loadbalancer - FQDN кластера, corp\jms-service - имя служебной УЗ.
+====== Тюнинг аутентификации JWM (Auth и Data Service) при работе в режиме балансировки. ======
+Аналогично, условием успеха является наличие у служебной записи SPN с префиксом **HTTP/**. \\
+Дополнительно необходимо настроить аутентификацию в IIS, т.к. не получится выполнить аутентификацию по кластерному имени. \\
+Открываем IIS Manager и для виртуальных папок Auth и Api заходим в раздел Configuration Editor. \\
+{{ :russianway:jms_jas:pasted:20220917-182456.png }}
+Далее в параметре **useAppPoolCredentials** по пути //system.webServer/security/authentication/windowsAuthentication// выставляем значение **true**.
+{{ :russianway:jms_jas:pasted:20220917-182741.png }}
+Перезагружаем сервер.