Задание на синхронизацию 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’;

Время в данный свойствах хранится в формате 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 синхронизация прошла успешно.

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

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

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

Сообщение Изменение расписания синхронизации LDAP каталогов в IVA MCU появились сначала на Админгуру.

Для настройки 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

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

.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

Сообщение Настройка SSO в IVA MCU появились сначала на Админгуру.

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

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 входа пользователей.

Сообщение Интеграция IVA MCU с Active Directory появились сначала на Админгуру.

В данной статье рассмотрим установку сертификата для платформы IVA MCU.

Сам процесс выпуска сертификата оставим за рамкой данной статьи, скажу что сертификат я выпускал на центре сертификации под управлением Windows. Поэтому мой сертификат в формате .pfx, и его необходимо преобразовать в формат .pem и вытащить закрытый ключ .key.

Для преобразования сертификата воспользуемся утилитой openssl.

Openssl pkcs12 –in iva.pfx –out iva_nokey.pem –nokeys

Openssl pkcs12 –in iva.pfx –out iva_withkey.pem Openssl rsa –in iva_withkey.pem –out iva.key

Openssl rsa –in iva_withkey.pem –out iva.key

В консоли администрирования переходим в раздел «Домены» – «Детально».

В открывшихся настройка находим секцию «Настройки TLS», как видно, никаких настроек сейчас нет.

Открываем текстовым редактором наши файлы сертификата .pem и ключа .key и копируем их в нужные секции. После этого сохраняем настройкой кнопкой «Сохранить».

Переходим в раздел «Системные настройки», находим секцию «Настройки TLS» и снимаем галку «Использовать текущую конфигурацию».

Проверяем что всё работает корректно. С клиента открываю ссылку на IVA MCU, как видно, что ошибки сертификата в браузере больше нет. Браузер доверяет сертификату сервера.

Если у вас будет использоваться один сертификат для платформы, тогда можно заменить сертификат и ключ по умолчанию в разделе «Системные настройки» — «Настройки TLS», а настройки раздела «Домены» не менять.

Стоит отметить, что сертификат можно сменить и через терминал сервера. Для этого необходимо разобраться где же платформа хранит сертификаты.

Посмотрим в настройках web сервера.

Дополнительные файлы конфигурации находятся по пути

/etc/nginx/conf.d

Открываем файл /etc/nginx/conf.d/iva.adminguru.local.conf и находим место хранения сертификата и ключа.

ssl_certificate      /var/lib/monitoring/storage/tls/local/iva.adminguru.local.crt;
ssl_certificate_key  /var/lib/monitoring/storage/tls/local/iva.adminguru.local.pem;

После замены файлов необходимо поправить ссылки на новые сертификаты, и не забыть выполнить сохранение изменений командой:

sudo iva-cli live save-changes

Если не выполнить сохранение изменений, то после перезагрузки они восстановяться в предыдущее состояние. Я переименовал файл сертификата по умолчанию ivcs-default.crt в ivcs-default.crt_old. После перезагрузки без сохранения изменений он снова присутствует в папке.

Настройка кластера завершена, в следующей статье рассмотрим интеграцию IVA MCU с MS AD.

Сообщение Установка сертификата в IVA MCU появились сначала на Админгуру.

Поднимаем ещё два сервера по аналогии.

У меня следующие параметры

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

sudo iva-cli configurator unlock

Затем на двух основных серверах пересобираем кластер:

sudo iva-cli cluster configure \

 —head-node-1-ip 192.168.232.20 \

 —head-node-2-ip 192.168.232.21 \

 —media-node-ip 192.168.232.30 \

 —media-node-ip 192.168.232.31 \

 —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 show-changes

Как видно изменения есть и их нужно сохранить.

Выполняем на всех серверах:

sudo iva-cli live save-changes

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

sudo iva-cli configurator lock

Проверим, что изменения применились. Переходим в консоль администрирования, вкладка «Модули системы». Как видно служба media, nginx-media и coturn теперь располагается на добавленных медиа серверах.

Теперь необходимо поправить медиа группу, для этого переходим на вкладку «Медиа сервера» в консоли администрирования. Удаляем значение медиа сервера по умолчанию 127.0.0.1.

Кнопкой «Подключить медиа сервер» вводим ip адреса новых серверов и добавляем их.

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

Проверим что всё работает корректно и медиа обрабатывается добавленными серверами. Создаю внутренних для ИВА тестовых пользователей.

Одним пользователем создаю комнату и добавляю второго пользователя в участники. В админке на вкладке «Запланированные конференции» находим созданное тестовое собрание, открываем «О мероприятии» и видно, что конференцию обслуживает медиа сервер 192.168.232.31.

Тест на клиентах показывает что всё работает и медиа трафик обслуживается новыми серверами.

Сообщение Вынос медиа сервиса на отдельные серверы появились сначала на Админгуру.

Поднимаем второй основной сервер 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. В следующей статье будет разобран вынос медиа серверов на отдельные машины.

Сообщение Настройка кластера active – standby появились сначала на Админгуру.

Согласно сайту производителя «ВКС IVA сочетает в себе все последние тенденции в области разработки и функционал, отвечающие требованиям современных пользователей. Платформа может быть использована для проведения совещаний, лекций, опросов, обмена файлами и сообщениями, планирования мероприятий и осуществления их записи. Благодаря поддержке разрешения видео до 4К Ultra HD, ни одна деталь не ускользнет от вашего внимания».

Используемый стенд

Memory          8GB

Processors      4

Hard Disk(SCSI) 60GB

Монтирую установочный диск в виртуальную машину, включаю ВМ и поехали.

На первом шаге нажимаем Install IVCS.

На втором шаге система предлагает проверить целостность образа, соглашаемся.

Ожидаем конца проверки.

На третьем шаге процесс установки предлагает создать разделы.

У меня один диск

выбираю его

и соглашаюсь на создание раздела.

Cнова ожидаем.

На четвёртом шаге процесс установки предлагает задать сетевую конфигурацию сервера и fqdn сервера. Заполняем все поля и нажимаем ОК.

На пятом этапе процесс установки предлагает разрешить доступ по паролю для подключений по ssh, выбираем данный пункт.

На шестом этапе предлагается ввести пароль супер пользователя системы.

Пароль должен состоять из 12 символов, содержать 2 и более заглавные буквы, а также минимум 2 спецсимвола.

На седьмом этапе выбираем регион.

В конце установки перегружаем сервер.

Сервер перезагружается и мы видим заветное приглашение в терминал.

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

Далее добавляю в DNS A запись сервера.

Попробуем открыть web консоль администрирования, и видим ошибку сертификата, установка которого ещё не проводилась. Всё равно переходим на сайт.

Согласно документации производителя, вход в web консоль администрирования разрешён с адресов из диапазонов: 127.0.0.0 – 127.255.255.255; 10.0.0.0 – 10.255.255.255; 172.16.0.0 – 172.31.255.255; 192.168.0.0 – 192.168.255.255. Если ваш ip адрес, с которого осуществляется вход в консоль, не входит в этот диапазон, то добавить свой ip в разрешённые можно будет через правку БД в терминале.

sudo -u postgres psql -d ivcs -Atc «update videoconference.settings set value = ‘0.0.0.0/0’ where name = ‘admin_access_ip_list’;»

Видим окно входа в систему. Вводим стандартный логин admin и пароль admin

Вот она заветная админка. Сразу замечаю, что fqdn, который мы вводили на четвёртом этапе оказался fqdn домена, а не сервера.

На этом базовая установка IVA MCU завершена.

В следующей статье рассмотрим создание кластера Active-Passive из двух серверов.

Сообщение Первичная установка IVA MCU появились сначала на Админгуру.