Как создать пользователя в нескольких синхронизируемых базах 1С и избежать дублирования?

При администрировании распределенных систем на платформе 1С часто возникает задача: в компании появляется новый сотрудник, которому необходим доступ сразу к нескольким информационным базам (например, Управление торговлей и Бухгалтерия предприятия). Если базы синхронизируются между собой, ручное создание карточки пользователя в каждой из них сопряжено с высоким риском дублирования данных. При первой же синхронизации система может не сопоставить эти записи автоматически, что приведет к появлению «двойников» в справочниках.

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

В чем сложность: архитектура пользователей в 1С

Для начала разберем важную техническую деталь, которую необходимо понимать каждому администратору 1С. Учетная запись пользователя в системе состоит из двух независимых сущностей:

1. Пользователь информационной базы (пользователь ИБ) — это объект системного уровня (настройки авторизации, имя входа, пароль, роли и права доступа). Эти данные хранятся на уровне платформы.
2. Элемент справочника «Пользователи» — это прикладной объект в базе данных, который используется для подстановки в документы (например, ответственный в заказе или реализации).

Типовая синхронизация данных между конфигурациями 1С на БСП (Библиотеке стандартных подсистем) умеет переносить только элементы прикладного справочника Пользователи. Системные пользователи ИБ (учетные записи для входа в систему) при этом автоматически не создаются и не переносятся. Обмен происходит по уникальному идентификатору (GUID). Если создать карточки вручную в двух базах, они получат разные GUID, что неизбежно приведет к их замятию или дублированию при обмене.

Рассмотрим рабочие способы решения этой задачи.

Способ 1. Использование обработки «Выгрузка и загрузка данных XML»

Это самый быстрый и надежный практический способ, если вам необходимо «клонировать» одного или нескольких конкретных пользователей с гарантированным сохранением их внутренних идентификаторов (GUID). Способ идеально подходит для баз с идентичными или схожими конфигурациями.

Разберем этот процесс по шагам:

1. Откройте первую («мастер») базу, в которой уже создан нужный пользователь в справочнике Пользователи.
2. Запустите типовую обработку ВыгрузкаЗагрузкаДанныхXML.epf (ее можно найти на диске ИТС или в каталоге шаблонов конфигураций).
3. В списке объектов для выгрузки найдите справочник Пользователи.
4. Настройте отбор, указав конкретного нового сотрудника, чтобы не выгружать весь справочник целиком.
5. Выгрузите данные во внешний файл XML.
6. Откройте базу-приемник и запустите ту же обработку на вкладке «Загрузка». Загрузите полученный файл.

Результат: В базе-приемнике будет создан элемент справочника с точно таким же уникальным идентификатором (GUID). Теперь при следующей плановой синхронизации обмена данными эти элементы гарантированно сопоставятся «один в один», и дублирования не произойдет. Настройки прав доступа и авторизацию для базы-приемника в данном случае можно настроить уже на месте вручную.

Способ 2. Интерактивное сопоставление при первой синхронизации

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

Проанализируем этот сценарий:

1. Создайте пользователя в обеих базах вручную. Постарайтесь сделать так, чтобы их ключевые реквизиты (ФИО, Наименование) совпадали до символа.
2. При запуске очередного сеанса синхронизации данных система обнаружит новые несинхронизированные объекты и выведет окно сопоставления.
3. В окне сопоставления данных вручную укажите связь между карточкой пользователя из базы А и карточкой из базы Б.
4. После подтверждения сопоставления эта связь запишется в специальный регистр сведений — РегистрСведений.СоответствияОбъектовИнформационныхБаз (в некоторых конфигурациях — РегистрСведений.ПубличныеИдентификаторыСинхронизируемыхОбъектов).

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

Способ 3. Программное создание пользователя ИБ с сохранением пароля

В некоторых случаях администратору требуется написать собственную мини-обработку для автоматического переноса пользователей ИБ (включая их пароли). Многие разработчики сталкиваются с трудностью: пароль пользователя информационной базы хранится в захешированном виде, и прочитать его напрямую методами встроенного языка невозможно.

Выясним причину и найдем решение. Начиная с версии платформы 8.2.9, у объекта ПользовательИнформационнойБазы появилось системное свойство СохраняемоеЗначениеПароля. Это позволяет нам считать хэш пароля в базе-источнике и записать его в базу-приемник без необходимости знать сам пароль в явном виде.

Рассмотрим пример кода для программного копирования параметров пользователя:

// Получаем системного пользователя из текущей базы
ПользовательИсточник = ПользователиИнформационнойБазы.НайтиПоИмени("ИвановИИ");

Если ПользовательИсточник <> Неопределено Тогда
    // Создаем пользователя в другой базе (например, через COM-соединение или в текущей для теста)
    НовыйПользователь = ПользователиИнформационнойБазы.СоздатьПользователя();
    НовыйПользователь.Имя = ПользовательИсточник.Имя;
    НовыйПользователь.ПолноеИмя = ПользовательИсточник.ПолноеИмя;
    
    // Переносим хэшированное значение пароля напрямую
    НовыйПользователь.СохраняемоеЗначениеПароля = ПользовательИсточник.СохраняемоеЗначениеПароля;
    
    // Сохраняем пользователя в системном списке
    НовыйПользователь.Записать();
КонецЕсли;

Обратите внимание на то, как БСП обходит ограничения платформы при создании пользователей. В современных версиях Библиотеки Стандартных Подсистем при необходимости генерации нового пароля система может временно создавать служебного пользователя, задавать ему текстовый пароль, получать его хэш через свойство СохраняемоеЗначениеПароля, после чего присваивать этот хэш целевому пользователю, а временный объект удалять. Этот подход позволяет гибко управлять безопасностью информационной системы.

Способ 4. Профессиональный подход — интеграция с Active Directory (AD / LDAP)

Если масштаб вашей компании растет, а количество информационных баз превышает 3–5 единиц, то ручное копирование GUID или регулярное использование XML-обработок становится неэффективным. Наиболее зрелым решением является внедрение сквозной авторизации (Single Sign-On, SSO) через домен Windows.

Как это работает на практике:

1. Администратор создает учетную запись нового сотрудника один раз в корпоративном каталоге Active Directory.
2. В каждой информационной базе 1С создается карточка пользователя, у которой в параметрах аутентификации выбирается пункт «Аутентификация операционной системы» и указывается его доменное имя (например, domain\ivanov.ii).
3. Для автоматизации наполнения справочника Пользователи настраивается периодическое регламентное задание, которое считывает список сотрудников из AD по протоколу LDAP и автоматически создает/обновляет карточки в базах 1С.

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