В одной из прошлых статей была рассмотрена синхронизация пользователей AD с IVA MCU.

Задание на синхронизацию LDAP каталогов выполняется раз в сутки в 7:00 и производитель не предусмотрел никаких инструментов для корректировки расписания. Если в вашей компании довольно большое число пользователей и изменения в течение дня бывает довольно много, то ждать сутки синхронизации с IVA не совсем уместно, а выполнять синхронизацию руками не выбор системного администратора.

Если хорошо разобраться в вопросе, то настройки системных заданий можно найти в базе данных ivcs, в таблицах quartz.simprop_triggers и quartz.triggers.

quartz.simprop_triggers – хранит настройки периодичности запуска заданий

quartz.triggers – хранит данные о состоянии задании, а также время старта/остановки и следующего запуска.

Для просмотра текущих настроек задания по синхронизации LDAP каталога необходимо выполнить запросы к БД. Для этого воспользуемся консольным клиентом psql.

sudo -u postgres psql -d ivcs

После входа в консоль выполните запросы:

SELECT * FROM quartz.simprop_triggers WHERE trigger_name = ‘su.ivcs.videoconference.jobs.ldap.LdapUserCacheSynchronizationJob.JOB_ID’;

Это означает что задание будет выполнять 1 раз в день.

Как видно в свойствах задания str_prop_1 стоит значение DAY, а в свойстве int_prop_1 стоит 1.

SELECT * FROM quartz.triggers WHERE trigger_name = ‘su.ivcs.videoconference.jobs.ldap.LdapUserCacheSynchronizationJob.JOB_ID’;

Отсюда видно, что trigger_state находится в состоянии WAITING, т.е. задаине не выполняется. Ещё есть свойство start_time – это время запуска.  Интересны prev_fire_time и next_fire_time, что является временем прошлого запуска и временем следующего запуска.

Время в данный свойствах хранится в формате TIMESTAMP. TIMESTAMP — хранит сколько прошло секунд с 1970-01-01 00:00:00 по нулевому часовому поясу. Для проверки значений можете воспользоваться функцией powershell.

Если взять значение prev_fire_time 1710907200000, у меня это 20 марта 2024 г. 7:00:00, то от него будет проще рассчитать нужное расписание.

Делим 1710907200000 на 1000 и прибавляем необходимое количество секунд, далее умножаем опять на 1000. Проверяем, у меня получилось 1710921600000, это 20 марта 2024 г. 12:00:00.

Теперь выполняем изменения в базе данных. Я хочу, чтобы задание выполнялось раз в 30 минут.

UPDATE quartz.simprop_triggers SET str_prop_1 = ‘MINUTE’, int_prop_1 = ’30’ WHERE trigger_name = ‘su.ivcs.videoconference.jobs.ldap.LdapUserCacheSynchronizationJob.JOB_ID’;

Далее изменяю время запуска задания

UPDATE quartz.triggers SET next_fire_time = ‘1710921600000’ WHERE trigger_name = ‘su.ivcs.videoconference.jobs.ldap.LdapUserCacheSynchronizationJob.JOB_ID’;

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

Предоставляю пользователю доступ к IVA

Ожидаем время запуска задания.

LDAP синхронизация прошла успешно.

Пользователь синхронизировался

Спустя пол часа проверяем, что задание будет выполняться и дальше .

Успешно! Учтите, что всё настройки в базе данных вы выполняете на свой страх и риск. Никто не знает к каким последствиям могут привести внесения изменений в БД.

В прошлой статье была рассмотрена интеграция IVA MCU с AD, и чтобы пользователи не вводили пароли лишний раз настроем single sign-on.

Для настройки single sign-on в IVA MCU необходимо выполнить конфигурацию сервера и клиентов.

• Конфигурация серверов

Для настройки SSO потребуется дополнительная сервисная учётная запись в AD, создаём пользователя в AD.

iva-krb-srv

Теперь для этой учётной записи необходимо создать keytab файл и прописать SPN запись.

Выполняем команду:

ktpass /princ HTTP/iva.adminguru.local@ADMINGURU.LOCAL /mapuser ADMINGURU\iva-krb-srv /out C:\Temp\iva.keytab /mapOp set /crypto ALL /ptype KRB5_NT_PRINCIPAL /pass Password

Проверим что SPN запись присутствует:

setspn -L iva-krb-srv

Теперь открываем консоль администрирования, переходим в раздел «Домены», открываем текущий домен кнопкой «Дополнительно» и находим секцию настроек «Настройки Kerberos».

Необходимо включить данные настройки установив галку в пункте «Включено».

После этого я попробовал загрузить keytab через данную секцию настроек, и … ничего не произошло. Keytab файл не появился в системе.

Копируем файл на оба главных сервера. Подключаемся в консоль по ssh и открываем файл:

sudo vim /etc/nginx/ivcs/server.conf

Как видно из файла конфигурации keytab файл лежит по пути:

/etc/nginx/local.keytab

Поскольку данные настройки лежат в общей конфигурации, то есть вероятность, что при обновлении системы данный файл будет перезаписан. Значит нужно переместить наш keytab файл под именем local.keytab в эту папку.

Из директории куда был помещён файл iva.keytab выполним его перенос:

sudo mv iva.keytab /etc/nginx/local.keytab

Проверим keytab файл:

klist -K -e -k -t /etc/nginx/local.keytab

Следующим шагом необходимо сконфигурировать Kerberos:

sudo vim /etc/krb5.conf

В моём случае конфигурация выглядит так:

[libdefaults] kdc_timesync = 1
ccache_type = 4
forwardable = true
proxiable =true
fcc-mit-ticketflags = true
dns_lookup_realm = true
dns_lookup_kdc = true
ticket_lifetime = 24h
renew_lifetime 7d
rdns = false

[logging] default = FILE:/var/log/krb5libs.log
kdc = FILE:/var/log/krb5kdc.log
admin_server = FILE:/var/log/kadmind.log

[realms] ADMINGURU.LOCAL = {
kdc = adminguru.local
admin_server = adminguru.local
default_domain = ADMINGURU.LOCAL
}

[domain_realm]

.adminguru.local = ADMINGURU.LOCAL
adminguru.local = ADMINGURU.LOCAL

Перезагружаю оба сервера, на этом конфигурация серверов закончена.

• Конфигурация клиентов

Для корректной работы SSO в браузере Edge, необходимо:

1. Если вы используете прокси-сервер, то адрес доступа к IVA MCU необходимо добавить в исключения.

2. Для Edge необходимо настроить политики

AuthNegotiateDelegateAllowlist

AuthServerAllowlist

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

Создаю новую групповую политику

В групповой политике необходимо перейти
Computer Configuration/Policies/Administrative Templates/Microsoft Edge/HTTP authentication
и добавить адрес сервера iva.adminguru.local и включить
Configure list of allowed authentication servers
Specifies a list of servers that Microsoft Edge can delegate user credentials to

На клиенте проверяем, что настройки браузера обновились. В адресной строке браузере:

edge://policy

Проверяем вход в систему и входим без ввода логина и пароля через браузер.

На очереди Desktop клиент IVA Connect.

Для того, чтобы sso заработало в Dektop клиенте необходимо в настройках клиента

 %LocalAppData%\IVKS\IVA Connect\Settings.ini

сконфигурировать параметр

SsoAutoLogin=true

Тоже самое для клиента Linux(в моём случае Alt)

Устанавливаем пакет с клиентом

Аналогично конфигурируем настройки sso в файле настроек пользователя:

$HOME/.config/IVKS/ivaconnect/settings.ini

пареметр

SsoAutoLogin=true

После этого клиент пароль спрашивать не должен.

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

Host=iva.adminguru.local

Наш кластер готов, настала пора добавить в него пользователей. В данной статье рассмотрим интеграцию IVA MCU c Microsoft Active Directory.

Для доступа к каталогу необходимо создать сервисную учётную запись.

iva-ad-srv

Я буду организовывать доступ к IVA через группу доступа, поэтому создаю дополнительно группу доступа IVA Access типа Domain Local.

Открываем консоль администрирования, переходим в раздел LDAP, нажимаем кнопку «LDAP сервера» и создаём новый сервер кнопкой «Добавить LDAP сервер».

В моём случае настройки следующие

Фильтр поиска по группе AD (memberof:1.2.840.113556.1.4.1941:=CN=IVA Access,OU=Service,OU=Adminguru,DC=adminguru,DC=local), конструкция memberof:1.2.840.113556.1.4.1941:= позволяет считывать вложенные группы.

Протокол LDAPS также поддерживается для подключения к контроллеру домена.

Ещё раз настройки после создания

Во вновь созданном LDAP коннекторе перехожу на вкладку «Атрибуты пользователей», тут я делаю несколько изменений. Самое главное делаю аутентификацию по UPN, а не SamAccountname. В организации с несколькими лесами аутентификация по SamAccountname может привести к проблемам, когда SamAccountname совпадает у нескольких пользователей.

Выполняем синхронизацию LDAP каталога, как видно всё прошло успешно.

Добавляю пользователя в группу доступа, ещё раз выполняю синхронизацию LDAP каталога.

Новый пользователь домена добавлен в IVA MCU.

Стоит обратить внимание, что в IVA MCU атрибут mail является обязательным. Если у пользователя домена данный атрибут не заполнен, то при синхронизации LDAP каталога он добавлен не будет!

Перехожу на клиентский ПК, выполняю аутентификацию, пользователь домена успешно вошёл в IVA MCU.

При включении LDAP аутентификации IVA выключает возможность входа в систему для локальных пользователей, созданных в IVA MCU. Если вы планируете поддержку как доменных, так и локальных пользователей, то данную поддержку необходимо включить.

Переходим в раздел «Домены», нажимаем кнопку детально, находим раздел «Настройки LDAP» и включаем «Возможность аутентификации локальных пользователей».

Также интересно выглядит настройка «Синхронизация пользователя при аутентификации» которая по умолчанию не включена. Из настроек есть «Блокирующая синхронизация» и «Неблокирующая синхронизация».

Добавляю ещё одного пользователя домена в IVA MCU.

Вхожу под ним в IVA MCU и открываю его профиль.

У пользователя заполняю атрибут telephoneNumber в AD.

Делаю повторный вход в IVA, и в профиле пользователя сделанные изменения присутствуют.

В моих тестах разницы между этими двумя настройками я не увидел (версия IVA 19.4). В обоих случаях при входе пользователя в UVA MCU выполняется LDAP синхронизация. При блокировке пользователя в AD в обоих случаях войти в IVA не вышло, то же самое если удалить пользователя из группы доступа.

При смене пароля в AD, без выполнения синхронизации LDAP каталога, войти в IVA MCU под старым паролем получилось, а это значит, что IVA MCU хранит в своей БД хэши паролей пользователей!

Включение настройки «Синхронизация пользователя при аутентификации» выглядит весьма полезной, но стоит учитывать, что её включение приведёт к увеличению нагрузки на контроллеры домена.

По умолчанию синхронизация LDAP каталога в IVA MCU выполняется раз в сутки и настройка расписания не предусмотрена вендором.

В следующей статье рассмотрим организацию SSO входа пользователей.

Рассмотрим настройку кластера active – standby из двух головных серверов IVA MCU.

Поднимаем второй основной сервер IVA MCU аналогично первому.

Для кластера необходимо общее файловое хранилище

Согласно документации, поддерживаются следующие виды хранилищ:

• NAS. Файловое хранилище, доступное для Платформы IVA MCU в качестве сетевой

файловой системы с поддерживаемыми протоколами CIFS, NFS.

• SAN. Файловое хранилище на стороне Платформы IVA MCU, представленное

блочным устройством. Доступ к файловому хранилищу осуществляется по одному из

протоколов iSCSI, FCoE и т. д.

В случае отсутствия файлового хранилища необходимо использовать

локальное файловое хранилище на основе технологии DRBD. В своей лабе я настроил NFS шару на Linux c ip адресом 192.168.232.23.

После развёртывания у меня два независимых головных сервера со следующими настройками

1.

2.

Открываем терминал на всех серверах и открываем изменения конфигурации:

sudo iva-cli configurator unlock

Следующим шагом необходимо выполнить команду создания кластера на каждой ноде. Команда имеет множество параметров, поэтому обратимся к документации.

sudo iva-cli cluster configure \

—head-node-1-ip HEAD_NODE_1_IP \

—head-node-1-secondary-ip HEAD_NODE_1_SECONDARY_IP \

—head-node-2-ip HEAD_NODE_2_IP \

—head-node-2-secondary-ip HEAD_NODE_2_SECONDARY_IP \

—media-node-ip MEDIA_NODE_IP \

—database-ip DATABASE_IP \

—filestorage-ip FILESTORAGE_IP \

—public-ip PUBLIC_IP \

—filestorage-device FILESTORAGE_DEVICE \

—filestorage-domain FILESTORAGE_DOMAIN \

—filestorage-username FILESTORAGE_USERNAME \

—filestorage-password FILESTORAGE_PASSWORD \

—disable-local-media-service

где:

• HEAD_NODE_1_IP – IP-адрес первого сервера управления (обязательный

параметр)

• HEAD_NODE_1_SECONDARY_IP – второй IP-адрес первого сервера

управления (указывается в случае частичного или полного

резервирования сети)

• HEAD_NODE_2_IP – IP-адрес второго сервера управления (обязательный

параметр)

• HEAD_NODE_2_SECONDARY_IP – второй IP-адрес второго сервера

управления (указывается в случае частичного или полного

резервирования сети)

• MEDIA_NODE_IP – IP-адреса медиасерверов (опционально)

• DATABASE_IP – плавающий IP-адрес, по которому будет доступна текущая

база данных master (обязательный параметр)

• FILESTORAGE_IP – плавающий IP-адрес внутреннего файлового

хранилища (обязательный параметр)

• PUBLIC_IP – плавающий IP-адрес, по которому доступен web-интерфейс и

SIP- / H.323-сигнализация (обязательный параметр)

• FILESTORAGE_DEVICE – название блочного устройства, используемого в

качестве внешнего файлового хранилища, или URI сетевого файлового

хранилища (NAS) (обязательный параметр)

• FILESTORAGE_DOMAIN – доменное имя внешнего файлового хранилища

(обязательный параметр, не указывается в случае использования

технологии DBRD)

• FILESTORAGE_USERNAME – имя пользователя для авторизации в сетевом

файловом хранилище (указывается в случае, когда файловое хранилище

требует авторизацию)

• FILESTORAGE_PASSWORD – пароль пользователя для авторизации в сетевом

файловом хранилище (указывается в случае, когда файловое хранилище

требует авторизацию).

Команда iva-cli cluster configure является идемпотентной (может

выполняться много раз без последствий для сервера) и приводит кластер в указанное состояние.

Адреса сетевых файловых хранилищ указываются в следующем формате:

• при использовании NFS: <IP-адрес>:/path_to_share

• при использовании SMB: //<IP-адрес>/share_nameРазвёртывание кластера Active / Standby

При указании ключа —disable-local-media-service на всех серверах управления будут выключены медиасервисы.

В моём случае команда создания кластера выглядит так:

sudo iva-cli cluster configure \

 —head-node-1-ip 192.168.232.20 \

 —head-node-2-ip 192.168.232.21 \

 —database-ip 192.168.232.19 \

 —filestorage-ip 192.168.232.18 \

 —public-ip 192.168.232.22 \

 —filestorage-device 192.168.232.23:/opt/nfsshare

Поскольку добавление медиасерверов будет рассмотрено дальше, на данный момент ключ —disable-local-media-service не используется.

После того как процесс создания кластера завершиться необходимо выполнить сохранение конфигурации командой:

sudo iva-cli live save-changes

Если этого не сделать, то после перезагрузки все изменения будут потеряны.

После завершения настройки на серверах необходимо

выполнить команду:

sudo iva-cli configurator lock

Выполним проверку состояния кластера командой sudo crm_mon -1 –A

Настройка кластера завершена, необходимо выполнить изменения в DNS для работы сервиса через кластерный ip адрес.

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

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

После перезагрузки кластерные службы благополучно переехали на ноду с ip адресом 192.168.232.20.

В данной статье произведена установка кластера active – standby. В следующей статье будет разобран вынос медиа серверов на отдельные машины.