При работе с распределенными информационными базами (РИБ) многие администраторы и разработчики сталкиваются с ситуацией, когда созданные в центральной базе (ЦБ) пользователи успешно переносятся в периферийную базу (ПБ) как элементы справочника, но при этом теряют свои пароли, права доступа и даже не отображаются в окне выбора при запуске программы. Рассмотрим подробнее, почему это происходит и как правильно настроить доступ в дочерних узлах.
Для начала проанализируем ситуацию с технической точки зрения. В системе 1С данные о пользователе разделены на два независимых слоя, и это критически важно понимать для успешной настройки РИБ:
Пользователи: Это обычный объект метаданных (ссылочный тип), который хранится в таблицах базы данных вместе с накладными, контрагентами и товарами. В нем хранятся ФИО, контактная информация и ссылки на настройки. Так как это справочник, он легко включается в состав плана обмена РИБ и мигрирует между базами.Выясним причину такого разделения. Это сделано из соображений безопасности и гибкости: один и тот же сотрудник может иметь полные права в центральном офисе, но обладать ограниченным доступом в региональном филиале. Кроме того, передача хешей паролей через файлы обмена могла бы создать уязвимость в защите данных.
Часто при попытке вручную задать пароль в периферийной базе возникает ошибка: «После исполнения в списке не осталось бы ни одного пользователя с административными правами». Это защитный механизм конфигураций на базе БСП (Библиотеки стандартных подсистем), таких как УНФ, Бухгалтерия или ERP.
Система видит, что в справочнике Пользователи есть люди с ролью «Администратор», но так как записи в списке системных пользователей (ПИБ) для них еще не созданы или не сопоставлены, платформа считает, что в базе вообще нет ни одного «живого» администратора, способного управлять доступом. Пока вы не создадите хотя бы одну полноценную системную запись, обладающую административными полномочиями, 1С будет блокировать изменения настроек безопасности.
Как выяснилось в ходе обсуждения, самым простым и правильным способом в современных конфигурациях является работа через режим «1С:Предприятие». Пройдем по шагам процесс активации перенесенного пользователя в периферийном узле:
ПользователиИнформационнойБазы.Важный момент: установка прав внутри режима «Предприятие» (через профили и группы доступа) является предпочтительной. Поскольку ГруппыДоступа и ПрофилиГруппДоступа сами являются объектами данных, они также передаются через РИБ. Вам достаточно лишь «привязать» пользователя к уже существующей группе в периферийной базе.
Если пользователей сотни, ручная активация в каждом филиале невозможна. Рассмотрим, как можно автоматизировать этот процесс. Мы можем использовать обработчик события загрузки данных в плане обмена или подписку на событие записи справочника Пользователи.
Посмотрим на пример кода, который программно создает системного пользователя на основе данных справочника:
Процедура СоздатьСистемногоПользователя(ТекущийПользовательСправочник)
// Проверяем, не создан ли уже системный пользователь
Идентификатор = ТекущийПользовательСправочник.ИдентификаторПользователяИБ;
СуществующийПИБ = ПользователиИнформационнойБазы.НайтиПоУникальномуИдентификатору(Идентификатор);
Если СуществующийПИБ = Неопределено Тогда
// Создаем новую запись ПИБ
НовыйПИБ = ПользователиИнформационнойБазы.СоздатьПользователя();
НовыйПИБ.Имя = ТекущийПользовательСправочник.Наименование;
НовыйПИБ.ПолноеИмя = ТекущийПользовательСправочник.Наименование;
НовыйПИБ.АутентификацияСтандартная = Истина;
// ВАЖНО: Пароли через РИБ не передаются, ставим пустой или временный
НовыйПИБ.Пароль = "123";
// Назначаем роли (должны существовать в конфигурации)
НовыйПИБ.Роли.Добавить(Метаданные.Роли.ПолныеПрава);
НовыйПИБ.Записать();
// Не забываем связать справочник с ПИБ
ОбъектПользователь = ТекущийПользовательСправочник.ПолучитьОбъект();
ОбъектПользователь.ИдентификаторПользователяИБ = НовыйПИБ.УникальныйИдентификатор;
ОбъектПользователь.Записать();
КонецЕсли;
КонецПроцедуры
Проанализируем этот код: мы используем метод ПользователиИнформационнойБазы.СоздатьПользователя() для генерации системной записи. Обратите внимание на реквизит ИдентификаторПользователяИБ. Это «мостик» между миром данных и миром системы. Если UUID в справочнике и UUID в системной таблице не совпадут, программа будет выдавать ошибки прав доступа, так как ГруппыДоступа не смогут сопоставить объект справочника с текущим сеансом.
Если в вашей организации используется доменная структура, задача упрощается. Рассмотрим этот вариант подробнее. При настройке пользователя в центральной базе укажите его имя в формате DOMAIN\UserName. Поскольку эта строка хранится в реквизитах справочника, она придет в периферийную базу по РИБ.
В периферийной базе при активации пользователя (флаг «Вход в программу разрешен») выберите «Аутентификация операционной системы». Это избавит вас от необходимости синхронизировать пароли вручную — 1С будет доверять проверке подлинности, выполненной Windows. Это наиболее стабильный и безопасный путь для распределенных систем.
Подведем итоги нашего исследования проблемы синхронизации пользователей в РИБ:
Пользователи, пришедшем из центра.Следуя этим правилам, вы сможете избежать ошибок с отсутствием прав и обеспечите бесперебойную работу всех сотрудников в распределенной системе 1С.