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